Lo que Google mide realmente con los Core Web Vitals
Los Core Web Vitals son tres métricas que describen la experiencia de carga tal como la vive un usuario real. El LCP mide el tiempo de visualización del contenido principal. El CLS cuantifica los saltos de diseño mientras la página se construye. El INP mide el retardo entre una acción del usuario y la respuesta visible de la interfaz.
El matiz que casi todo el mundo pasa por alto está en el método de evaluación. Google no retiene la media de tus visitas. Retiene el percentil 75, sobre una ventana deslizante de 28 días, y separa el móvil del escritorio. Dicho de otro modo, tres visitantes de cada cuatro deben pasar por debajo del umbral para que la métrica se valide. Un sitio rápido para la mayoría pero catastrófico para el cuarto de usuarios en 4G degradada fracasa.
Esta mecánica explica por qué tantos sitios muestran una puntuación Lighthouse de 95 en local y permanecen en rojo en la Search Console. La puntuación Lighthouse simula una visita en condiciones fijas. Los Core Web Vitals, en cambio, provienen del Chrome User Experience Report, la base de datos que Chrome alimenta con las visitas reales de los usuarios que han aceptado el envío de estadísticas.
Los umbrales oficiales de Google: LCP inferior o igual a 2,5 segundos, CLS inferior o igual a 0,1, INP inferior o igual a 200 milisegundos. Entre 2,5 y 4 segundos, entre 0,1 y 0,25, entre 200 y 500 milisegundos, la métrica se clasifica como «necesita mejorar». Más allá, se clasifica como «deficiente». Una URL solo se considera conforme si las tres métricas pasan simultáneamente.
Estos tres indicadores tienen una historia cambiante. El FID, First Input Delay, fue reemplazado por el INP el 12 de marzo de 2024 porque solo medía el retardo antes del procesamiento de la primera interacción, lo que dejaba pasar interfaces realmente lentas. El INP hizo que miles de sitios WordPress sobrecargados de scripts pasaran inmediatamente a rojo cuando hasta entonces mostraban un FID cómodo. En las auditorías que realizamos desde entonces, es la métrica que falla con más frecuencia.
LCP: el elemento más grande visible decide tu percepción de velocidad
El Largest Contentful Paint registra el momento en que el elemento de contenido más grande visible en la ventana inicial termina de mostrarse. En la práctica, casi siempre se trata de la imagen de banner, un vídeo de fondo o el bloque de título principal. Google eligió esta métrica porque corresponde al momento en que el visitante estima que la página está ahí.
Identificar el elemento LCP antes de intentar cualquier cosa
Optimizar sin saber qué elemento se mide hace perder semanas. La pestaña Performance de las DevTools de Chrome muestra un marcador LCP directamente en la línea de tiempo, y PageSpeed Insights nombra el elemento en cuestión en la sección de diagnósticos. En un sitio de presentación, es el visual de hero en el 80 % de los casos. En una ficha de producto, es la imagen principal del producto. En un artículo de blog, a menudo es el título H1 cuando la imagen destacada se carga en diferido.
Descomponer el LCP en cuatro segmentos
Un LCP de 4,8 segundos no dice nada mientras no esté desglosado. El primer segmento es el TTFB, el tiempo que tarda tu servidor en devolver el primer byte. El segundo es el retardo antes del descubrimiento del recurso, es decir, la diferencia entre la llegada del HTML y el momento en que el navegador comprende que debe descargar esa imagen. El tercero es la descarga del recurso. El cuarto es el retardo de renderizado, a menudo causado por un CSS o un JavaScript bloqueante.
Este desglose lo cambia todo, porque cada segmento requiere una corrección diferente. Un TTFB de 1,2 segundos se soluciona del lado del alojamiento y la caché del servidor, nunca comprimiendo imágenes. Un retardo de descubrimiento elevado se soluciona eliminando el lazy loading en el elemento LCP y añadiendo un atributo fetchpriority="high". Un tiempo de descarga excesivo requiere WebP o AVIF, un redimensionamiento real y un CDN. Un retardo de renderizado largo delata una hoja de estilos demasiado pesada o una fuente web mal declarada.
La precarga merece una mención especial porque a menudo se emplea mal. Declarar una decena de recursos en preload equivale a no priorizar nada en absoluto: el navegador se encuentra con diez urgencias simultáneas y el ancho de banda se reparte entre ellas. Una sola precarga bien dirigida a la imagen LCP, asociada a un preconnect hacia el dominio que la aloja cuando proviene de un CDN, produce una ganancia neta. Más allá, el efecto se invierte.
loading="lazy" a todas las imágenes del sitio, incluida la del hero. El navegador retrasa entonces la descarga del elemento LCP y la métrica se dispara. La imagen visible en la carga nunca debe diferirse.Google recomienda un TTFB por debajo de 800 milisegundos para dejar un margen suficiente a los otros tres segmentos. En un WordPress compartido en PHP 7.4 sin caché de objetos, este umbral es inalcanzable independientemente del trabajo realizado en el front. Es el primer punto que verificamos durante una auditoría SEO técnica, incluso antes de mirar el contenido.
CLS: la inestabilidad visual que tus visitantes sufren sin decirlo
El Cumulative Layout Shift mide los desplazamientos inesperados de los elementos durante la carga. Cada desplazamiento recibe una puntuación que combina la fracción de la pantalla afectada y la distancia recorrida por el elemento. El CLS retenido es el de la peor ventana de sesión, una ventana de 5 segundos como máximo, con un intervalo de un segundo entre dos desplazamientos.
Nadie se queja de un CLS elevado, y eso es precisamente lo que lo hace peligroso. El visitante que apunta a un botón y hace clic en un banner publicitario porque la página se ha movido no rellena un formulario de contacto para señalarlo. Se va. En los sitios de comercio electrónico que auditamos, un CLS superior a 0,25 acompaña casi sistemáticamente una tasa de abandono anormal en la ficha de producto.
Las cuatro causas que producen el 90 % del CLS
Las imágenes sin atributos width y height encabezan la lista. Sin estas dimensiones, el navegador no puede reservar el espacio y el texto sube bruscamente cuando la imagen se carga. La corrección consiste en dos atributos, y WordPress los añade nativamente desde la versión 5.5 para las imágenes insertadas mediante el editor, pero no siempre para las inyectadas por un tema o un constructor de páginas.
A continuación vienen los contenidos inyectados dinámicamente por encima de la línea de flotación: banners de consentimiento, barras de promoción, notificaciones de stock. Cada uno empuja todo lo demás hacia abajo. La solución consiste en reservar la altura por adelantado con un contenedor de dimensión fija, o superponer el elemento en lugar de insertarlo en el flujo.
Las fuentes web constituyen la tercera causa. Cuando una fuente personalizada reemplaza la fuente de respaldo, las métricas tipográficas cambian y el texto se reorganiza. La pareja font-display: swap y size-adjust limita el fenómeno, siempre que se precargue el archivo de fuente y se aloje en tu propio dominio en lugar de ir a buscarlo a un tercero.
Los iframes y las integraciones de terceros cierran la marcha. Un mapa, un reproductor de vídeo o un widget de opiniones de clientes que se dimensiona después provoca un desplazamiento sistemático. Reservar la relación de aspecto en CSS soluciona el problema sin tocar el servicio de terceros.
Un CLS limpio no se corrige después, se concibe. En un sitio construido correctamente desde la maqueta, con relaciones de aspecto de imagen definidas y zonas reservadas para cada elemento asíncrono, la métrica cae naturalmente por debajo de 0,05.
INP: la métrica que sanciona los sitios sobrecargados de scripts
El Interaction to Next Paint mide el tiempo entre una interacción y la actualización visible de la pantalla. A diferencia del FID al que reemplazó, observa todas las interacciones de la visita, no solo la primera, y retiene la más lenta o casi. En las páginas que superan unas cincuenta interacciones, el algoritmo ignora un caso extremo por tramo de cincuenta para evitar que un incidente aislado penalice el conjunto.
Tres componentes, tres responsables diferentes
El INP se descompone en retardo de entrada, tiempo de procesamiento y retardo de presentación. El retardo de entrada corresponde a la espera antes de que el navegador pueda siquiera empezar a procesar el clic, porque el hilo principal está ocupado con otra cosa. El tiempo de procesamiento es la duración de ejecución de tus gestores de eventos. El retardo de presentación cubre el recálculo del diseño y el renderizado.
En la gran mayoría de los casos encontrados en WordPress, el culpable es el retardo de entrada, y el culpable detrás del culpable es un script de terceros. Un gestor de etiquetas que carga seis herramientas de seguimiento, un widget de chat en directo, un módulo de opiniones, un píxel publicitario: cada uno añade tareas largas que monopolizan el hilo principal. El visitante hace clic, no pasa nada durante 600 milisegundos, vuelve a hacer clic.
Reducir el INP sin romper las funcionalidades
La primera medida consiste en hacer el inventario de los scripts de terceros y suprimir aquellos de los que nadie consulta los datos. En los sitios que retomamos en mantenimiento WordPress, no es raro desactivar tres herramientas de seguimiento redundantes instaladas en épocas diferentes por proveedores sucesivos.
La segunda consiste en diferir lo que se puede diferir. Un widget de chat no tiene ninguna razón para cargarse antes de la primera interacción del visitante. Cargarlo al primer scroll o al pasar el ratón por el botón libera el hilo principal durante la fase crítica.
La tercera consiste en dividir las tareas largas. Un gestor de eventos que ejecuta 400 milisegundos de cálculo de un bloque debe devolver el control al navegador entre dos etapas, con scheduler.yield() cuando está disponible o un simple aplazamiento de ejecución. El trabajo total sigue siendo idéntico, pero la interfaz responde entre los segmentos.
Medir tus Core Web Vitals: datos de campo frente a datos de laboratorio
Confundir estas dos fuentes es el error metodológico más extendido. Los datos de campo provienen de tus visitantes reales y constituyen la única fuente utilizada por Google para la evaluación. Los datos de laboratorio provienen de una simulación ejecutada bajo demanda, en un entorno estandarizado. Los primeros dicen dónde estás. Los segundos dicen por qué.
PageSpeed Insights, el punto de partida
La herramienta muestra los dos bloques en la misma página. Arriba, la evaluación de la experiencia de usuario real, extraída del Chrome User Experience Report sobre 28 días. Abajo, el diagnóstico Lighthouse y su lista de oportunidades. El bloque superior es el que cuenta para el posicionamiento. El bloque inferior es el que te dice qué corregir.
Una página con poco tráfico no tiene suficientes visitas para alimentar el informe. PageSpeed Insights pasa entonces a los datos del dominio completo, lo que oculta totalmente el comportamiento de la URL probada. Una ficha de producto lenta puede así mostrar un verde tranquilizador heredado de la página de inicio.
La Search Console, para razonar a escala del sitio
El informe Señales web esenciales agrupa las URLs por similitud de estructura y señala los grupos en fallo. Es la herramienta que permite comprender que un problema proviene de una plantilla y no de una página. Cuando 240 fichas de producto aparecen en el mismo grupo en rojo, la corrección se hace una vez en la plantilla y cubre el conjunto del catálogo. Este razonamiento por plantilla es central en un proyecto de SEO e-commerce, donde el volumen de URLs hace imposible cualquier corrección unitaria.
Cuenta 28 días después de una corrección para ver la Search Console pasar a verde. La ventana deslizante del informe integra progresivamente las nuevas visitas. Validar una corrección se hace en laboratorio en una hora, confirmarla sobre el terreno lleva un mes.
Medir en tus propios visitantes
La biblioteca oficial web-vitals de Google permite recopilar las tres métricas directamente en el navegador de tus visitantes y enviarlas a tu herramienta de análisis. El interés es segmentar por tipo de dispositivo, por navegador, por página y por país, lo que el informe agregado no permite. En un sitio multilingüe que sirve Andorra, Francia y España, esta segmentación revela a veces que el problema se limita a una zona geográfica mal cubierta por el CDN.
Corregir los Core Web Vitals en WordPress y Elementor
WordPress no es lento por naturaleza. Se vuelve lento por acumulación: un tema genérico cargado de funcionalidades no utilizadas, treinta extensiones de las cuales doce inyectan su CSS en todas las páginas, un constructor de páginas configurado por defecto, un alojamiento compartido. Cada capa añade unos cientos de milisegundos.
El alojamiento y el TTFB, la base
Ninguna optimización front compensa un servidor lento. PHP 8.2 o superior, OPcache activo, caché de objetos persistente con Redis, caché de página completo, HTTP/2 como mínimo: esta base divide habitualmente el TTFB por tres. En un sitio con tráfico internacional, un CDN que sirve los recursos estáticos desde un punto de presencia cercano al visitante completa el dispositivo. Es exactamente lo que cubre una oferta de alojamiento infogestionado, por oposición a un alojamiento compartido de unos pocos euros al mes donde tu sitio comparte sus recursos con cientos de otros.
Las imágenes, el yacimiento más rentable
Tres acciones en orden. Servir WebP o AVIF en lugar de JPEG, lo que reduce el peso de un 30 a un 50 % a calidad visual constante. Redimensionar realmente los archivos en lugar de dejar que el navegador reduzca una imagen de 3000 píxeles de ancho en un contenedor de 800. Aplicar el lazy loading en todas partes excepto en el elemento LCP, con fetchpriority="high" en este último.
El CSS y el JavaScript, la disciplina de la carga
El principio cabe en una frase: cargar en una página solo lo que esa página utiliza. Un formulario de contacto que inyecta su CSS y su JavaScript en la totalidad del sitio cuando solo aparece en una URL representa un desperdicio puro. La carga condicional de los recursos por extensión, la puesta en línea del CSS crítico en el documento y el aplazamiento del resto constituyen lo esencial del trabajo.
Elementor, los ajustes que cambian las cosas
Elementor Pro arrastra una reputación de pesadez ampliamente heredada de sus versiones antiguas y de configuraciones dejadas por defecto. Las funcionalidades experimentales a activar son conocidas: carga optimizada de recursos, carga del CSS bajo demanda, iconos de fuente en línea, salida DOM optimizada. Eliminan varias decenas de kilobytes en cada página.
El resto depende del método de construcción. Los contenedores flexbox reemplazan ventajosamente el antiguo apilamiento sección, columna, widget, que multiplicaba los niveles de anidamiento y sobrecargaba el árbol del documento. Desactivar las bibliotecas de iconos y las animaciones no utilizadas suprime peticiones enteras. En nuestros proyectos de sitio a medida, limitamos voluntariamente el número de widgets de terceros y reescribimos en HTML y CSS nativos los bloques cuya versión widget cuesta demasiado en rendimiento.
Esta disciplina tiene un límite que hay que asumir. En un sitio que acumula ocho años de contenidos, tres rediseños parciales y una biblioteca de extensiones heredada, la optimización marginal alcanza un techo. Un rediseño de sitio web cuesta a menudo menos que doce meses de correcciones sucesivas sobre una base estructuralmente comprometida, y da un resultado que el remiendo nunca alcanzará.
La base de datos y las extensiones, la partida que nadie mira
Una instalación WordPress de varios años acumula silenciosamente peso invisible desde el front. Las revisiones de artículos se cuentan a veces en decenas de miles de líneas, las tablas de las extensiones desinstaladas permanecen en su sitio, las entradas transitorias caducadas nunca se purgan. Cada petición de página atraviesa esta masa y el TTFB se alarga unos cuantos milisegundos en cada capa.
La limpieza se hace con copia de seguridad previa, nunca en caliente en un sitio en producción. Limitar el número de revisiones conservadas, purgar las tablas huérfanas, indexar correctamente las columnas interrogadas por las extensiones voraces: la ganancia rara vez es espectacular tomada aisladamente, pero se suma a las demás y evita la deriva lenta que se constata en los sitios dejados sin seguimiento. Es precisamente lo que cubre un contrato de mantenimiento serio, a diferencia de una simple vigilancia de disponibilidad.
Queda la cuestión del número de extensiones, sobre la cual circulan muchas aproximaciones. Treinta extensiones ligeras y bien codificadas pesan menos que cinco extensiones que cargan cada una su biblioteca JavaScript completa en todas las páginas del sitio. El criterio útil no es la cantidad, es el peso realmente inyectado página por página, que la pestaña Red de las DevTools revela en unos minutos.
El impacto real en tu posicionamiento, sin exageración
Hay que ser honesto sobre el peso de estas métricas en el algoritmo. Los Core Web Vitals son una señal de clasificación, confirmada y documentada por Google, pero una señal entre cientos. Un sitio perfectamente optimizado técnicamente y vacío de contenido útil nunca pasará por delante de una página de referencia lenta en una consulta competitiva. La pertinencia y la autoridad siguen por delante.
Su influencia se manifiesta en dos situaciones precisas. La primera es el arbitraje entre páginas de calidad comparable: a pertinencia equivalente, la experiencia de página desempata. En una consulta donde diez resultados tratan el mismo tema con la misma seriedad, la diferencia se juega ahí. La segunda es el presupuesto de rastreo. Un servidor lento reduce el número de páginas que Google explora por sesión, lo que ralentiza la indexación de las novedades en los sitios voluminosos.
El efecto indirecto pesa sin embargo más que el efecto directo. Una página lenta aumenta la tasa de rebote, reduce el número de páginas vistas por visita y hace caer la tasa de conversión. Estos comportamientos acaban por leerse en los datos que Google recopila a escala de la web. Un túnel de compra que tarda cuatro segundos en reaccionar a cada clic pierde carritos antes incluso de perder posiciones.
Es también la razón por la cual tratamos el rendimiento como una restricción de diseño y no como una fase de optimización final. Un sitio concebido con un presupuesto de rendimiento definido desde la maqueta no necesita ser recuperado después. Los proyectos visibles en nuestras realizaciones se entregan directamente en verde, sin extensión milagrosa instalada en el último minuto.
El método de intervención, en el orden que produce resultados
El orden cuenta tanto como las acciones. Muchos proyectos fracasan porque empiezan por lo más visible en lugar de por lo más determinante.
- Medir el punto de partida sobre el terreno. Anotar las tres métricas en la Search Console, grupo de páginas por grupo de páginas, y no solo en la página de inicio.
- Tratar el servidor. Versión de PHP, caché de objetos, caché de página, TTFB por debajo de 800 milisegundos. Nada más avanza mientras este punto no esté resuelto.
- Corregir el elemento LCP página por plantilla. Precarga, prioridad de recuperación, formato y dimensiones reales de la imagen.
- Eliminar los desplazamientos. Dimensiones en todas las imágenes, espacio reservado para los elementos asíncronos, fuentes precargadas y alojadas localmente.
- Hacer el inventario de los scripts de terceros. Suprimir, diferir o cargar en la interacción. Es la partida que desbloquea el INP.
- Aligerar el CSS y el JavaScript de las extensiones. Carga condicional, CSS crítico en línea, aplazamiento del resto.
- Esperar 28 días y volver a medir. Sobre los datos de campo, nunca sobre una puntuación de laboratorio.
Esta secuencia se aplica tanto a un sitio de presentación de doce páginas como a un catálogo de varios miles de referencias. Solo cambia la amplitud del trabajo por etapa. En un sitio e-commerce, la etapa tres y la etapa cinco representan por sí solas la mayoría del esfuerzo, porque las fichas de producto concentran las imágenes pesadas y los scripts de personalización.
Una observación sobre el presupuesto. El rendimiento no es una línea opcional del presupuesto, es una consecuencia de las elecciones de arquitectura hechas al principio. Un proyecto construido sobre un tema genérico comprado por 60 euros costará más caro corregirlo en tres años que un desarrollo limpio. Nuestro simulador de precio de sitio web da una horquilla realista en unos minutos, y el artículo que detalla cuánto cuesta un sitio web en 2026 explica lo que cubre cada partida.
Lo que debes recordar
Los Core Web Vitals no recompensan el rendimiento teórico, recompensan el rendimiento vivido por el cuarto menos favorecido de tus visitantes. Esta diferencia de perspectiva explica la brecha permanente entre una puntuación Lighthouse halagadora y un informe Search Console en rojo.
Tres prioridades se desprenden de la centena de auditorías que hemos realizado. El servidor primero, porque condiciona todo lo demás y ningún ajuste front compensa un TTFB degradado. El elemento LCP después, porque se corrige rápido y produce una ganancia inmediatamente medible. Los scripts de terceros por último, porque se han convertido en la primera causa de fallo desde la llegada del INP y nadie los vigila.
El resto depende de la higiene del proyecto: dimensiones en las imágenes, fuentes alojadas localmente, un espacio reservado para todo lo que llega después del primer renderizado, y el rechazo de las extensiones que prometen arreglarlo todo con una casilla de verificación. Un sitio rápido no es un sitio optimizado después, es un sitio construido correctamente. Si tus métricas siguen bloqueadas a pesar de las correcciones, el problema es estructural y la discusión versa entonces sobre la arquitectura, no sobre los ajustes.
