Page Speed: qué es, cómo medirlo y qué lo ralentiza

Page speed y Core Web Vitals no son sinónimos, aunque se usan a menudo como si lo fueran. Page speed es el concepto amplio y coloquial: la percepción general de cuánto tarda una página en cargar y quedar utilizable. Es un término que se usa en SEO desde mucho antes de que existieran las métricas actuales y que sigue empleándose para hablar del rendimiento de una web en general, en una conversación con un cliente o en un briefing, sin entrar en cifras concretas. Quien apunta solo «mejorar el page speed» en un informe, sin precisar qué métrica o qué herramienta usa como referencia, deja que el equipo de desarrollo busque la solución sin saber por dónde empezar.

Core Web Vitals es la implementación concreta que Google eligió a partir de 2020 para medir ese rendimiento de forma estandarizada: tres métricas con umbrales numéricos definidos, que forman parte de las señales de "page experience" en el algoritmo de búsqueda. Core Web Vitals es, en la práctica, un subconjunto dentro de page speed: la parte que Google decidió convertir en factor de ranking medible. Page speed incluye también aspectos que esas tres métricas no capturan de forma directa, como el tiempo de respuesta del servidor en interacciones que no forman parte del cálculo de LCP, INP o CLS, o la percepción subjetiva de fluidez que tiene un usuario al navegar.

Para el desglose completo de LCP, INP y CLS, con sus umbrales y ejemplos, está el artículo dedicado a Core Web Vitals. Aquí nos centramos en lo que ese artículo no cubre: cómo se mide el page speed en la práctica y qué lo está frenando.

Para medir page speed hay tres herramientas gratuitas de Google que cubren casi todos los casos.

PageSpeed Insights analiza una URL concreta en el momento en que se la pides y devuelve dos bloques de datos distintos para esa misma página: datos de laboratorio y datos de campo, cuando existen suficientes visitas reales para generarlos. Es la herramienta más habitual para una primera revisión rápida.

Lighthouse es el motor que hace la auditoría de laboratorio, tanto dentro de PageSpeed Insights como desde las herramientas para desarrolladores de Chrome, la línea de comandos o un módulo de Node. Simula una visita en condiciones fijas, con un dispositivo y una conexión de referencia, y por eso da siempre el mismo resultado si nada cambia en la página entre una prueba y otra.

El informe de velocidad o de Core Web Vitals de Search Console muestra datos de campo agregados por grupos de URLs con estructura parecida, no una sola página aislada, y con una ventana temporal de varias semanas. Es el que refleja mejor lo que están viviendo los visitantes reales del sitio, aunque tarda más en actualizarse que una prueba puntual.

La diferencia entre datos de laboratorio y datos de campo es el punto que más confunde a quien empieza a mirar estas herramientas. Los datos de laboratorio, los que da Lighthouse, se generan en un entorno controlado: mismo dispositivo simulado, misma velocidad de red, sin el ruido de miles de conexiones distintas. Sirven para depurar un problema concreto antes de publicar un cambio, porque son reproducibles. Los datos de campo, los que vienen del Chrome User Experience Report o CrUX, proceden de visitas reales de usuarios de Chrome que han cargado esa página en sus propios móviles, portátiles y conexiones, con toda la variedad que eso implica.

Que ambas cifras no coincidan no es un fallo de la herramienta ni una señal de que algo esté mal configurado. Miden cosas distintas por diseño: un test de laboratorio con fibra y un móvil de gama media puede salir "bueno" en LCP, mientras que el dato de campo real refleja que buena parte de los visitantes entra desde un móvil de gama baja con una conexión 4G débil, y ahí el resultado agregado sale peor. Cuando las dos cifras difieren mucho, el dato de campo es el que manda a la hora de decidir prioridades, porque es el que describe lo que de verdad experimenta la audiencia.

Conviene tener en cuenta también cómo se genera el dato de campo. PageSpeed Insights lo calcula sobre una ventana móvil de 28 días, así que refleja el comportamiento agregado de las últimas cuatro semanas, no el de esa misma jornada. Si una URL concreta no recibe suficiente tráfico real, Chrome no genera datos de campo para ella y solo aparece el resultado de laboratorio; en ese caso conviene mirar el dato agregado del grupo de URLs con plantilla similar en Search Console, en lugar de asumir que la página simplemente no tiene datos de rendimiento reales disponibles.

