¿Por qué mi web es tan lenta? Las causas reales y cómo solucionarlas

Resumen: los sospechosos habituales, por orden

La mayoría de las webs lentas lo son por el mismo puñado de razones, y normalmente encontrarás la tuya en la lista de abajo. Las mayores mejoras casi siempre vienen de imágenes demasiado grandes y de scripts de terceros que olvidaste que habías añadido. Empieza por ahí y luego baja. Una prueba de velocidad puntual en tu propia máquina te engañará, así que el último y más importante paso es medir la velocidad que experimentan tus visitantes reales en sus propios móviles y redes.

• Imágenes y medios pesados. Las fotos sin comprimir y los archivos sobredimensionados son la causa número uno de cargas lentas. Comprime, redimensiona y usa formatos modernos.
• Demasiados scripts de terceros. Los widgets de chat, los píxeles de anuncios, las herramientas de A/B y las analíticas pesadas añaden cada uno su peaje. Y suman rápido.
• CSS y JavaScript que bloquean el renderizado. El navegador se atasca con recursos que tiene que cargar antes de poder pintar nada. Aplaza lo que no haga falta de entrada.
• Hosting lento y sin caché ni CDN. El hosting compartido barato y la falta de caché hacen que cada visitante espere a un servidor de origen lento.
• Core Web Vitals deficientes. Hasta un sitio "rápido" puede sentirse torpe si el contenido salta o los botones no responden. Son las métricas que Google y tus usuarios notan.
• Medir lo que no es. Una puntuación de laboratorio en una sola máquina rápida no es la velocidad que reciben tus visitantes reales. Monitoriza a usuarios reales para encontrar el camino lento que de verdad te está costando.

Imágenes y medios pesados

Si tu sitio va lento, las imágenes son lo primero que debes mirar. Una sola foto de cabecera exportada directamente desde un móvil o una herramienta de diseño puede pesar tres o cuatro megabytes. Apila unas cuantas en una página y habrás construido un sitio que se arrastra en el móvil, por muy limpio que sea tu código.

La solución tiene tres partes. Primero, redimensiona las imágenes al tamaño al que realmente se muestran. Una foto que se ve a 600 píxeles de ancho no necesita medir 4000 píxeles de ancho. Segundo, comprímelas. Las herramientas y los procesos de compilación pueden reducir la mayoría de las imágenes a la mitad o más sin pérdida de calidad visible. Tercero, usa formatos modernos como WebP o AVIF, que son muchísimo más pequeños que los antiguos JPEG y PNG con la misma calidad.

Dos mejoras baratas más: aplica carga diferida (lazy loading) a las imágenes que quedan por debajo del pliegue, para que el navegador solo las descargue cuando el visitante se acerca a ellas al desplazarse, y define siempre un ancho y un alto explícitos en las imágenes para que la página no salte mientras cargan. Esto último importa más de lo que parece, y volveremos a ello cuando hablemos de los Core Web Vitals.

El vídeo es la misma historia, solo que peor. Si tienes que usarlo, alójalo en una plataforma pensada para streaming y carga el reproductor solo cuando alguien interactúa con él.

Demasiados scripts de terceros (el peaje oculto)

Esta es la causa que se esconde a plena vista. A lo largo de un año, un sitio va acumulando en silencio un widget de chat, una herramienta de mapas de calor, un fragmento de pruebas A/B, dos píxeles de anuncios, un banner de cookies, un cargador de fuentes y una o tres etiquetas de analítica. Cada una parecía inofensiva cuando la añadiste. Juntas suelen ser lo más pesado de la página, y lo más lento, porque se conectan con servidores que no controlas.

Los scripts de terceros son un peaje por dos motivos. Añaden bytes que descargar y procesar, y añaden idas y vueltas de red a otros dominios que pueden ser lentos de por sí. Una sola etiqueta de marketing perezosa puede impedir que el resto de tu página se vuelva interactiva, y normalmente no puedes hacer más rápidos esos servidores externos, así que tu única palanca es eliminar o aplazar el script.

