Mide el problema real primero
No puedes arreglar lo que no has medido, y "se siente lento" no es un diagnóstico. Abre PageSpeed Insights (pagespeed.web.dev), introduce tu URL, y lee dos cosas: los Core Web Vitals y las métricas de laboratorio. Céntrate en la pestaña móvil, ya que la mayoría de los visitantes están en teléfonos. Luego mide el TTFB (Time To First Byte) —cuánto tarda tu servidor en enviar el primer byte— porque separa un problema de servidor de un problema de entrega.
Los objetivos saludables son un LCP por debajo de 2,5 segundos, un INP por debajo de 200 ms, un CLS por debajo de 0,1, y un TTFB por debajo de unos 200 ms. Si el TTFB es alto, el cuello de botella está en el lado del servidor: hosting, PHP o la base de datos. Si el TTFB está bien pero el LCP es alto, el cuello de botella es la propia página —normalmente imágenes grandes y la distancia que recorren hasta el visitante. Esta única medición te dice con qué soluciones empezar.
Las causas reales de un sitio lento
La mayoría de los sitios lentos comparten un puñado de causas. Un servidor lento o un hosting compartido saturado dispara el TTFB antes de que cargue una sola imagen. Las páginas pesadas vienen después —imágenes sobredimensionadas (normalmente lo más grande de una página), temas hinchados y constructores de páginas que envían docenas de hojas de estilo y scripts. Demasiados scripts de terceros (widgets de chat, mapas de calor, rastreadores, fuentes extra) añaden cada uno una petición y bloquean el renderizado.
El CSS y el JavaScript que bloquean el renderizado retrasan el primer pintado incluso cuando el servidor es rápido. Y la distancia importa: un único servidor lejos de muchos de tus visitantes añade latencia a todo, y un pico de tráfico puede saturarlo. Casi todo sitio lento es alguna mezcla de esto —trabajo repetido del servidor, recursos pesados, scripts bloqueantes y distancia física.
Entender los Core Web Vitals
Google posiciona en parte según los Core Web Vitals, así que ayuda saber qué mide cada uno. El LCP (Largest Contentful Paint) es cuánto tarda en aparecer el contenido principal —a menudo la imagen hero—; lo perjudican sobre todo los servidores lentos y las imágenes pesadas y distantes. El INP (Interaction to Next Paint) es cuán rápido responde la página cuando un visitante toca o hace clic; lo perjudica el JavaScript pesado que bloquea el hilo principal.
El CLS (Cumulative Layout Shift) es cuánto salta el diseño mientras carga; lo perjudican las imágenes y los anuncios sin espacio reservado y las fuentes que cargan tarde. Arreglar las causas anteriores —entrega más rápida, imágenes más ligeras, menos JavaScript y espacio reservado para los medios— es exactamente lo que mejora estos tres números.
Las soluciones que mueven los números
Trabaja en orden de impacto. Caché: sirve una página ya lista en lugar de reconstruirla en cada visita —la mayor ganancia individual para el TTFB y la carga del servidor. Imágenes: ajusta su tamaño al que se muestran y sirve formatos modernos (WebP/AVIF), que suelen dominar el peso de la página. Scripts: elimina los scripts de terceros que no necesitas y difiere el resto para que dejen de bloquear el primer pintado.
Reserva espacio para imágenes y anuncios para que el diseño no salte (mejor CLS), y carga las fuentes sin bloquear el renderizado. Luego acorta la distancia que recorre tu contenido con una CDN. Cada solución ataca una causa específica, y juntas mueven el LCP, el INP y el CLS a la vez.
Una CDN resuelve el problema de la distancia y de los picos
Incluso después de afinar tu servidor y tus páginas, un servidor solo puede estar en un lugar. Una CDN copia tus archivos estáticos a servidores edge repartidos por todo el mundo, así cada visitante se sirve desde el más cercano —menor latencia y un LCP más bajo para quienes están lejos de tu origen, además de resiliencia cuando el tráfico se dispara porque el edge absorbe la carga. La entrega moderna (compresión Brotli, HTTP/2) y el SSL automático, el WAF y la protección DDoS vienen incluidos.
cdn.com.tr hace esto sin reconstruir nada: enruta tu dominio a través de la CDN y el edge empieza a almacenar en caché y entregar tus recursos desde una ubicación cercana a cada visitante. Las páginas dinámicas siguen funcionando con normalidad, los certificados se renuevan solos, y la distancia que perjudicaba tu LCP desaparece.
Dónde más importa la velocidad
Los lectores abandonan los artículos lentos; unas páginas más rápidas y la caché edge los mantienen leyendo y ayudan a que una publicación popular sobreviva a un pico de tráfico.
Cada segundo extra en una página de producto o pago reduce las conversiones; la caché y una CDN mantienen ágil una tienda concurrida.
Las primeras impresiones y las puntuaciones de calidad de los anuncios dependen de la velocidad; una página rápida y cercana al visitante mejora ambas.
Preguntas frecuentes sobre la velocidad del sitio
¿Qué son los Core Web Vitals?
Tres métricas que Google usa para puntuar la experiencia real: LCP (cuán rápido aparece el contenido principal), INP (cuán rápido responde la página a la interacción) y CLS (cuán estable es el diseño). Mejorarlas ayuda tanto a los usuarios como al posicionamiento.
¿Cómo bajo un TTFB alto?
Un TTFB alto es un problema del lado del servidor: usa PHP actualizado, añade caché de página para que las páginas no se reconstruyan en cada visita, añade una caché de objetos Redis para sitios con muchas consultas, y elige un hosting más rápido. Una CDN sirve entonces las respuestas en caché aún más cerca de los visitantes.
¿Una CDN por sí sola hará mi sitio rápido?
Una CDN elimina el problema de la distancia y absorbe los picos, que es una gran parte de la velocidad. Pero si un TTFB alto viene del servidor, o las imágenes están sobredimensionadas, arregla eso también —una CDN entrega tus páginas más rápido, no reconstruye por ti un origen lento.
¿Por qué mi sitio es más lento en móvil?
Los teléfonos tienen CPUs más débiles y a menudo redes más lentas, así que el JavaScript pesado y las imágenes grandes perjudican más. Imágenes más ligeras, menos scripts y una entrega en caché y cercana son lo que mueve las puntuaciones móviles que Google usa para posicionar.