Core Web Vitals explicados: qué son y cómo acelerar tu sitio web

Tu sitio puede verse precioso y aun así perder clientes en los primeros tres segundos. Google mide esa experiencia con tres números llamados Core Web Vitals, y en esta guía vas a entender qué significa cada uno, cómo revisarlos gratis y qué arreglar primero, sin necesidad de saber programar.

La escena es conocida: alguien te encuentra en Google Maps, toca el enlace a tu página desde su celular, con señal de dos rayitas, mientras espera en un semáforo de la avenida Tulum. La pantalla se queda en blanco, luego aparece el menú, luego el texto brinca porque llegó una foto enorme, y cuando por fin intenta tocar el botón de WhatsApp, la página tarda en reaccionar. Esa persona ya se fue. No se quejó, no dejó reseña: simplemente regresó a los resultados y tocó al siguiente.

Los Core Web Vitals ponen nombre y medida a ese momento. Son la traducción en números de una pregunta muy de negocio: ¿tu sitio trata bien a quien llega con prisa?

01Antes de empezar: lo que necesitas

• La dirección de tu sitio y, si puedes, de tus tres páginas más visitadas (la de inicio, la de servicios o menú y la de contacto suelen ser las clave).
• Acceso a Google Search Console si ya lo tienes configurado. Si no, no pasa nada; puedes empezar sin él.
• Un celular de gama media. Revisar tu sitio solo desde la laptop de la oficina, conectada a fibra, es la forma más rápida de engañarte.

02Qué miden los Core Web Vitals

Google agrupa tres métricas, y cada una responde a una sensación distinta del visitante. Según la guía oficial de Web Vitals en web.dev, se evalúan en el percentil 75 de las visitas reales, separando celular y computadora. Dicho de otra forma: tu sitio tiene que portarse bien también con quien tiene un teléfono modesto y mala señal.

1. LCP: cuánto tarda en aparecer lo importante

LCP significa Largest Contentful Paint, y mide cuánto tarda en mostrarse el elemento más grande de la pantalla inicial: casi siempre la foto principal, un video de portada o un bloque grande de texto. Es la respuesta a «¿ya cargó?».

De acuerdo con la documentación de LCP en web.dev, un LCP bueno es de 2.5 segundos o menos; entre 2.5 y 4 segundos necesita mejorar, y arriba de 4 segundos se considera deficiente.

Imagina, como ejemplo, una boutique de trajes de baño en Playa del Carmen cuya portada es una foto enorme tomada con cámara profesional, sin comprimir. Logotipo, menú y botones llegan en un instante, pero mientras la foto no aparezca, el visitante siente que la página no ha cargado.

El error común es culpar de todo al hosting, cuando muchas veces el problema es una sola imagen o un video de fondo.

2. INP: qué tan rápido responde cuando la tocas

INP significa Interaction to Next Paint y reemplazó a una métrica anterior llamada FID. Mide el tiempo entre que alguien toca, da clic o escribe, y el momento en que la página muestra una reacción visible. Es la respuesta a «¿sí me hizo caso?».

Según la documentación de INP en web.dev, un INP de 200 milisegundos o menos es bueno; entre 200 y 500 milisegundos necesita mejorar, y por encima de 500 milisegundos es deficiente.

Piensa en un restaurante con un menú digital donde cada categoría se abre con un toque. Si al tocar «Mariscos» la pantalla se congela antes de desplegar los platillos, el comensal vuelve a tocar y la experiencia se siente torpe aunque la página haya cargado rápido. Ese retraso suele venir de demasiado código ejecutándose a la vez, muchas veces de herramientas de terceros: chats emergentes, ventanas de cookies, píxeles de publicidad, widgets de reseñas.

El error común aquí es instalar «solo un complemento más». Cada uno parece inofensivo; juntos le quitan al navegador la capacidad de responder a tiempo.

3. CLS: qué tanto se mueve la página mientras carga

CLS significa Cumulative Layout Shift y mide los saltos inesperados del contenido. Es la respuesta a «¿por qué se movió todo justo cuando iba a tocar?».

La documentación de CLS en web.dev marca como bueno un valor de 0.1 o menos y como deficiente cualquier valor mayor a 0.25; lo que queda en medio necesita mejorar. Ahí mismo se explican las causas más frecuentes: imágenes o videos sin dimensiones definidas, anuncios o widgets que cambian de tamaño solos, contenido que se inserta arriba del que ya estaba y tipografías que, al terminar de cargar, se ven más grandes o más chicas que la letra provisional.