Casi todos los problemas de page speed se reducen a un puñado de causas técnicas que se repiten proyecto tras proyecto.

Imágenes sin comprimir o demasiado grandes para el espacio en el que se muestran son la causa más común, sobre todo en sitios con muchas fotos de producto o contenido editorial. La solución pasa por servir las imágenes en formatos modernos como WebP o AVIF, comprimirlas antes de subirlas y usar tamaños responsive que entreguen la resolución adecuada según el dispositivo, en lugar de una imagen enorme redimensionada por CSS. También ayuda aplicar carga diferida, o lazy loading, a las imágenes que quedan fuera de la primera pantalla, para que el navegador no gaste ancho de banda en contenido que el usuario todavía no ve.

El JavaScript y el CSS que bloquean el renderizado obligan al navegador a descargar y ejecutar ese código antes de poder pintar el contenido en pantalla, aunque ese código no haga falta para lo primero que ve el usuario. La solución habitual es diferir o cargar de forma asíncrona el JavaScript que no es crítico para la primera pantalla, e insertar en línea solo el CSS mínimo necesario para el contenido inicial, dejando el resto para después. Marcar los scripts no esenciales con los atributos defer o async, y revisar qué parte de las hojas de estilo realmente hace falta para pintar la primera pantalla, suele ser el cambio con más impacto en relación con el esfuerzo que requiere.

La falta de caché obliga al navegador a volver a descargar recursos que apenas cambian, como logotipos, hojas de estilo o librerías, en cada visita. La solución es configurar cabeceras de caché adecuadas en el servidor o el CDN para que esos recursos se guarden en el navegador durante un tiempo razonable y solo se vuelvan a pedir cuando cambien de verdad. Conviene distinguir entre la caché del navegador, que guarda archivos estáticos como imágenes o scripts, y la caché de página completa en el servidor, que evita regenerar el HTML dinámico en cada visita cuando el contenido no ha cambiado.

Un tiempo de respuesta del servidor lento, lo que se conoce como TTFB alto, retrasa todo lo demás porque el navegador no puede empezar a construir la página hasta recibir la primera respuesta. Aquí la solución pasa por revisar el hosting, activar caché de servidor para páginas que no cambian en cada petición y, si el volumen de tráfico lo justifica, apoyarse en un CDN que sirva contenido desde un servidor más cercano al usuario. En sitios con gestor de contenidos, buena parte de un TTFB alto viene de consultas a la base de datos mal optimizadas o de plugins que ejecutan tareas pesadas en cada petición, así que revisar ese punto suele dar más margen de mejora que limitarse a cambiar de plan de hosting.

Estos cuatro frenos rara vez aparecen solos. Una página con imágenes pesadas y sin caché en el servidor suma sus efectos: cada uno añade tiempo por separado, y el usuario percibe la suma total, no cada causa por separado. Por eso una auditoría de page speed rara vez se resuelve tocando un único punto; conviene revisar las cuatro causas en el mismo pase antes de dar el problema por solucionado.

• Medir la misma URL con PageSpeed Insights y con el informe de Core Web Vitals de Search Console antes de sacar conclusiones, para comparar datos de laboratorio con datos de campo reales.
• Comprimir y servir imágenes en formatos modernos (WebP, AVIF) con tamaños adaptados a cada dispositivo, en lugar de subir la imagen original sin tocar.
• Diferir el JavaScript no crítico y cargar en línea solo el CSS necesario para el contenido inicial visible.
• Configurar cabeceras de caché en servidor o CDN para los recursos estáticos que cambian poco.
• Revisar el tiempo de respuesta del servidor (TTFB) de forma periódica, no solo cuando ya hay quejas de lentitud.

• Fijarse solo en el dato de laboratorio de Lighthouse e ignorar el informe de campo de Search Console, que refleja mejor la experiencia real de los visitantes.
• Instalar un plugin de "optimización de velocidad" sin revisar qué cambia realmente en el sitio, ni comprobar el resultado después.
• Subir imágenes a resolución completa y dejar que el navegador las redimensione por CSS, en vez de generar el tamaño correcto de antemano.
• Cargar todo el JavaScript de terceros, chats, píxeles de anuncios, widgets, de forma síncrona y en el head, bloqueando el resto de la carga.
• Tratar el page speed como una tarea puntual antes de un lanzamiento, en lugar de revisarlo con cierta regularidad conforme se añade contenido y funcionalidades nuevas.