Puntos clave
- Las Core Web Vitals son tres métricas de Google: carga (LCP), capacidad de respuesta (INP) y estabilidad visual (CLS).
- Un INP bueno es de 200 milisegundos o menos, medido en el percentil 75 de visitas reales, por separado en móvil y en escritorio.
- El INP reemplazó a First Input Delay (FID) como Core Web Vital el 12 de marzo de 2024.
- En sitios de pymes las causas típicas son plantillas pesadas, widgets de chat, pop-ups y demasiadas etiquetas de seguimiento.
- La velocidad ayuda, pero no salva un sitio que Google no puede rastrear ni páginas que no responden la búsqueda. Eso va primero.
¿Qué son las Core Web Vitals?
Las Core Web Vitals son tres mediciones que Google usa para juzgar la experiencia de una página: qué tan rápido aparece el contenido principal (LCP), qué tan rápido reacciona cuando alguien toca o hace clic (INP) y cuánto salta el diseño mientras carga (CLS). Salen de visitantes reales en Chrome, no de una prueba de laboratorio.
Las definiciones oficiales están en la página Web Vitals de web.dev. Cada métrica tiene una línea de "bueno", y Google la revisa en el percentil 75 de las cargas de página. En la práctica, al menos tres de cada cuatro visitas deben llegar a esa línea, no solo tu visita desde el internet rápido de la oficina.
| Métrica | Qué mide | Bueno | Lo que siente el visitante |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Carga del contenido principal | 2,5 segundos o menos | "Ya cargó la página." |
| INP (Interaction to Next Paint) | Respuesta a toques, clics y teclas | 200 milisegundos o menos | "El botón reacciona cuando lo toco." |
| CLS (Cumulative Layout Shift) | Estabilidad visual al cargar | 0,1 o menos | "El texto no saltó mientras leía." |
¿Qué es el INP, en palabras simples?
El INP mide cuánto tarda tu página en mostrar una reacción visible después de que alguien interactúa: abrir el menú, tocar Llamar, elegir una talla o enviar un formulario. Tiene en cuenta las interacciones de toda la visita. Si la pantalla se congela un instante después de un toque, el visitante lo nota y el INP lo registra.
Según la guía de INP de web.dev, un INP de 200 milisegundos o menos indica buena capacidad de respuesta, entre 200 y 500 milisegundos necesita mejorar y por encima de 500 milisegundos es deficiente. La misma guía explica de dónde sale la demora: tareas largas que mantienen ocupado al navegador antes de responder, el tiempo que tarda tu propio código en procesar el clic y el tiempo que necesita el navegador para pintar el siguiente cuadro.
Imagina a un cliente en el celular que toca "Reservar" y no pasa nada, así que toca otra vez y el formulario se abre dos veces. Ese es un problema de respuesta, y cuesta clientes potenciales aunque la página pareciera rápida al cargar.
¿Qué pasó con el FID?
First Input Delay (FID) era la métrica anterior de respuesta. Solo medía la demora antes de que el navegador empezara a procesar la primera interacción. Google lo reemplazó por el INP como Core Web Vital el 12 de marzo de 2024, porque el INP refleja todas las interacciones y la espera completa hasta que la pantalla cambia.
El cambio se anunció en web.dev: Interaction to Next Paint es oficialmente una Core Web Vital. Si un reporte o un plugin viejo todavía habla de FID, está desactualizado. Muchos sitios que pasaban el FID sin problema ahora fallan el INP, porque el INP también cuenta el trabajo que ocurre después del primer clic.
¿Las Core Web Vitals afectan el posicionamiento en Google?
Sí, como parte de la experiencia de página, pero no son todo. Google dice que unas buenas Core Web Vitals, junto con otros aspectos de experiencia, se alinean con lo que sus sistemas de clasificación buscan premiar. En mi experiencia, una página rápida con contenido débil sigue perdiendo contra una más lenta que responde mejor.
La página de Google Understanding Core Web Vitals and Google search results recomienda alcanzar buenos puntajes tanto para tener éxito en la Búsqueda como para dar una mejor experiencia. Yo lo leo así: la velocidad desempata en los resultados y pesa de verdad en la conversión. Una página que reacciona al instante conserva más de los visitantes que ya te costó atraer.
¿Qué suele hacer lento el sitio de una pyme?
En sitios de pymes los problemas casi nunca son raros. Los sospechosos de siempre son una plantilla o un maquetador pesado, imágenes enormes, widgets de chat y de reservas, pop-ups, sliders y un gestor de etiquetas lleno de códigos viejos. Cada uno suma scripts que compiten por el navegador justo cuando el visitante intenta tocar algo.
Plantillas y maquetadores pesados
Temas multipropósito que cargan código de funciones que nunca usas, en cada página.
Widgets de chat y reservas
Scripts de terceros que arrancan apenas abre la página, aunque nadie use el chat.
Demasiadas etiquetas
Píxeles y pruebas viejas que siguen en el gestor de etiquetas mucho después de la campaña.
Imágenes sobredimensionadas
Fotos tal como salen de la cámara, que frenan el contenido principal y dañan el LCP.
Pop-ups y sliders
Scripts grandes y, muchas veces, saltos de diseño que dañan el CLS.
Fuentes e incrustaciones sin espacio reservado
Mapas, videos y tipografías que empujan el contenido hacia abajo al llegar.
Un ejemplo real: en el sitio de una clínica médica en la que trabajé, solo las imágenes pesaban 5,85 MB. Después de comprimirlas y ajustarles el tamaño quedaron en unos 0,56 MB, sin pérdida visible de calidad. Fue uno de los diez arreglos del caso de SEO técnico de la clínica, y el más barato de todos.
¿Cómo revisar tus propias Core Web Vitals?
Abre Google Search Console y mira el informe de Core Web Vitals: agrupa tus URL en buenas, que necesitan mejorar y deficientes, con datos de visitantes reales. Luego prueba una página de cada grupo en PageSpeed Insights para ver qué métrica falla y por qué. Empieza por móvil, donde navega la mayoría de clientes locales.
- Search Console, informe de Core Web Vitals: qué grupos de páginas fallan, en móvil y en escritorio.
- PageSpeed Insights en tus páginas de entrada principales: inicio, servicios clave y productos top.
- Mira primero los datos de campo (usuarios reales). El puntaje de laboratorio es solo para diagnosticar.
- Anota la métrica que falla por plantilla, no por URL. Un arreglo en el tema suele resolver cientos de páginas.
- Vuelve a medir 28 días después de un arreglo, porque los datos de campo miran las últimas semanas de visitas.
¿Qué preguntarle a tu desarrollador?
Haz preguntas concretas ligadas a la métrica que falla, no “haz el sitio más rápido”. ¿Qué scripts corren en todas las páginas y quién los necesita todavía? ¿El chat y las reseñas pueden cargar solo tras un clic? ¿Las imágenes tienen el tamaño correcto y formatos modernos? ¿Qué interacción tiene el peor INP y qué código corre ahí?
- Pásame la lista de todos los scripts y etiquetas de terceros, con el responsable y el propósito de cada uno.
- ¿El widget de chat puede cargar cuando el visitante toca el botón de chat y no al abrir la página?
- ¿Qué interacción tiene el peor INP y qué código se ejecuta cuando ocurre?
- ¿Las imágenes están ajustadas al tamaño en que se muestran, comprimidas y con carga diferida bajo el pliegue?
- ¿Los banners, las incrustaciones y las fuentes tienen espacio reservado para que el diseño no salte?
- ¿Qué vamos a quitar, no solo optimizar? Borrar código que no se usa es la mejora más rápida.
Si la respuesta a casi todo es "eso lo hace la plantilla", el problema es la plantilla. Eso no significa automáticamente que necesites un sitio nuevo. Lee ¿necesito un sitio web nuevo para el SEO? antes de decidir.
Dónde encaja la velocidad en un plan de SEO
Trabajo en este orden: primero me aseguro de que Google pueda rastrear e indexar las páginas que venden, después de que cada página responda su búsqueda, y luego arreglo la velocidad en las plantillas que traen tráfico y clientes. La secuencia completa está en mi checklist de SEO técnico, y es como llevo cada proyecto de SEO técnico. Si estás planeando un rediseño, pon metas de Core Web Vitals en el brief, como explico en rediseño web sin perder SEO.
Mi enfoque general está en la página de consultor SEO. Si quieres que alguien revise tus cifras, una auditoría SEO técnica arranca en USD 450 (mira los precios), y el primer diagnóstico de 30 minutos es gratis desde la página de contacto.
Preguntas frecuentes
¿Hace falta un puntaje de 100 en PageSpeed?
No. El puntaje de laboratorio es para diagnosticar. Lo que cuenta son los datos de campo de visitantes reales dentro de los umbrales buenos de LCP, INP y CLS.
¿El INP importa en un sitio con pocos botones?
Sí. Menús, acordeones, enlaces de teléfono y formularios son interacciones. Un sitio pequeño con una plantilla pesada también puede tener un INP deficiente.
¿Por qué mi sitio pasa en escritorio y falla en móvil?
Los celulares tienen menos capacidad de procesamiento y conexiones más lentas, así que los mismos scripts tardan más. Google reporta móvil y escritorio por separado.
¿Un plugin de caché arregla el INP?
Casi nunca. La caché acelera la carga, pero el INP depende del código que corre cuando alguien toca. Eso exige menos JavaScript o uno más liviano.
¿Cuánto tarda Search Console en mostrar la mejora?
Los datos de campo miran las últimas semanas de visitas reales, así que cuenta con varias semanas antes de que el informe refleje el arreglo.
Sobre el autor
Juan José Giraldo es consultor SEO en Medellín, Colombia, con más de 5 años de experiencia. Trabaja el SEO técnico y local de más de 600 concesionarios en EE. UU. en una agencia Inc. 5000 y supervisa el SEO de 18 tiendas online en EE. UU. con más de 3 millones de productos. Ver más · LinkedIn.