Como ejemplo, imagina una clínica dental cuya página de inicio muestra primero el texto «Agenda tu cita», y medio segundo después aparece encima un banner de promoción que empuja todo hacia abajo. Quien iba a tocar «Agendar» termina tocando el teléfono de otra sucursal.

El error común es revisar solo en una computadora potente, donde los saltos ni se notan. En un celular con señal lenta, el mismo sitio baila.

Un sitio rápido no se nota; uno lento se nota siempre.

03Cómo revisar tu sitio paso a paso

1. Mide con PageSpeed Insights

Entra a PageSpeed Insights, pega la dirección de tu página de inicio y espera el análisis. Verás dos bloques que conviene no confundir:

• Datos de usuarios reales. Arriba aparece, si tu sitio tiene suficientes visitas, la evaluación de los Core Web Vitals con datos de personas que de verdad entraron a tu página recientemente. Este es el resultado que importa.
• Diagnóstico de laboratorio. Abajo hay una simulación con una calificación de 0 a 100 y una lista de oportunidades. Sirve para encontrar causas, pero es una prueba de un solo momento y puede variar de una corrida a otra.

Si tu sitio es nuevo o tiene pocas visitas, quizá no veas datos reales. En ese caso, trabaja con el diagnóstico de laboratorio y repite la medición varias veces para no reaccionar a un resultado aislado.

Revisa siempre la pestaña de celular primero. Es donde llega la mayoría de la gente que te busca por Maps o desde un anuncio en Instagram, y es donde los problemas se ven más.

2. Revisa el informe de Search Console

Si tienes Search Console, abre el informe de Core Web Vitals. Ahí Google agrupa las páginas de tu sitio que comparten problemas parecidos y las clasifica como buenas, que necesitan mejorar o deficientes. Es útil porque te dice si el problema es de una sola página o de una plantilla que se repite, por ejemplo, todas las fichas de producto o todos los artículos del blog.

3. Anota el culpable de cada métrica

En tu libreta, tres renglones: para LCP, cuál es el elemento más grande (el diagnóstico lo señala); para INP, qué código de terceros carga la página; para CLS, qué elementos se mueven. Parece burocrático, pero te ahorra el error más caro: arreglar cosas que no eran el problema.

4. Prueba con tus propios ojos en el celular

Abre tu sitio en el celular con los datos móviles, no con el wifi de la oficina. Pon atención a tres momentos: cuándo sientes que ya cargó, si algo se movió de lugar y si los botones responden en cuanto los tocas. Pídele a alguien que nunca ha visto tu página que intente contactarte desde ahí y obsérvalo sin ayudarle.

04Qué arreglar primero, en orden de impacto

No todo pesa igual. Este orden suele dar el mayor cambio con el menor esfuerzo.

1. Adelgaza las imágenes

Es la mejora más rentable y la puedes hacer tú. Exporta las fotos al tamaño en que realmente se ven (una foto que se muestra a lo ancho de un celular no necesita el tamaño de un cartel espectacular) y guárdalas en formatos modernos como WebP o AVIF. Herramientas gratuitas como Squoosh te dejan comparar calidad y peso lado a lado antes de descargar.

Dos reglas más que tu desarrollador debe aplicar: la imagen principal de cada página debe cargarse con prioridad, no de manera diferida, y todas las demás imágenes (las que están más abajo) sí pueden esperar a que el visitante haga scroll.

2. Reserva el espacio de cada elemento

Para frenar los saltos, cada imagen, video, mapa o banner debe tener reservado su espacio antes de cargar. En la práctica, esto significa indicar ancho y alto en el código, o una proporción fija, para que el navegador sepa cuánto lugar dejar. Si usas avisos de promoción o de cookies, que aparezcan encima del contenido en una capa, no empujándolo.

3. Haz limpieza de herramientas de terceros

Haz una lista de todo lo que se instaló en tu sitio con los años: chat, píxel de Meta, etiquetas de Google, mapas de calor, widgets de reseñas, botones de redes, encuestas. Para cada uno pregúntate: ¿alguien revisa los datos que genera?, ¿me trae clientes?, ¿lo puedo cargar después de que la página ya esté lista? Lo que nadie usa, se va. Lo que sí sirve, que se cargue cuando no estorbe.