Audita lo que tienes. Abre el panel de red de tu navegador, carga la página y ordena por dominio. Casi con seguridad encontrarás peticiones a servicios que habías olvidado o que dejaste de usar hace meses. Borra todo lo que no necesites de verdad. Para el resto, cárgalos de forma asíncrona o después de que la página sea interactiva, y plantea una alternativa más ligera. Los que más pesan rara vez son los que imaginarías.

Un buen hábito: trata cada script nuevo como un coste, no como un añadido gratis. Antes de pegar un fragmento en tu sitio, pregúntate si se gana su peso. Si estás montando un proyecto nuevo, un repaso rápido a una lista de comprobación para lanzar una web te ayuda a no acabar atornillando cinco herramientas que luego tendrás que arrancar.

CSS y JavaScript que bloquean el renderizado

Incluso con imágenes ligeras y pocos scripts, una página puede sentirse lenta por el orden en que el navegador hace las cosas. Cuando el navegador se topa con una hoja de estilos o un script en la cabecera de tu página, a menudo tiene que detenerse, descargar ese archivo y procesarlo antes de poder pintar nada en pantalla. Ese atasco es lo que los visitantes experimentan como una página en blanco.

El objetivo es dejar que el navegador muestre algo útil lo antes posible. Incrusta el pequeño fragmento de CSS necesario para renderizar lo que se ve primero (el contenido "por encima del pliegue") y carga el resto después. Para JavaScript, usa los atributos defer o async para que los scripts no bloqueen el primer pintado, y divide los paquetes grandes para que el navegador solo descargue el código que una página concreta necesita de verdad.

Los frameworks y constructores de sitios modernos se encargan de buena parte de esto por ti, pero no de todo. Las fuentes son un culpable habitual: una fuente web personalizada que impide mostrar el texto deja a los visitantes mirando la nada, o provoca un parpadeo cuando el texto se intercambia. Indica al navegador que muestre texto de respaldo de inmediato mientras la fuente carga. Cambio pequeño, diferencia real.

Hosting, caché y una CDN

A veces la página en sí está bien y el problema es el servidor que hay detrás. En un hosting compartido económico, tu sitio convive en una máquina con cientos más, y cuando uno de ellos se satura, todos se ralentizan. El primer byte de tu página puede tardar un segundo o más en llegar antes de que empiece nada más. Si tu tiempo hasta el primer byte es lento de forma constante, ninguna compresión de imágenes te va a salvar.

La caché es la solución con más palanca aquí. Una caché guarda una copia ya preparada de tus páginas para que el servidor no las reconstruya desde cero en cada petición. Para un sitio de contenidos o un blog, la caché de página completa puede convertir un origen perezoso en algo que responde casi al instante. La mayoría de las plataformas y gestores de contenido traen la caché integrada o a un plugin de distancia.

Una red de distribución de contenidos (CDN) es la otra gran palanca. Una CDN mantiene copias de tus archivos estáticos (imágenes, CSS, JavaScript) en servidores repartidos por el mundo, de modo que un visitante en Sídney carga desde una ciudad cercana en lugar de esperar a que los bytes crucen un océano desde tu origen en Fráncfort. Para una audiencia global, esto por sí solo puede recortar el tiempo de carga de forma notable, y si tu hosting no incluye una, hay muchas CDN gratuitas para empezar.

Y antes de que nada de esto importe, el servidor tiene que estar disponible. Un sitio caído es infinitamente lento, y las caídas tienen la costumbre de ocurrir en el peor momento sin que nadie se dé cuenta durante horas. Si nunca te has parado a pensar en lo que tu hosting realmente garantiza, nuestras notas sobre el tiempo de actividad de una web explican por qué una serie de pequeñas caídas suma en silencio mucho más tiempo perdido del que la mayoría de los propietarios supone. Saber el momento exacto en que tu origen se apaga, o empieza a responder lento, es el suelo sobre el que se apoya todo lo demás que ves aquí.

