Mejorar la velocidad de carga de una web empieza por localizar en cuál de las tres capas se pierde el tiempo, el servidor, la red o el navegador. Cada una se arregla con palancas distintas, así que de la lista genérica que circula por ahí solo te toca una parte.
Cuál de las tres es la tuya lo dice la medición, y no toda medición vale lo mismo, porque la nota que da PageSpeed Insights sale de un simulador, mientras que Google puntúa con lo que viven tus usuarios reales.
Vamos por orden, primero cómo hacer esa medición, después qué palanca toca en cada capa y por último qué hacer con los scripts que la web ha ido acumulando, que no son un problema técnico sino una decisión de negocio.
Localiza qué está frenando la velocidad de carga de tu web
Las tres capas van encadenadas, así que lo que se atasca arriba arrastra a todo lo que viene detrás, y casi siempre hay una que se lleva la mayor parte del tiempo. Ese es tu cuello de botella, y hasta que no lo tengas localizado, cualquier mejora es una apuesta.
El diagnóstico sale de dos herramientas gratuitas de Google, el informe de Core Web Vitals de Search Console, que te dice si tus visitantes reales sufren el problema, y de PageSpeed Insights, que señala la capa con el TTFB para el servidor, el peso de los recursos para la red y las tareas largas de JavaScript para el navegador.
Vamos con las tres en el orden en que se encadenan, de arriba abajo, que es el mismo en el que conviene arreglarlas cuando te sale más de una tocada.
El servidor tarda en contestar y lo mide el Time to First Byte (TTFB)
El reloj empieza cuando el navegador pide la página y para cuando recibe el primer byte, y ese número lo encuentras en PageSpeed Insights, dentro del bloque de datos de usuarios reales. Según la documentación de TTFB de web.dev, por debajo de 0,8 segundos está bien y por encima de 1,8 es malo.
Google no lo cuenta entre las Core Web Vitals, pero llega antes que ellas, porque mientras el servidor no conteste, el navegador no puede ni empezar a dibujar la página.
Para saber si el problema es del alojamiento o de tu web, compara páginas. Si va igual de mal en la más sencilla que en la portada, mira el plan o el proveedor, y si solo se dispara en el catálogo filtrado, mira las consultas y los plugins.
El peso de lo que se descarga y desde dónde viaja
Con el servidor ya respondiendo, queda lo que pesa la página y los kilómetros que hay hasta quien te visita. Un ecommerce alojado en Madrid con clientes en México paga esa distancia en cada archivo que envía.
Sobre ese peso circula un consejo clásico que ha caducado a medias, el de juntar todo el CSS y el JavaScript en un solo fichero. Quitar los archivos que ya no usa nadie sigue valiendo, pero juntar los que quedan ya no sale a cuenta, porque HTTP/2 y HTTP/3 los piden en paralelo y cambiar una línea invalida el fichero entero en la caché.
Cada dominio externo al que se conecta la página abre además su propio viaje, porque antes de su primer byte hay que resolver un DNS, abrir conexión y negociar el cifrado, y cada integración nueva repite el trámite entero.
Lo que le cuesta al navegador pintar la página y responder a un clic
Una web puede recibirlo todo rápido y aun así sentirse lenta, y ahí el sospechoso es el JavaScript. Mientras el navegador ejecuta un bloque pesado no pinta nada ni atiende los clics, así que el usuario ve una página quieta.
Eso es lo que mide el Interaction to Next Paint (INP), con el listón en 200 milisegundos para considerarse bueno y en 500 para darlo por malo.
Si te encuentras el First Input Delay en una guía, ya sabes que está desactualizada, porque el INP lo sustituyó el 12 de marzo de 2024.
En esta capa entra también el desplazamiento visual de lo que carga tarde, una de las tres Core Web Vitals que mide Google, y se arregla reservándole el espacio por adelantado.
Las palancas para mejorar la velocidad de carga de tu web
Con el diagnóstico delante, la acción que más rinde es la que ataca tu capa. Comprimir imágenes cuando el servidor tarda dos segundos en contestar es tiempo perdido en el sitio equivocado.
Y si una guía te manda montar AMP, mira su fecha, porque el 1 de julio de 2026 Google retiró el visor y la caché de AMP y esas páginas se indexan igual que cualquier otra, así que hoy es trabajo doble sin premio.
Alojamiento y redirecciones
Si el diagnóstico apunta al servidor, en esta capa solo hay dos cosas que tocar, lo que tarda en contestar y cuántas veces le preguntas antes de llegar a la página buena. Se empieza por lo segundo, porque limpiar saltos es barato y, si aun así el TTFB no baja, ya sabes que el problema es del proveedor.
Las redirecciones te las lista el propio PageSpeed Insights, en el mismo bloque donde mide el tiempo de respuesta del servidor, y casi siempre vienen de mudanzas viejas, el salto de http a https o una URL que cambió de sitio y nadie limpió detrás.
Cada salto es una petición completa antes de que empiece a contar todo lo demás, y cuando se encadenan dos o tres, esa espera se repite en cada página que abre el visitante. Dejar cada URL en un solo salto son treinta minutos y se nota en toda la web.
Cambiar de plan o de proveedor es otra historia, una migración con su riesgo y su fin de semana perdido, así que se guarda para cuando el TTFB siga mal con los saltos ya limpios.
Comprimir lo que viaja y acortar la distancia
Se empieza por el texto, que es lo más barato de arreglar, porque GZIP o Brotli encogen el HTML, el CSS y el JavaScript antes de enviarlos y en la mayoría de alojamientos basta con activar el interruptor.
Las imágenes llevan más trabajo, pero es donde más peso se recupera, porque una foto de 3.000 píxeles que se ve a 600 pesa varias veces lo que debería, y optimizar las imágenes para SEO pasa por redimensionarlas al tamaño real y servirlas en WebP.
Cuando ya no queda peso que quitar, lo que se acorta es el viaje, con una CDN que deja copias cerca de quien te visita y la caché de navegador, que evita descargar lo mismo en cada página que abre.
El vídeo es la excepción, porque en tu propio servidor genera picos de peso que ninguna compresión arregla. YouTube o Vimeo se llevan ese ancho de banda, pero su reproductor mete JavaScript de terceros que carga aunque nadie le dé al play, así que pon una miniatura y que el vídeo llegue solo cuando alguien lo pide.
Cargar solo lo que hace falta cuando hace falta
Buena parte de lo que descarga una página al entrar no lo ve nadie, porque queda por debajo de la pantalla, y la carga diferida, o lazy loading, retrasa esos recursos hasta que el visitante se acerca.
Una ficha con veinte fotos descarga dos al entrar y pide el resto solo si alguien baja, y la excepción es la imagen principal de la parte visible, porque si la retrasas frenas justo la pantalla que querías acelerar.
No hace falta programarlo, porque el atributo que lo activa es cosa del navegador y WordPress lo añade solo desde la versión 5.5, y desde la 5.9 deja fuera la primera imagen de la página por ese mismo motivo. Lo que sí conviene es comprobar que tu plantilla o tu plugin de caché no lo esté aplicando también ahí.
Aligerar lo que ejecuta el navegador
De esta capa todo el mundo conoce una palanca, minificar y diferir el JavaScript que no hace falta para pintar la primera pantalla, y casi nadie audita la otra, los plugins del gestor de contenidos.
Minificar es quitarle al código los espacios, los saltos de línea y los comentarios que el navegador no necesita, y ahorra unos pocos kilobytes. Diferir es lo que mueve la aguja, porque un script diferido deja de bloquear el pintado y se ejecuta cuando la página ya está en pantalla.
En webs con años de recorrido es normal encontrar plugins instalados para una campaña que terminó hace dos años y que siguen sumando peticiones en cada visita. Lista los que tienes activos, mira cuáles siguen haciendo algo hoy y ve desactivándolos de uno en uno, para ver si algo se rompe.
Decide qué scripts de terceros se quedan
Ese código no lo escribió tu equipo, entra desde marketing o ventas con una petición razonable y se acumula sin que nadie vuelva a mirarlo, así que empieza por un inventario corto con el chat, los píxeles, el gestor de etiquetas y los tests A/B, y por cada uno apunta quién lo pidió y qué pasaría si lo apagases mañana.
Un chat que trae dos contactos al mes puede estar costando más de lo que aporta si ralentiza la web entera en cada visita, y esa cuenta la hace quien mira el embudo, no quien mira el código.
Cuando un script se queda porque hace falta, tienes tres salidas, retrasar su carga hasta que la página sea usable, activarlo solo donde cumple una función, o sustituirlo por una alternativa más ligera.
Esta tabla recoge todas las palancas, en qué capa actúa cada una y qué señal del diagnóstico te dice que te toca.
Acción | Capa donde actúa | La señal que lo dispara |
|---|---|---|
Cambiar de plan o proveedor de alojamiento | Servidor | TTFB alto en páginas simples con los saltos ya limpios |
Quitar redirecciones innecesarias | Servidor | Saltos encadenados antes de la primera respuesta |
Comprimir el texto de la página con GZIP o Brotli | Red | HTML, CSS y JavaScript que viajan sin comprimir |
Activar una CDN | Red | Visitas lejos del servidor |
Activar caché de navegador | Red | Los mismos archivos en cada visita |
Comprimir y redimensionar imágenes | Red | Imágenes más grandes de lo que se ven |
Lazy loading para lo que queda fuera de pantalla | Red | Peso al entrar que el usuario no llega a ver |
No alojar vídeo en el propio servidor | Red | Picos de peso en las páginas con vídeo |
Minificar o diferir el JavaScript no crítico | Navegador | Tareas largas de JavaScript e INP por encima de 200 ms |
Auditar y quitar plugins innecesarios | Navegador | Plugins activos que ya no usa nadie |
Quitar o retrasar scripts de terceros | Red y navegador | Conexiones a dominios externos que nadie reclama |
El orden no cambia, medir antes de tocar nada, decidir qué terceros se quedan y atacar solo la capa que señale tu cuello de botella. La velocidad se degrada sola con cada plugin y cada tanda de contenido, así que vuelve a medirla cada pocos meses, dejando cuatro semanas tras cada cambio, que es lo que cubre el informe de Search Console.
Si quieres que te digamos por dónde empezar, pídenos el análisis SEO gratuito, donde revisamos 41 puntos de tu posicionamiento en Google, la velocidad incluida, y te devolvemos un vídeo con lo que arreglaríamos primero. Y si prefieres no tocarlo tú, lo resolvemos nosotros con el servicio de mejora de velocidad de carga.
