¿Por qué mi web va lenta? Las 6 causas y cómo arreglarlas

Una web va lenta cuando una de seis cosas tarda demasiado: la primera respuesta del servidor, la imagen principal, el momento en que el navegador la descubre, el JavaScript que hay que ejecutar, los scripts de otras empresas, o las fuentes y un diseño que no deja de moverse. Cada una tiene su arreglo, y actuar sobre la causa equivocada no cambia nada. El límite que Google considera rápido es el Largest Contentful Paint (LCP), el momento en que aparece el contenido principal: 2,5 segundos o menos en al menos el 75% de las visitas, según lo define web.dev.

Este artículo es para quien tiene la web y se pregunta por qué va lenta: un founder, una responsable de marketing, el dueño de un negocio al que se lo ha dicho un cliente. Aquí están las seis causas, cómo saber en unos diez minutos cuál es la tuya y qué arregla cada una.

¿Es habitual que una web vaya lenta?

Mucho, sobre todo en el móvil. El Web Almanac 2025 de HTTP Archive vio que el 48% de las webs en móvil aprueba las tres Core Web Vitals, frente al 36% de 2023. La métrica que más suspende es la propia carga: en el móvil, el 62% de las webs tiene un LCP bueno, el 25% necesita mejorar y el 13% es deficiente.

Además, las páginas pesan cada vez más. En 2025 la página de inicio mediana en escritorio llegó a 2,9 MB, un 7,3% más que el año anterior, según el capítulo del Web Almanac sobre el peso de las páginas. La de móvil lleva 911 KB de imágenes y 632 KB de JavaScript.

Y la velocidad se nota en la facturación. En el estudio Milliseconds Make Millions, que Deloitte y 55 hicieron para Google con 37 marcas europeas y estadounidenses y más de 30 millones de sesiones, una mejora de 0,1 segundos en la velocidad móvil vino acompañada de un 9,1% más de usuarios de retail que pasaban de la ficha de producto a la cesta. Esos usuarios gastaron además un 9,2% más.

Por qué un servidor más rápido casi nunca basta

Lo primero que hace mucha gente es contratar un hosting más potente. Eso ataca una causa de seis. Web.dev divide el LCP en cuatro partes: el tiempo hasta el primer byte, el retraso antes de que empiece a cargarse la imagen principal, lo que tarda en descargarse y el retraso antes de que se pinte. En una página bien ajustada, según web.dev, cerca del 40% del tiempo se va en la respuesta del servidor y otro 40% en descargar el recurso principal, con menos del 10% para cada uno de los dos retrasos. Un servidor nuevo recorta la primera parte. Si el tiempo se va en una foto de portada de 1,4 MB o en un script que bloquea el renderizado, el plan nuevo cuesta más y la página sigue lenta.

Así que el orden es: medir, encontrar la causa y arreglar esa causa.

¿Cómo sé por qué mi web va lenta?

Abre PageSpeed Insights, pega la dirección de la página que más importa (la de inicio y la landing a la que apuntan tus campañas) y lee el informe en este orden:

1. El bloque de arriba, los datos de campo. Es lo que vivieron los visitantes reales de Chrome en los últimos 28 días, en el percentil 75. Si dice que no hay datos, la página tiene poco tráfico y te toca fiarte de la prueba de laboratorio de debajo.
2. Primero el móvil. Es la pestaña que suele suspender.
3. Qué métrica está en rojo. El LCP en rojo indica una carga lenta. El INP (Interaction to Next Paint) en rojo indica que la página tarda en reaccionar a toques y clics. El CLS (Cumulative Layout Shift) en rojo indica que los elementos saltan mientras se carga.
4. El desglose del LCP en el diagnóstico. Muestra cuántos milisegundos se van en cada una de las cuatro partes. La más grande señala tu causa.

Con diez minutos sabes dónde mirar. Las seis causas de abajo siguen el orden en que las revisamos.

Causa 1: el servidor tarda en responder

El Time to First Byte (TTFB) es la espera antes de que al navegador le llegue algo. Web.dev lo considera bueno hasta 0,8 segundos y deficiente por encima de 1,8. Los motivos habituales: la página se reconstruye desde la base de datos en cada visita, un hosting compartido está ocupado sirviendo otras webs, el servidor está en otro continente respecto a tus visitantes, o una cadena de redirecciones (de http a https y luego a www) añade viajes antes de que la página arranque.

Qué la arregla: servir las páginas desde una caché, o generarlas de antemano cuando el contenido lo permite. Poner una CDN delante para que la respuesta salga de una ciudad cercana al visitante. Quitar las redirecciones que sobran. Y solo después pensar en un servidor más grande.

Causa 2: la imagen principal pesa demasiado

En casi todas las páginas de marketing el elemento visible más grande es una foto de portada. Subida tal cual sale de la cámara o del programa de diseño, puede pesar varios megas para un banner que se muestra a 1.200 píxeles de ancho. En el desglose, es la duración de la carga del recurso.

Qué la arregla: exportar la imagen al tamaño al que se muestra, con varias versiones para cada pantalla mediante srcset. Usar AVIF o WebP y comprimir. Después, fijar un límite de peso para la portada y revisarlo cada vez que alguien cambie la foto, que es cuando el problema vuelve.

