¿Qué son los Core Web Vitals?
Cuando un sitio web de marketing de una empresa SaaS pierde posiciones en las búsquedas a pesar de tener un contenido sólido, los Core Web Vitals suelen ser el culpable silencioso. Muchos responsables de operaciones y content managers se topan por primera vez con estas métricas en Google Search Console, marcadas como «deficientes» en páginas que habían superado todos los controles de calidad internos. Entender qué mide realmente cada métrica y dónde marca Google la línea entre aprobar y suspender es el primer paso para diagnosticar si una carencia de rendimiento técnico te está costando posiciones y registros de prueba.
Actualizado el
Respuesta rápida: los Core Web Vitals son tres métricas de Google, Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS), que miden lo rápida, receptiva y visualmente estable que resulta una página web para los visitantes reales. Google las utiliza como parte de sus señales de posicionamiento de experiencia de página, y son importantes para los sitios de marketing de SaaS porque las páginas lentas y con saltos pierden tanto visibilidad en buscadores como registros de prueba. Una página aprueba cuando al menos el 75 % de las visitas de usuarios reales obtienen una puntuación «buena» en las tres métricas.
Google introdujo los Core Web Vitals para cuantificar algo que antes era subjetivo: si una página resulta realmente agradable de usar. Para los equipos de SaaS que compiten por la visibilidad orgánica con G2, Capterra y una docena de competidores bien financiados, el rendimiento técnico ya no es una cuestión de segundo plano. Se refleja directamente en el posicionamiento, en las tasas de rebote y en la confianza que un prospecto deposita en tu producto antes de reservar una demo.
¿Cuáles son las tres métricas de los Core Web Vitals?
Los Core Web Vitals son un conjunto de métricas que miden la experiencia real del usuario en cuanto al rendimiento de carga, la interactividad y la estabilidad visual de la página. Cada métrica se centra en un momento distinto de la experiencia del visitante y tiene su propio umbral para aprobar o suspender.
Largest Contentful Paint (LCP)
Largest Contentful Paint mide el rendimiento de carga. Para ofrecer una buena experiencia de usuario, procura que el LCP se produzca en los primeros 2,5 segundos desde que la página empieza a cargarse. En un sitio de marketing de SaaS, el elemento más grande suele ser una imagen principal, una captura del producto o un titular grande. Cualquier cosa que retrase ese renderizado, como una imagen sin optimizar, un servidor lento o scripts que bloquean el renderizado, lleva el LCP a la zona de «necesita mejorar» o «deficiente».
Interaction to Next Paint (INP)
Interaction to Next Paint mide la capacidad de respuesta. Para ofrecer una buena experiencia de usuario, procura que el INP sea inferior a 200 milisegundos. El INP es la más reciente de las tres métricas. El INP sustituyó por completo al First Input Delay (FID) en marzo de 2024, así que cualquier guía que aún mencione el FID está desactualizada. A diferencia del FID, que solo registraba el primer clic o toque, el INP evalúa la latencia de todas las interacciones de la página, lo que lo convierte en una medida mucho más estricta y representativa de la capacidad de respuesta. Esto es importante en los sitios SaaS cargados de widgets de chat, calculadoras de precios y demos interactivas, ya que cada uno de esos elementos suma a la puntuación del INP.
Cumulative Layout Shift (CLS)
Cumulative Layout Shift mide la estabilidad visual. Para ofrecer una buena experiencia de usuario, procura que la puntuación del CLS sea inferior a 0,1. El CLS se dispara cuando las imágenes se cargan sin dimensiones, cuando los banners de cookies o los elementos incrustados de terceros inyectan contenido después del renderizado inicial, o cuando las fuentes web se intercambian y reorganizan la página. Un solo desplazamiento brusco, como una tabla de precios que salta al cargarse un widget de chat, puede hundir la puntuación de toda una sesión.
¿Cómo afectan los Core Web Vitals al posicionamiento en Google?
No hay una señal única. Nuestros sistemas de posicionamiento principales analizan una variedad de señales que se alinean con la experiencia general de la página. Nuestros sistemas de posicionamiento utilizan los Core Web Vitals como parte de esa evaluación. En la práctica, los Core Web Vitals funcionan más como un criterio de desempate que como una carta ganadora. Aunque los Core Web Vitals son un factor de posicionamiento, crear contenido relevante es, por supuesto, fundamental para el Search Engine Optimization, pero Google puede usar los Core Web Vitals como «desempate» entre páginas con una calidad de contenido similar.
Esta distinción importa a la hora de priorizar el tiempo en los equipos de SaaS. Una página muy rápida con contenido escaso e inútil sigue perdiendo frente a una página más lenta que responde mejor a la pregunta del usuario. Pero cuando dos competidores publican una profundidad comparable sobre la misma palabra clave de comparación, la que tiene una página más rápida y estable suele quedarse con la posición. Esta es exactamente la clase de ventaja que Seedling ayuda a identificar a los equipos de contenido de SaaS: un contenido lo bastante sólido para competir en relevancia, apoyado en una base técnica que no le haga perder esa ventaja en el margen.
El argumento de negocio va más allá del posicionamiento. En un estudio reciente con millones de impresiones de página, Google descubrió que los sitios que cumplían los umbrales de los Core Web Vitals tenían un 24 % menos de probabilidades de sufrir abandonos antes de que la página terminara de cargarse. Para un sitio SaaS que dirige tráfico de pago y orgánico a las mismas landing pages, esa diferencia de abandono se traduce directamente en inversión desperdiciada y pipeline perdido.
¿Cómo se miden los Core Web Vitals?
Google traza una línea clara entre dos tipos de datos, y confundirlos es uno de los errores más comunes en el SEO técnico.
Los datos de campo son la capa relevante para el posicionamiento. Google recopila datos de campo globales del percentil 75 de los usuarios reales que han accedido a tu aplicación en los últimos 28 días desde el navegador Chrome. Estos datos residen en el Chrome User Experience Report (CrUX) y aparecen en el informe de Core Web Vitals de Google Search Console.
Los datos de laboratorio, generados por herramientas como PageSpeed Insights o Lighthouse, son útiles para depurar, pero no determinan el posicionamiento. Las puntuaciones de Lighthouse no influyen directamente en el posicionamiento en Google. Que obtengas una puntuación de rendimiento baja en una prueba de laboratorio no significa que tu sitio vaya a salir mal parado en los datos de Core Web Vitals de usuarios reales. Es habitual que los datos de laboratorio sean muy distintos de los de usuarios reales.
Google fija la línea entre aprobar y suspender en un percentil concreto, no en un promedio. Para superar los Core Web Vitals, al menos el 75 % de tus visitantes debe tener una puntuación «buena» en LCP, INP y CLS en el conjunto de datos CrUX de Google a nivel de URL. No basta con que la página sea rápida en tu portátil de gama alta con fibra: también tiene que serlo para el cuarto usuario más lento de cada cuatro, normalmente alguien con un móvil de gama media y una conexión móvil irregular. Ese único principio explica por qué tantos sitios de marketing de SaaS superan sus propios controles de calidad internos y aun así aparecen como «deficientes» en Search Console.
¿Qué errores comunes perjudican los Core Web Vitals de los sitios SaaS?
Los sitios de marketing de SaaS suspenden los Core Web Vitals siguiendo patrones distintos a los de los sitios de ecommerce o de medios, sobre todo por el conjunto de herramientas en el que se apoyan los equipos de marketing.
- Sobrecarga de widgets de terceros. Las herramientas de chat, el software de recorridos de producto y los scripts de marketing automation bloquean el hilo principal y empeoran el INP. Cada uno añade una latencia medible a cada interacción de la página.
- Integraciones de dashboards o del producto en páginas de marketing. Las vistas previas del producto en vivo, que suelen ser el objetivo de la sección principal de una home, son con frecuencia el mayor culpable del LCP porque se cargan más despacio que una imagen estática o un vídeo.
- Ventanas modales de cookies y consentimiento. Se inyectan tarde en el ciclo de renderizado y son una de las principales causas de fallos de CLS en sitios B2B sujetos al RGPD o a requisitos de consentimiento similares.
- Probar solo la home. La home suele aprobar. Los problemas de CWV se concentran en las entradas de blog con mucho tráfico, las páginas de comparativas y las landing pages de pago, que son las que soportan más peso del tráfico orgánico y de pago.
- Fiarse de las puntuaciones de laboratorio en lugar de los datos de campo. Una puntuación verde en Lighthouse da una falsa seguridad. Solo los datos de campo de CrUX reflejan lo que Google utiliza realmente para evaluar la experiencia de página.
¿Cómo puedes mejorar los Core Web Vitals?
Arreglar el LCP suele ser la victoria más sencilla: convierte las imágenes principales a WebP o AVIF, añade atributos explícitos de ancho y alto, precarga los recursos críticos y aplaza los scripts no esenciales. El INP es más difícil y a menudo exige replantear la arquitectura de JavaScript, dividir las tareas largas, aplazar los widgets de terceros y cargar de forma diferida todo lo que no sea necesario para la primera interacción. El CLS se resuelve reservando espacio para cada imagen, anuncio y elemento incrustado antes de que se cargue, y usando font-display swap para evitar que el texto se reorganice.
La disciplina que de verdad marca la diferencia no es una solución única. Consiste en llevar los datos de campo de CrUX o de una herramienta de monitorización de usuarios reales al mismo dashboard donde ves tus métricas de contenido y tráfico, de modo que una regresión se detecte en días y no en la ventana móvil de 28 días que CrUX usa por defecto. Para los equipos de SaaS que ya usan Seedling para gestionar la producción de contenido y seguir la visibilidad orgánica, combinar ese flujo de trabajo con un monitor de Core Web Vitals cierra el círculo entre lo que publicas y cómo rinde realmente cuando visitantes reales, en dispositivos reales, cargan la página.
Los Core Web Vitals seguirán evolucionando a medida que Google afine lo que significa una «buena experiencia» en el campo. Tratarlos como una auditoría puntual en lugar de como una disciplina continua es el error que, con el tiempo, cuesta silenciosamente posiciones y conversiones a los sitios SaaS, mucho después de que se aplicara la corrección inicial.
Fuentes
- Core Web Vitals, Google Search Central
- Introducing INP to Core Web Vitals, Google Search Central
- Chrome User Experience Report (CrUX) overview, Chrome Developers
- Web Vitals, web.dev