Las tres métricas Core Web Vitals y sus umbrales 2026
Google mide la experiencia de usuario mediante tres métricas principales, agrupadas bajo el término Core Web Vitals. Cada una tiene un umbral «Good» y un umbral «Needs Improvement» a partir del cual el posicionamiento se ve afectado.
LCP — Largest Contentful Paint. Mide el tiempo de renderizado del elemento visible más grande (imagen principal, bloque de texto principal). Umbral Good: ≤ 2 500 ms. Needs Improvement: entre 2 500 ms y 4 000 ms. Por encima de 4 000 ms: Poor.
INP — Interaction to Next Paint. Introducido como sustituto de FID, INP mide la latencia entre un gesto del usuario (clic, tecla, toque) y el siguiente renderizado visual. Umbral Good: ≤ 200 ms. Needs Improvement: entre 200 ms y 500 ms. Por encima de 500 ms: Poor.
CLS — Cumulative Layout Shift. Mide la inestabilidad visual de la página — desplazamientos de bloques durante la carga. Umbral Good: ≤ 0,1. Needs Improvement: entre 0,1 y 0,25. Por encima de 0,25: Poor.
Estos umbrales se aplican a datos de campo (CrUX), no a puntuaciones de laboratorio. Una puntuación de 90 en el laboratorio de PageSpeed Insights no garantiza que los usuarios reales superen el umbral — la distinción es importante para las agencias que reportan métricas a sus clientes.
- Posicionamiento de búsqueda degradado — Google integra los Core Web Vitals en su señal Page Experience desde 2021; un sitio clasificado como Poor en LCP o INP pierde posiciones frente a un competidor comparable cuyas métricas están en verde.
- CTR móvil más bajo — los resultados bien posicionados tienen una señal implícita de confianza; una carga lenta percibida por el usuario tras el clic aumenta la tasa de rebote y registra una señal de participación negativa.
- Tasa de conversión reducida — cada segundo adicional de LCP más allá de 2,5 s se correlaciona con un aumento del abandono del carrito; para un sitio de e-commerce, un TTFB de 1 200 ms puede borrar una parte significativa de los ingresos generados por SEO.
- Mayor gasto publicitario — el Quality Score de Google Ads incorpora la experiencia de la página de destino; un LCP Poor degrada la puntuación y eleva el CPC para la misma palabra clave.
- Pérdida de clientes de agencia — cuando el informe mensual de un cliente muestra un INP en rojo, la pregunta llega de inmediato; sin una infraestructura capaz de mantener los umbrales, la agencia no puede prometer una solución duradera.
- Indexación móvil más lenta — Googlebot móvil sigue el mismo retraso de renderizado que los usuarios; un TTFB elevado ralentiza el rastreo y puede retrasar la indexación de páginas nuevas.
- Impacto medible en la experiencia de usuario — un INP superior a 500 ms hace que las interacciones (menús, filtros, formularios) sean perceptiblemente lentas; los comentarios negativos de usuarios suelen preceder a las alertas de métricas.
Cómo el TTFB bloquea el LCP: la cadena causal
TTFB (Time to First Byte) es el tiempo entre la solicitud HTTP del navegador y la recepción del primer byte de la respuesta del servidor. Es el piso incompresible de todo lo demás.
En una conexión móvil estándar (4G mediano), el navegador dispone de aproximadamente 2 500 ms para alcanzar el umbral LCP Good. De ese presupuesto se descuentan primero la resolución DNS, el handshake TLS y el TTFB. Un TTFB de 800 ms — habitual en un alojamiento compartido saturado — deja 1 700 ms para la descarga HTML, el análisis, la carga de recursos bloqueantes y el renderizado del elemento LCP. En la práctica, ese presupuesto es insuficiente.
La cadena causal es la siguiente: el servidor genera la página (PHP, base de datos), luego envía el primer byte. Si PHP-FPM no está activado y el servidor usa mod_php en modo prefork, cada solicitud monopoliza un worker Apache completo. Bajo carga, los workers se agotan y las solicitudes entran en cola. El TTFB crece de forma no lineal — un alojamiento compartido saturado puede superar 1 200 ms de TTFB mientras que en reposo muestra 200 ms.
Añadir una caché de objetos Redis reduce este tiempo de forma significativa: en lugar de ejecutar 40 a 80 consultas SQL para componer una página WordPress, la caché devuelve el resultado precomputado en milisegundos. Sin Redis, cada fallo de caché de página completa (WP Rocket, W3TC) desencadena una regeneración completa que empuja el TTFB muy por encima de 600 ms.
HTTP/3 (QUIC) reduce la latencia de conexión eliminando el round-trip adicional del handshake TCP+TLS, lo que es especialmente significativo en móvil y en redes con pérdida de paquetes. La activación requiere un servidor que soporte QUIC — no disponible en todos los alojamientos compartidos.
Alojamiento compartido saturado vs VPS con PHP-FPM y Redis
Desplace la tabla
| Criterio | Alojamiento compartido saturado | VPS + PHP-FPM + Redis |
|---|---|---|
| TTFB mediano bajo carga | 800 – 1 200 ms | 120 – 250 ms |
| Ejecución PHP | mod_php prefork (worker compartido) | PHP-FPM (pool dedicado, no bloqueante) |
| Caché de objetos | No disponible o desactivada | Socket Redis local, latencia < 1 ms |
| HTTP/3 (QUIC) | Raramente disponible | Configurable en nginx / Caddy |
| Puntuación LCP (campo) | Needs Improvement a Poor con frecuencia | Good alcanzado en conexión estándar |
| Puntuación INP (campo) | Depende del JS del lado del cliente | Mismo JS, menos eventos de bloqueo de red |
| Aislamiento de recursos | CPU y memoria compartidas entre clientes | Recursos dedicados, sin efecto vecino ruidoso |
Optimizar el stack del servidor desde el alojamiento
Activar PHP-FPM en lugar de mod_php
En Apache, reemplazar mod_php por PHP-FPM con
mpm_eventelimina el bloqueo de workers en solicitudes lentas. Verificar el modo activo:apache2ctl -M | grep php. En nginx, PHP-FPM es el único modo disponible — asegurarse de que el pool esté dimensionado para la carga (pm.max_childrencalculado desde la RAM disponible dividida por el consumo promedio de un worker).Configurar Redis como caché de objetos de WordPress
Instalar Redis en el servidor (
apt install redis-servero mediante el gestor de paquetes de la distribución). Activar el socket Unix en lugar de TCP para reducir la latencia:unixsocket /var/run/redis/redis.sock. En WordPress, instalar un plugin de caché de objetos Redis y apuntarlo al socket. Verificar la activación conwp redis status— el estado debe mostrarConnected.Activar la compresión Brotli y Gzip
Brotli ofrece una tasa de compresión superior a Gzip en recursos de texto (HTML, CSS, JS). En nginx, verificar la disponibilidad del módulo:
nginx -V 2>&1 | grep brotli. Sin Brotli, Gzip sigue siendo eficaz:gzip_comp_level 6; gzip_types text/plain text/css application/javascript application/json image/svg+xml;. Activar el servicio precomprimido (archivos.gzestáticos) para recursos que no cambian.Activar HTTP/3 (QUIC) en nginx o Caddy
Caddy activa HTTP/3 por defecto sin configuración adicional. En nginx, la disponibilidad depende de la versión compilada:
nginx -V 2>&1 | grep http3. Añadir en el bloqueserver:listen 443 quic reuseport; add_header Alt-Svc 'h3=":443"; ma=86400';. Abrir el puerto UDP 443 en el firewall (ufw allow 443/udp). Validar concurl --http3 -I https://yourdomain.com.Activar la caché de página en el servidor (si el CDN no la gestiona)
Una caché de página del servidor (FastCGI cache de nginx, o módulo Varnish) devuelve el HTML precompilado sin tocar PHP ni la base de datos. El TTFB cae entonces por debajo de 50 ms para las páginas en caché. Excluir las páginas de carrito, cuenta y páginas con cookie de sesión del almacenamiento en caché:
fastcgi_cache_bypass $cookie_woocommerce_items_in_cart;.Medir el TTFB en condiciones reales con WebPageTest
Ejecutar un test desde
webpagetest.orgseleccionando un punto de presencia cercano al objetivo geográfico de los clientes. Elegir un perfil móvil (Moto G4 o equivalente) y una conexión 4G simulada. En los resultados, leer la columna TTFB en la cascada — aísla el tiempo del servidor del tiempo de red. Comparar las ejecuciones en caliente (caché presente) y en frío (caché vaciada mediante el parámetro de test).Verificar el impacto real mediante CrUX y Search Console
PageSpeed Insights muestra los datos CrUX para el dominio analizado cuando están disponibles (volumen de tráfico suficiente). Las métricas de campo aparecen en la sección 'Field data' — son las únicas que importan a Google. En Search Console, el informe 'Page Experience' agrega las URL por estado (Good / Needs Improvement / Poor) en una ventana de 28 días.
Medir correctamente: WebPageTest vs PageSpeed Insights
WebPageTest y PageSpeed Insights miden cosas diferentes, y confundirlos conduce a decisiones erróneas.
PageSpeed Insights ejecuta una auditoría Lighthouse en el laboratorio — condiciones controladas, dispositivo simulado, red simulada. La puntuación mostrada (0 a 100) es una valoración de oportunidades de mejora, no una medida del rendimiento real de los usuarios. Un sitio puede mostrar 95 en el laboratorio y ser clasificado como Poor en datos de campo si el contenido dinámico o las interacciones JavaScript degradan las métricas reales. La puntuación de PageSpeed Insights no es la señal de posicionamiento de Google.
WebPageTest permite configurar con precisión el punto de test geográfico, el perfil de dispositivo y la simulación de red. Expone la cascada de carga completa, los tiempos DNS/TCP/TLS/TTFB, y admite tests multi-paso para medir INP en una interacción simulada. Para diagnosticar un TTFB elevado, WebPageTest es la herramienta de referencia.
Los datos CrUX (Chrome User Experience Report) recopilan métricas reales de usuarios de Chrome durante 28 días. Están disponibles a través de PageSpeed Insights, Search Console y la API CrUX directamente. Estos son los datos que Google utiliza para el posicionamiento — no la puntuación Lighthouse.
Cómo leer el informe CrUX en Search Console: abre la propiedad, ve a 'Experiencia en la página', luego 'Informe de Core Web Vitals'. El informe distingue entre móvil y escritorio. Haz clic en 'URL correctas' o 'URL deficientes' para ver qué páginas están afectadas. Si el volumen de datos es insuficiente (sitio con poco tráfico), los datos CrUX no aparecerán — usa PageSpeed Insights en las URL clave y ten en cuenta que el impacto en el posicionamiento sigue siendo real aunque no haya informe de Search Console disponible. Para clientes de agencia con poco tráfico, céntrate en las mediciones de WebPageTest y los umbrales absolutos en lugar de los informes CrUX.
Resolución de problemas: cuatro casos frecuentes
TTFB correcto pero INP en rojo. Un TTFB inferior a 250 ms no garantiza un INP por debajo de 200 ms. INP mide la capacidad de respuesta a las interacciones, no la carga inicial. Causas frecuentes de un INP elevado a pesar de un buen TTFB: el hilo principal de JavaScript bloqueado por scripts de terceros (analítica, chatbots, publicidad) durante la fase de interactividad; tareas largas (Long Tasks > 50 ms) que retrasan el renderizado tras un clic; hidratación Vue o React costosa en una página SSR. El diagnóstico se realiza en Chrome DevTools > Performance, grabando una interacción e identificando las tareas largas en el hilo principal.
INP pasa en el laboratorio pero no en el campo. Las herramientas de laboratorio (Lighthouse, WebPageTest) miden INP en interacciones simuladas en condiciones controladas. En datos de campo, INP incluye todas las interacciones de todos los usuarios, incluidas las de dispositivos de gama baja con scripts de terceros cargados, extensiones de navegador activas y conectividad variable. Un INP de 180 ms en el laboratorio puede superar 500 ms en el campo si un script de terceros bloquea el hilo principal durante la carga inicial. Identifica los scripts de terceros con webpagetest.org y mide su impacto en el hilo principal.
LCP lento a pesar de Cloudflare. Cloudflare almacena en caché los recursos estáticos, pero no almacena en caché las páginas HTML por defecto (salvo configuración explícita mediante Page Rules o Cache Rules). Si el LCP está impulsado por un elemento HTML (texto o imagen incluida en el HTML), el TTFB de la página HTML sigue determinando el LCP. Verifica la cabecera CF-Cache-Status en la respuesta HTTP: curl -I https://yourdomain.com | grep CF-Cache-Status. Si el valor es DYNAMIC o BYPASS, la página no está en caché de Cloudflare y el TTFB del servidor se aplica íntegramente.
CLS que retrocede tras una actualización del tema. El CLS es sensible a los recursos que cargan sin dimensiones especificadas (imágenes sin width/height, fuentes web que causan FOIT/FOUT, banners inyectados por JavaScript). Tras una actualización de tema, verifica sistemáticamente que las imágenes tienen atributos de dimensión explícitos y que las fuentes web usan font-display: swap u optional. Inspecciona la sesión de grabación CLS en PageSpeed Insights (sección Diagnósticos) para identificar el elemento que se desplaza.
Lo que la agencia puede prometer a sus clientes
Un informe PageSpeed en rojo no es inevitable, pero hay que distinguir qué corresponde al alojamiento y qué al código del cliente.
Del lado del alojamiento, los compromisos medibles son: TTFB inferior a 250 ms en condiciones normales de carga, disponibilidad de PHP-FPM con un pool dimensionado, caché de objetos Redis activa y compresión Brotli o Gzip en recursos de texto. Estos cuatro puntos cubren la parte del servidor en el LCP y reducen mecánicamente el riesgo de superar los 2 500 ms en una página optimizada del lado del cliente.
INP sigue siendo parcialmente responsabilidad del código front-end — los scripts de terceros, la hidratación JavaScript y las tareas largas no dependen del proveedor de alojamiento. Lo que el alojamiento puede hacer por el INP: reducir el TTFB (menos tiempo de espera antes de que JS empiece a ejecutarse), activar HTTP/3 (menos latencia en los recursos bloqueantes), y no introducir contención de CPU que prolongue las tareas JavaScript durante el renderizado SSR.
Una agencia que gestiona un portfolio de clientes puede garantizar los umbrales del lado del servidor, documentar las mediciones de WebPageTest y CrUX por dominio, y aislar las regresiones en su fuente — tema, plugin, script de tercero o capacidad del servidor. Esa capacidad de aislamiento es lo que diferencia a una agencia que reacciona ante los informes PageSpeed de una que los controla.
