Core Web Vitals explicados para propietarios de sitios web

Las Core Web Vitals son tres mediciones que Google utiliza para describir cómo percibe una página un visitante real: con qué rapidez aparece el contenido principal, con qué rapidez reacciona la página cuando alguien toca o hace clic y si el diseño se desplaza mientras carga. Forman parte de las señales de experiencia de página de Google, pero el motivo más importante para que te interesen es más simple. Los visitantes abandonan las páginas lentas y que saltan, y rara vez te dicen por qué.

Esta guía explica las tres métricas en lenguaje claro, los umbrales que publica Google y cómo decidir qué corregir primero en un sitio normal de una pequeña empresa.

Las tres métricas de un vistazo

Métrica	Qué mide	Buena	Mala
LCP (Largest Contentful Paint)	Tiempo hasta que se ha renderizado el elemento visible más grande	2,5 segundos o menos	Más de 4 segundos
INP (Interaction to Next Paint)	Cuánto tarda la página en responder visualmente tras un toque, un clic o una pulsación de tecla	200 milisegundos o menos	Más de 500 milisegundos
CLS (Cumulative Layout Shift)	Cuánto se mueve de forma inesperada el contenido visible	0,1 o menos	Más de 0,25

Los valores entre “buena” y “mala” caen en una franja de “necesita mejorar”. Google evalúa una página en el percentil 75 de las visitas reales, lo que significa que tres cuartas partes de tus visitantes deberían tener una experiencia igual o mejor que el umbral. Una sola prueba rápida en tu propio portátil no demuestra que la página lo cumpla.

Largest Contentful Paint: ¿aparece la página?

El LCP observa la imagen, el póster de vídeo o el bloque de texto más grande de la primera pantalla y registra cuándo termina de renderizarse. En la mayoría de los sitios es una imagen principal o un titular grande. Un LCP lento suele deberse a una de cuatro causas: una respuesta lenta del servidor, una imagen pesada o mal formateada, CSS o JavaScript que bloquean el renderizado, o que el navegador descubre demasiado tarde la imagen clave.

Interaction to Next Paint: ¿responde la página?

El INP sustituyó en marzo de 2024 a la antigua métrica First Input Delay. Mientras que First Input Delay miraba solo la primera interacción y solo el retraso antes de que empezara, el INP considera las interacciones durante toda la visita e informa de una de las más lentas, desde la entrada hasta que se dibuja el siguiente fotograma. Las páginas que cargan rápido pero se sienten torpes al abrir un menú o pulsar un botón suelen tener un problema de JavaScript: demasiado código ejecutándose a la vez en el hilo principal.

Cumulative Layout Shift: ¿se mantiene quieta la página?

El CLS suma el movimiento inesperado de los elementos visibles. Lo has sentido cuando ibas a tocar un enlace y se cargó un banner encima, empujando el enlace hacia abajo. Los desencadenantes habituales son imágenes sin atributos de ancho y alto, anuncios e incrustaciones que cargan tarde, fuentes que se intercambian y cambian el tamaño del texto, y banners de cookies inyectados en la parte superior de la página.

Datos de laboratorio frente a datos de campo

Hay dos tipos de medición, y mezclarlos genera confusión.

• Los datos de campo provienen de visitantes reales que usan dispositivos y redes reales. Google los recopila de los usuarios de Chrome y los muestra en PageSpeed Insights y Search Console cuando tu sitio tiene suficiente tráfico. Es lo que cuenta para la evaluación.
• Los datos de laboratorio provienen de una prueba simulada, como Lighthouse. Son reproducibles, lo que los hace ideales para depurar, pero corresponden a un dispositivo en una conexión.

Un sitio pequeño puede no tener datos de campo en absoluto. En ese caso, usa las pruebas de laboratorio para encontrar problemas y trata los resultados como orientación, no como veredicto.

Por dónde empezar a corregir

1. Mide las páginas que importan. Prueba tu página de inicio, tu página de destino más visitada y un artículo o página de producto típicos con un perfil móvil. No promedies todo el sitio.
2. Corrige primero la métrica más lenta. Si el LCP es malo y el CLS está bien, trabaja en el LCP.
3. Empieza por las mejoras baratas. Comprime y redimensiona la imagen principal, define las dimensiones de las imágenes, activa la caché, considera una CDN y elimina los plugins o scripts que ya no uses.
4. Vuelve a medir tras cada cambio. Cambia una sola cosa a la vez para saber qué ayudó.
5. Espera a que los datos de campo se pongan al día. Las cifras del mundo real se recopilan durante un periodo móvil, por lo que las mejoras tardan unas semanas en reflejarse por completo.

Qué tiene que ver el hosting

Las Core Web Vitals dependen sobre todo de cómo está construida una página, pero el hosting marca el suelo. Una respuesta lenta del servidor retrasa todo lo que viene después, lo que perjudica directamente al LCP. Los servidores saturados, las versiones obsoletas de PHP y la falta de caché en el servidor añaden tiempo antes de que el navegador reciba el primer byte. Un buen trabajo en el front-end no puede compensar del todo un back-end lento.

Una expectativa realista

Superar las tres métricas es un objetivo que vale la pena, pero no es un interruptor mágico de posicionamiento. La relevancia del contenido sigue importando mucho más. Piensa en las Core Web Vitals como una forma de eliminar fricción: no harán que una página débil se posicione, pero una página lenta y que salta hace más difícil conservar a los visitantes que ya te ganaste.

Errores comunes de los propietarios de sitios

• Perseguir una puntuación perfecta en Lighthouse. Un 100 en una prueba de laboratorio no es el objetivo. Lo es cumplir los tres umbrales con visitantes reales.
• Probar solo en escritorio. La mayor parte de la evaluación se hace en móvil, y los dispositivos móviles tienen procesadores y conexiones más lentos.
• Instalar un plugin de velocidad y quedarse ahí. Los plugins pueden ayudar con la caché y el manejo de imágenes, pero no pueden eliminar una imagen principal de 3 MB ni una docena de scripts de marketing.
• Ignorar las plantillas. Las páginas construidas con la misma plantilla suelen compartir los mismos problemas, así que arreglar la plantilla arregla muchas páginas a la vez. Search Console agrupa URL similares precisamente por eso.

Mantén un registro sencillo de lo que cambiaste y de la puntuación antes y después. Ahorra conjeturas cuando algo empeora tras la actualización de un plugin.

Las páginas rápidas empiezan en el servidor

En Zebra Hosting Cloud, todos los planes incluyen el panel de control Plesk, donde puedes elegir versiones actuales de PHP, y la CDN de Cloudflare está disponible en los sitios alojados para servir los archivos estáticos más cerca de los visitantes. En conjunto, esto cubre el lado del servidor de la ecuación para que puedas concentrarte en la propia página. Consulta lo que ofrece cada plan en la página general de hosting.