4. Cuida el video de portada

Un video a pantalla completa en la portada puede ser hermoso y a la vez convertirse en el elemento más pesado de tu página. Si lo mantienes, que sea corto, sin audio, comprimido y con una imagen fija de portada ligera que aparezca de inmediato. En celular, muchas veces la mejor decisión es mostrar solo esa imagen.

5. Revisa tipografías, servidor y plataforma

Aquí ya conviene la ayuda de quien hizo tu sitio: limitar las variantes de tipografía que se descargan, servir las fuentes desde tu propio dominio, usar un hosting con caché y una red de distribución de contenido, y revisar si la plataforma o el tema que usas carga código que no necesitas. Si la plantilla arrastra funciones que nadie pidió, a veces es más sensato reconstruir sobre una base ligera que seguir parchando.

05Errores frecuentes al trabajar la velocidad

• Obsesionarse con llegar a 100 en la calificación de laboratorio. La meta real es que los datos de usuarios reales estén en verde.
• Medir solo la página de inicio. Las páginas de servicios, productos o menú suelen ser las más pesadas y las que más venden.
• Revisar en computadora y olvidar el celular.
• Instalar un complemento de «optimización» encima de otros diez. Más código para arreglar el exceso de código rara vez funciona.
• Cambiar muchas cosas a la vez y no saber cuál funcionó. Haz un cambio, mide, anota.
• Olvidar que los datos reales tardan en actualizarse. Después de una mejora, dale unas semanas antes de juzgar el informe de Search Console.

06Un sitio pensado para ser ligero desde el principio

La velocidad es mucho más fácil de cuidar cuando se decide desde la planeación y no al final. Si estás por construir o rehacer tu página, vale la pena leer primero cómo planear un sitio web con estructura y contenido claros, porque cada sección que no necesitas es peso que te ahorras. Y si tu negocio depende de que te encuentren en el mapa, la velocidad se suma a todo lo que vimos en la guía de SEO local y Perfil de Negocio.

En BDB construimos sitios web en código propio, sin plantillas cargadas de funciones de más, precisamente para que carguen rápido en el celular de quien te busca. Si quieres que revisemos el tuyo, escríbenos.

07Preguntas frecuentes

¿Qué son los Core Web Vitals en palabras simples?

Son tres medidas que Google usa para describir la experiencia real de quien visita tu sitio: qué tan rápido aparece lo principal (LCP), qué tan rápido responde a un toque o clic (INP) y qué tan quieta se mantiene la página mientras carga (CLS). Se calculan con datos de visitantes reales, no con una sola prueba en tu computadora.

¿Cuáles son los valores buenos de LCP, INP y CLS?

Según la documentación oficial de Google en web.dev, un LCP bueno es de 2.5 segundos o menos, un INP bueno es de 200 milisegundos o menos y un CLS bueno es de 0.1 o menos. Se evalúan en el percentil 75 de las visitas, separando celular y computadora.

¿Los Core Web Vitals afectan mi posicionamiento en Google?

Google recomienda lograr buenos Core Web Vitals y dice que, junto con otros aspectos de experiencia de página, se alinean con lo que sus sistemas de clasificación buscan premiar. También aclara que siempre intenta mostrar el contenido más relevante, aunque la experiencia sea mejorable. Un sitio rápido no compensa un contenido pobre, pero sí evita que pierdas visitantes y te ayuda a destacar frente a opciones parecidas.

¿Puedo mejorar los Core Web Vitals sin ser programador?

Sí, una parte importante. Comprimir imágenes, quitar complementos que no usas, reducir videos de fondo y revisar los chats o anuncios que se cargan de terceros está al alcance de cualquier dueño de negocio. Los ajustes de código, servidor y tipografías conviene dejarlos a quien desarrolló el sitio.

08Fuentes

• Web Vitals, web.dev
• Largest Contentful Paint (LCP), web.dev
• Interaction to Next Paint (INP), web.dev
• Cumulative Layout Shift (CLS), web.dev
• Core Web Vitals y los resultados de búsqueda, Google Search Central
• Experiencia de página en la Búsqueda de Google, Google Search Central
• Informe de Core Web Vitals en Search Console, Ayuda de Google
• PageSpeed Insights