El dueño de un e-commerce de repuestos de electrodomésticos me pasó una captura de Google Search Console hace un par de meses. En la columna de Core Web Vitals, sobre un fondo rojo intenso, aparecían 847 URLs clasificadas como “Poor”. Me preguntó si eso explicaba por qué, desde hacía tres meses, el tráfico orgánico venía bajando sin que hubiera cambiado nada en el catálogo, en los precios ni en la inversión en anuncios. La respuesta fue sencilla: “Es exactamente eso. Tus páginas están rindiendo mal según los estándares que Google define como aceptables, y el algoritmo te está corriendo de las posiciones donde estabas.”
Lo que siguió fue una conversación técnica que el tipo no debería haber necesitado tener. Su sitio había sido armado con una plantilla de WordPress, tres constructores visuales distintos según la sección y dieciocho plugins activos. Nadie le había explicado, cuando lo contrató, que el rendimiento web iba a convertirse en un factor de posicionamiento tan concreto como lo son hoy los backlinks o la intención de búsqueda.
Los Core Web Vitals no son una métrica más para desarrolladores. Son la forma en que Google mide si un sitio ofrece una experiencia de usuario aceptable en términos de velocidad de carga, capacidad de respuesta e interactividad y estabilidad visual. Y desde que forman parte del algoritmo de ranking, ignorarlos no es una opción para ninguna empresa que dependa del tráfico orgánico.
“Un sitio lento no solo frustra a los usuarios. También le está diciendo a Google que no merece estar en la primera página de resultados.”
Qué son los Core Web Vitals y por qué Google los convirtió en prioridad
Durante años, Google midió la relevancia de una página mirando señales como la densidad de palabras clave, la autoridad del dominio y la estructura de enlaces entrantes. Esas señales siguen siendo importantes, pero no alcanzan para garantizar una buena experiencia de usuario. Una página puede tener el contenido más relevante del mundo para una búsqueda; si tarda ocho segundos en cargar, el usuario se va antes de leerlo.
Google lo sabe porque tiene acceso a datos de comportamiento real de millones de usuarios a través de Chrome. Sabe cuánto tarda en promedio cada página en mostrar algo útil, cuánto demora en responder a un clic y cuántas veces un usuario intenta tocar un botón y termina tocando otra cosa porque la página se movió mientras cargaba. Esas observaciones se convirtieron en tres métricas estandarizadas que forman los Core Web Vitals:
- LCP (Largest Contentful Paint): mide cuánto tarda en renderizarse el elemento de contenido más grande visible en la pantalla. Es la métrica que le dice al usuario “esta página cargó”.
- INP (Interaction to Next Paint): mide la capacidad de respuesta de la página a las interacciones del usuario. Reemplazó al FID (First Input Delay) en marzo de 2024 porque captura mejor la experiencia completa de uso, no solo la primera interacción.
- CLS (Cumulative Layout Shift): mide la estabilidad visual. Cuantifica cuánto se mueven los elementos de la página durante la carga. Es la métrica que explica por qué tocaste “Cancelar” cuando ibas a tocar “Confirmar”.
Cada una de estas métricas tiene umbrales definidos por Google. Un LCP por debajo de 2.5 segundos es “Good”, entre 2.5 y 4 segundos es “Needs Improvement”, y arriba de 4 segundos es “Poor”. Para el INP, el umbral de “Good” está en 200 milisegundos o menos. Para el CLS, un puntaje de 0.1 o menos se considera aceptable. Superar estos umbrales no es un lujo técnico: es la diferencia entre que Google te muestre o te entierre.
LCP: la primera impresión de tu sitio se mide en segundos
El Largest Contentful Paint responde una pregunta simple: ¿cuánto tarda tu página en mostrar el contenido principal? Ese contenido suele ser una imagen hero, un título grande o un bloque de texto destacado. Si tarda más de 2.5 segundos en aparecer, Google considera que la experiencia de carga es deficiente.
Lo interesante del LCP es que no mide cuánto tarda en cargar la página completa. Mide cuánto tarda en aparecer lo que el usuario ve primero. Una página puede tener el footer, los scripts de analytics y los comentarios todavía cargándose en segundo plano, pero si el contenido principal ya está visible, el LCP es bueno. El problema es que la mayoría de las plantillas genéricas cargan todo junto y en el orden equivocado.
Estas son las causas más comunes de un LCP alto cuando trabajás con plantillas o constructores visuales:
- Imágenes no optimizadas que se cargan en tamaño original y se redimensionan con CSS. Una foto de 4000 píxeles de ancho que se muestra en un contenedor de 800 píxeles obliga al navegador a descargar cinco veces más datos de los necesarios, decodificar una imagen enorme y después escalarla.
- JavaScript que bloquea el renderizado. Cuando un plugin de chat, un tracker de marketing o un script de animación se cargan antes que el contenido principal, el navegador espera a ejecutarlos antes de mostrar nada útil.
- Tiempos de respuesta del servidor lentos. Si el hosting es compartido o el backend procesa cada request sin cache, el navegador puede estar listo para pintar la página pero no recibe los datos a tiempo.
- Carga secuencial de recursos. El navegador descubre una hoja de estilos, la descarga, descubre que referencia una fuente, la descarga, y recién después renderiza el texto. Mientras tanto, la pantalla está en blanco.
En un desarrollo con Next.js, varias de estas causas desaparecen por arquitectura. El renderizado del lado del servidor (SSR) envía HTML ya procesado al navegador, así que el contenido principal llega en el primer viaje de datos, no después de ejecutar JavaScript. Las imágenes se pueden servir en formato WebP o AVIF con tamaños predefinidos por dispositivo usando el componente next/image. Y con ISR (Incremental Static Regeneration), las páginas que no cambian con cada visita se sirven como contenido estático desde un CDN, con tiempos de respuesta de milisegundos.
INP: la métrica que te dice si tu sitio responde o se queda pensando
El Interaction to Next Paint mide algo que cualquier persona que usa internet todos los días conoce por instinto: la diferencia entre un sitio que reacciona instantáneo cuando hacés clic y uno que se queda congelado medio segundo antes de hacer algo. Esa pausa, que técnicamente es el tiempo que transcurre entre la interacción del usuario y el siguiente fotograma que pinta el navegador, es lo que el INP cuantifica.
Google eligió el INP para reemplazar al FID porque el FID solo miraba la primera interacción, y era fácil de trucar. Una página podía retrasar todo el JavaScript pesado para después del primer clic, pasar el FID con buena nota y después funcionar como el orto durante el resto de la sesión. El INP, en cambio, observa todas las interacciones —clics, toques, pulsaciones de teclado— durante toda la visita y reporta la peor de todas, o una cercana a la peor.
Las causas de un INP alto se reducen casi siempre a JavaScript mal administrado:
- Tareas largas que bloquean el hilo principal. Si un script de tracking, una animación o un cálculo en el frontend ocupa el procesador durante 300 milisegundos, cualquier interacción del usuario durante ese lapso se encola y se ejecuta con retraso.
- Código de terceros sin control. Plugins de chat en vivo, banners de cookies, widgets de redes sociales. Cada uno inyecta su propio JavaScript, muchas veces sin que el desarrollador de la plantilla haya previsto cómo interactúan entre sí.
- Event listeners mal optimizados. Cuando cada clic dispara una cascada de funciones que recalcula el layout completo de la página, la respuesta se degrada rápido.
- Demasiado código ejecutándose en el cliente. Si la lógica de filtrado de productos, validación de formularios o actualización del carrito corre en el navegador del usuario en vez de resolverse en el servidor, cada interacción suma tiempo de proceso.
Next.js ataca el INP desde dos frentes. El primero es la hidratación progresiva: en vez de cargar e inicializar todo el JavaScript de una página de una sola vez, los componentes interactivos dentro de una página que es mayoritariamente estática se hidratan a demanda. El segundo es React Server Components, que permiten ejecutar lógica en el servidor y mandar al cliente solo el HTML resultante, sin una gota de JavaScript innecesario. En criollo: el navegador hace menos trabajo pesado, así que cuando el usuario hace clic, el hilo principal está libre para responder.
CLS: cuando tu página baila y el usuario se va
El Cumulative Layout Shift es la métrica más subestimada de las tres y probablemente la que más conversiones destruye sin que nadie lo note. Mide cuánto se mueven los elementos visibles de una página durante la carga. Ese movimiento es el responsable de que un usuario toque “Agregar al carrito” y termine en “Eliminar de favoritos” porque un banner publicitario se cargó un segundo después y empujó todo hacia abajo.
Google penaliza el CLS porque degrada la experiencia de usuario de forma concreta. Un estudio interno de Google de 2024 mostró que las páginas con CLS alto tienen una tasa de rebote entre un 15% y un 25% mayor que las páginas con CLS bueno, incluso cuando el contenido de ambas es equivalente.
Las causas de un CLS alto suelen ser fáciles de identificar pero difíciles de resolver en una plantilla:
- Imágenes sin dimensiones declaradas. Si el HTML no especifica ancho y alto, el navegador reserva cero píxeles para la imagen, renderiza el contenido que está arriba, y cuando la imagen se descarga la mete a presión desplazando todo lo demás.
- Fuentes web que se cargan tarde. El navegador muestra el texto con una fuente del sistema, calcula las posiciones, y cuando la fuente custom llega la aplica —y si las métricas de las dos fuentes son distintas, todo el párrafo se reacomoda.
- Contenido dinámico inyectado sin aviso. Banners de promociones, barras de notificación, CTAs flotantes que se insertan después del renderizado inicial sin reservar su espacio de antemano.
- Anuncios o iframes que ajustan su tamaño después de cargar. Un embed de YouTube o un banner de display que primero ocupa 0 píxeles y después 250 píxeles es un generador automático de CLS.
Resolver el CLS de verdad requiere control sobre cómo y cuándo se renderiza cada elemento, algo que una plantilla genérica no puede garantizar porque no sabe qué contenido concreto vas a poner. Un desarrollo a medida, en cambio, puede planificar el espacio de cada componente desde el diseño, reservar placeholders del tamaño exacto para cada imagen, precargar las fuentes críticas y asegurarse de que nada se inyecta en el layout sin un contenedor que ya ocupe su lugar.
Por qué Next.js saca ventaja en Core Web Vitals frente a las plantillas genéricas
Si llegaste hasta acá, probablemente notaste un patrón. Muchas de las causas de mal rendimiento en LCP, INP y CLS están relacionadas con la forma en que las plantillas y los constructores visuales manejan los recursos: cargan de más, cargan en el orden equivocado, cargan código que no saben si van a usar y le delegan al navegador del usuario decisiones que debería tomar el servidor.
Next.js no es mágico, pero su arquitectura está diseñada para resolver estos problemas desde la base, no parchándolos después:
Para el LCP, el SSR y el SSG (Static Site Generation) entregan HTML pre-renderizado. El navegador no tiene que esperar a que JavaScript termine de ejecutarse para mostrar contenido útil. Si la página es estática, se sirve desde un CDN global con latencias mínimas. Si es dinámica, el servidor resuelve la lógica y manda HTML listo. En ambos casos, el componente next/image automatiza la generación de versiones en múltiples tamaños y formatos modernos como WebP y AVIF, que pesan entre un 30% y un 50% menos que un JPEG equivalente. Como explicamos en Next.js y desarrollo web a medida: por qué las empresas están dejando las plantillas, esta diferencia de arquitectura tiene un impacto directo en el rendimiento y en el SEO técnico.
Para el INP, la división automática de código (code splitting) por página y por componente garantiza que el usuario solo descarga el JavaScript que necesita para la página que está viendo. React Server Components permite que la lógica pesada —consultas a base de datos, formateo de datos, renderizado inicial— se ejecute en el servidor. El navegador recibe HTML y solo hidrata los componentes interactivos. Menos JavaScript en el cliente significa menos tareas largas y mejor capacidad de respuesta.
Para el CLS, el control granular sobre el markup y los estilos permite declarar dimensiones explícitas para cada imagen, placeholder y componente dinámico. Las fuentes se pueden precargar con next/font, que las auto-hospeda y las optimiza eliminando la latencia de Google Fonts. No hay sorpresas de terceros que inyecten DOM sin previo aviso.
La diferencia práctica es medible. En nuestra experiencia, un sitio migrado de una plantilla de WordPress con plugins a Next.js con una arquitectura bien implementada suele pasar de métricas “Poor” o “Needs Improvement” a “Good” en las tres categorías de Core Web Vitals, y lo hace de forma consistente, no como un pico puntual después de una optimización express.
Cómo medir y monitorear los Core Web Vitals de tu sitio
No hace falta ser desarrollador para saber si tu sitio está aprobando o no en Core Web Vitals. Google ofrece herramientas gratuitas que te dan una foto clara en menos de un minuto:
- PageSpeed Insights: ingresás la URL, te devuelve un puntaje de rendimiento de 0 a 100 y desglosa los resultados de LCP, INP y CLS con datos de campo (experiencia real de usuarios de Chrome) y de laboratorio (simulación en un entorno controlado). Es el punto de partida más rápido para un diagnóstico inicial.
- Google Search Console > Core Web Vitals: te muestra, para todo tu sitio, cuántas URLs están en “Good”, “Needs Improvement” o “Poor”. Si tenés cientos de URLs en rojo, el algoritmo ya lo sabe y está actuando en consecuencia.
- Lighthouse: integrado en Chrome DevTools, permite auditar cualquier página simulando condiciones de red y dispositivo. Es más detallado que PageSpeed Insights y te da recomendaciones específicas sobre qué arreglar.
- Web Vitals Extension: una extensión de Chrome que te muestra las métricas en tiempo real mientras navegás tu propio sitio. Útil para detectar problemas que aparecen solo en flujos específicos, como un checkout o un formulario complejo.
La clave no es medir una vez y olvidarse. Los Core Web Vitals se degradan con el tiempo si nadie los monitorea: un plugin que se actualiza, una integración nueva que inyecta JavaScript, imágenes que alguien sube sin optimizar. Incorporar estas mediciones como parte del mantenimiento periódico del sitio es lo que separa a las empresas que sostienen su posicionamiento de las que lo pierden sin entender por qué.
Un sitio rápido no es un capricho técnico ni una carrera por ver quién saca 100 en PageSpeed Insights. Es una decisión de negocio que impacta en el tráfico orgánico, en la tasa de conversión y en la percepción de profesionalismo de tu empresa. La buena noticia es que los Core Web Vitals no son un misterio: se miden con herramientas gratuitas, se entienden con conceptos accesibles y se resuelven con decisiones de arquitectura tomadas desde el inicio, no con parches aplicados sobre la marcha.
En Gambit Lab trabajamos con Next.js justamente porque creemos que el rendimiento web no debería ser un problema que el cliente descubre seis meses después, cuando Google ya le bajó el tráfico y las conversiones cayeron. Es un atributo del producto desde el día uno, como la identidad visual o la estrategia de contenido. Si querés saber cómo está tu sitio hoy en Core Web Vitals y qué impacto puede estar teniendo en tus resultados, escribinos. Una auditoría inicial no te compromete a nada y te deja información concreta para decidir.