Core Web Vitals en lenguaje claro

Google mide la velocidad de un sitio mediante un conjunto de métricas llamadas Core Web Vitals, que aparecen en la búsqueda y en el informe de experiencia de Chrome. Vale la pena entenderlas porque se corresponden de cerca con lo que un visitante real siente de verdad, no solo con el tiempo bruto de descarga. Son tres, y los umbrales son públicos en web.dev.

El Largest Contentful Paint (LCP) mide cuánto tarda en terminar de cargar el elemento visible más grande (normalmente tu imagen de cabecera o tu titular). Apunta a menos de 2,5 segundos. El Interaction to Next Paint (INP) mide la rapidez con que responde la página cuando alguien toca o hace clic, con un objetivo por debajo de 200 milisegundos. El Cumulative Layout Shift (CLS) mide cuánto salta la página mientras carga, y conviene mantenerlo por debajo de 0,1. Puedes leer las definiciones completas en la página oficial de Core Web Vitals.

En términos sencillos: el LCP es "qué tan rápido apareció la página", el INP es "qué tan rápido reacciona cuando la toco" y el CLS es "¿se quedó quieto el diseño o el botón se movió justo cuando iba a tocarlo?". Ese CLS conecta directamente con las imágenes sin dimensiones y los anuncios que cargan tarde, por lo que definir el ancho y el alto de las imágenes importa tanto. Si algún término de aquí te resulta nuevo, el glosario define los más comunes en un solo lugar.

Dos de las tres tienen que ver con la capacidad de respuesta y la estabilidad, no solo con la velocidad de descarga. Esa es la parte que una sola ejecución de Lighthouse en tu portátil tiende a ocultar, lo que nos lleva a la sección más importante.

Los datos de laboratorio mienten: monitoriza a tus usuarios reales

Aquí está el truco que socava la mayor parte del trabajo de optimización. Cuando ejecutas una herramienta como Lighthouse y obtienes una puntuación brillante, eso es una prueba de laboratorio: una página, una máquina rápida, una conexión estable, ejecutada una sola vez. Tus visitantes reales no se parecen en nada a eso. Están en móviles de gama media, en el wifi de un hotel, en un tren, con una docena de pestañas abiertas de fondo. La velocidad que reciben puede ser radicalmente distinta de la que reporta tu portátil, y un script que a ti te carga bien podría ser justo lo que está lastrando a todos los demás.

Por eso una sola puntuación, por muy verde que sea, no basta. La única forma de saber la velocidad que la gente experimenta de verdad es medirla desde su lado, en sus dispositivos y redes, de forma continua. Cuando puedes observar la velocidad que reciben los visitantes reales, dejas de optimizar para un número que nadie más ve y empiezas a arreglar el camino lento que te está costando visitantes: la página que va rápida en tu máquina pero se atasca en un móvil, el script que va bien con fibra pero lo bloquea todo con datos móviles.

El lugar más sencillo para empezar es la pregunta más básica de todas: ¿está el sitio respondiendo ahora mismo, y con qué rapidez? No puedes arreglar una ralentización de la que nunca te enteras, y las caídas y las respuestas lentas tienen la costumbre de pasar desapercibidas durante horas. Un poco de monitorización de tiempo de actividad que compruebe tu origen de forma programada te avisará cuando los tiempos de primer byte suban o el servidor se quede en silencio, que es el suelo bajo cualquier otra solución de este artículo.

Una vez que vigilas a usuarios reales, el trabajo cambia. En lugar de perseguir una puntuación de laboratorio perfecta, vigilas las páginas y dispositivos donde la velocidad cae, los arreglas y confirmas que el arreglo se mantuvo para personas reales. Para un marco más amplio sobre qué medir y por qué, nuestra guía de buenas prácticas de analítica web explica cómo conectar los datos de velocidad y comportamiento con resultados que de verdad importan.