Causa 3: la imagen principal empieza a cargar tarde

Una imagen ligera también llega tarde si el navegador la descubre tarde. El culpable típico es la carga diferida (lazy loading) aplicada a todas las imágenes, portada incluida: el navegador espera a tener el diseño antes de pedirla. El Web Almanac 2025 vio que entre el 16% y el 17% de las páginas aplica la carga diferida justo a la imagen del LCP. Pasa lo mismo con las portadas puestas como fondo CSS o insertadas con JavaScript, porque el navegador no las ve en el HTML.

Qué la arregla: dejar loading="lazy" solo para las imágenes que quedan por debajo de la primera pantalla. Poner la portada en el HTML como una img normal y marcarla con fetchpriority="high" para que el navegador la pida la primera.

Causa 4: demasiado JavaScript

Una imagen se descarga y se pinta. El JavaScript se descarga, se analiza y se ejecuta, y mientras se ejecuta la página no responde. El Web Almanac lo resume en una línea: 100 KB de imagen son píxeles, 100 KB de JavaScript son trabajo. La página móvil mediana arrastra 251 KB de JavaScript sin comprimir que nunca usa. El JavaScript pesado se nota en un INP malo, en un retraso de renderizado largo o en las dos cosas. Los maquetadores visuales, los sliders, las librerías de animación y las plantillas que cargan todas sus funciones en todas las páginas son las fuentes más habituales.

Qué la arregla: quitar lo que la página no usa. Cargar el resto solo donde hace falta y aplazar lo que la primera pantalla no necesita. Generar el contenido en el servidor, para que el texto no espere a un script. La parte de código la tienes con detalle en los errores de frontend que hunden la puntuación de Lighthouse.

Causa 5: los scripts de otras empresas

Analítica, gestores de etiquetas, chats, mapas de calor, herramientas de test A/B, píxeles de publicidad, mapas y vídeos incrustados. Cada uno es código que llega del servidor de otro: no decides cuánto pesa ni cuándo cambia. Según el capítulo del Web Almanac sobre terceros, al menos el 90% de las páginas usa uno o más servicios de terceros. Se acumulan sin hacer ruido: cada campaña añade un píxel y nadie quita el de la campaña anterior.

Qué la arregla: hacer la lista de todas las etiquetas y de quién las pidió. Quitar aquellas cuyos datos no lee nadie. Cargar el resto cuando la página ya se puede usar, y cambiar los elementos incrustados pesados (un chat, un reproductor de vídeo) por un marcador ligero que carga el de verdad al hacer clic. Las herramientas de test A/B que ocultan la página hasta elegir la variante frenan todo, así que conviene comprobar si de verdad hay un test en marcha.

Causa 6: las fuentes y un diseño que se mueve

La página de inicio móvil mediana carga 122 KB de fuentes, también según el Web Almanac. Varios pesos de una tipografía propia, servidos desde otro dominio, pueden retener el texto o cambiarlo en el último momento. Las imágenes sin dimensiones, los banners que se insertan arriba y los anuncios que llegan tarde empujan el contenido hacia abajo mientras se lee. Ese movimiento es lo que mide el CLS, y por encima de 0,25 el valor es deficiente.

Qué la arregla: cargar solo los pesos que usa el diseño y alojarlos en tu propio dominio. Usar font-display: swap con una fuente de reserva de tamaño parecido. Dar de antemano sus dimensiones a cada imagen, elemento incrustado y hueco publicitario, para que el espacio quede reservado antes de que llegue el contenido.

Un ejemplo concreto

Un desglose ilustrativo, no de un cliente. Una página de inicio tiene un LCP de 4,2 segundos en móvil. PageSpeed Insights lo reparte en 0,6 segundos de TTFB, 2,1 de retraso en la carga del recurso, 1,2 de duración de la carga y 0,3 de retraso de renderizado. El servidor está bien. La portada lleva carga diferida y pesa 1,4 MB. Cargarla de inmediato con prioridad alta elimina buena parte de los 2,1 segundos; exportarla al tamaño correcto en AVIF elimina buena parte del 1,2. Dos cambios en una sola imagen, ningún hosting nuevo, y la página puede bajar de los 2,5 segundos.

La misma página con un TTFB de 2 segundos pediría el trabajo contrario: primero caché y CDN, después la imagen. Por eso el desglose va antes que cualquier arreglo.

Cómo mantener la web rápida después del arreglo

La velocidad se pierde poco a poco: una etiqueta nueva, una sección más, una foto más pesada. La mantienen tres costumbres. Fijar un límite de peso para las páginas clave y revisarlo antes de cada publicación. Repasar el gestor de etiquetas cada trimestre con quien lleve el marketing. Vigilar el informe de Core Web Vitals de Search Console, que lee los mismos datos de campo que PageSpeed Insights; como abarcan 28 días, una mejora aparece ahí cerca de un mes después.

Si tras un rediseño han caído a la vez la velocidad y el posicionamiento, la guía sobre por qué tu web ya no aparece en Google después del rediseño cubre la parte de indexación. Para el presupuesto de mantener una web en forma tienes cuánto cuesta mantener un sitio web en 2026. Para webs en Next.js, Core Web Vitals en Next.js repasa las herramientas del propio framework.