En resumen
Qué se mide
LCP (velocidad de carga), CLS (estabilidad visual) y TBT (capacidad de respuesta).
Valores buenos
LCP de 2,5 segundos o menos, CLS de 0,1 o menos, TBT por debajo de 200 milisegundos.
Por qué importa
Google declara que usa las Core Web Vitals en sus sistemas de posicionamiento.
Severidad en Wakaris
Crítico. Es el hallazgo que más se repite: falla en el 96 % de las páginas analizadas.
Qué es y qué mide este hallazgo
Este hallazgo salta cuando alguna de las tres métricas de rendimiento de tu página se sale de su umbral. Cada una mira una cosa distinta y conviene no confundirlas.
El LCP, o Largest Contentful Paint, mide el tiempo hasta que se muestra el elemento visible más grande de la página, que suele ser una imagen destacada o un bloque de texto principal. Es el momento en que la página parece cargada.
El CLS, o Cumulative Layout Shift, mide cuánto se mueve el contenido de sitio sin que nadie lo haya pedido: el botón que se desplaza justo cuando vas a pulsarlo. No es un tiempo, es una puntuación que se calcula multiplicando la parte de la pantalla afectada por la distancia que se ha movido.
El TBT, o Total Blocking Time, mide cuánto tiempo estuvo el navegador demasiado ocupado para responder. Suma los tramos de las tareas largas, las que pasan de 50 milisegundos, contando solo lo que exceden de ese medio décimo de segundo.
Cómo se mide
Wakaris mide las tres sobre la URL que le indiques y te devuelve el valor de cada una, el umbral que incumple y la severidad del hallazgo, sin instalar nada. Esa es la vía directa para saber en qué punto estás.
Hay un detalle que cambia cómo se leen los números. Las Core Web Vitals son tres: LCP, INP y CLS. El INP, que mide la respuesta a las interacciones, requiere una persona interactuando de verdad, así que ninguna medición automática lo obtiene. En su lugar se usa el TBT, que es su sustituto de laboratorio: la documentación de Google lo describe como un proxy de INP. Por eso Wakaris mide LCP, CLS y TBT, y no INP.
La otra distinción es entre laboratorio y campo. Wakaris carga tu página en condiciones controladas, que es lo que sirve para diagnosticar y para comprobar si un arreglo funcionó. Los datos de campo agregan las cargas reales de tus visitantes, y son los que Google usa para evaluar la experiencia de página: fija el umbral en el percentil 75 de esas cargas y separa móvil de escritorio. Aprobar en escritorio y suspender en móvil es lo habitual.
Por qué importa
Importa en dos frentes, y conviene medir el peso de cada uno con precisión.
El primero es la experiencia de quien entra. Cuanto más tarda en aparecer lo principal, más probable es que se vaya antes de verlo. Si el contenido se mueve mientras carga, se pulsa lo que no se quería pulsar. Y si el navegador está bloqueado, la página parece rota aunque se vea entera.
El segundo es el posicionamiento, y aquí hay que ser exacto para no prometer de más. Google declara en su documentación que las Core Web Vitals las usan sus sistemas de posicionamiento. Pero añade algo igual de importante: la búsqueda siempre trata de mostrar el contenido más relevante, incluso si la experiencia de página es mediocre, y una buena experiencia contribuye al éxito sobre todo cuando hay mucho contenido útil compitiendo por la misma consulta. Dicho en claro: un buen rendimiento no rescata a un contenido flojo, pero un rendimiento malo sí puede frenar una página que por lo demás es excelente, y frena más cuanto más reñida está la búsqueda.
Causas comunes
Las tres métricas fallan por motivos distintos, y ese es el primer paso para no perder tiempo.
Detrás de un LCP alto hay casi siempre una de estas cuatro: un servidor que tarda en responder, imágenes pesadas o en formatos poco eficientes, recursos que bloquean el pintado porque el navegador tiene que procesarlos antes de dibujar nada, o una página que depende de JavaScript para montar su propio contenido.
Detrás de un CLS alto están las imágenes y los vídeos sin dimensiones declaradas, que empujan lo que tienen debajo al aparecer; los anuncios, iframes y avisos que se insertan sobre la marcha; y las fuentes tipográficas que al cargarse cambian el tamaño del texto y recolocan párrafos enteros.
Detrás de un TBT alto hay una sola familia de culpables: JavaScript que ocupa el hilo principal demasiado tiempo de seguido. Suele venir de librerías grandes que se cargan enteras para usar una parte, de código de terceros como etiquetas de medición y de publicidad, y de trabajo pesado hecho de una vez en lugar de partido en trozos.
Cómo solucionarlo
Lo primero es saber cuál de las tres falla y por qué, porque el arreglo no se parece en nada de una a otra. Wakaris te señala en el informe qué métrica se sale del umbral y con qué valor, que es de dónde parte cualquier decisión sensata.
Para el LCP, por orden de esfuerzo frente a resultado: sirve las imágenes al tamaño real y en formatos modernos, marca el elemento principal para que el navegador lo priorice, quita o retrasa los recursos que bloquean el pintado, y solo después toca el servidor.
Para el CLS el arreglo es casi mecánico y suele ser el más rentable: declara ancho y alto en todas las imágenes y vídeos, reserva por adelantado el hueco de lo que vaya a insertarse después, y evita insertar contenido por encima de lo que ya se está leyendo.
Para el TBT, parte las tareas largas en trozos, carga solo el código necesario para el primer pintado, y revisa qué mete cada etiqueta de terceros. No busques un único ajuste que lo arregle todo.
Tabla con los umbrales de LCP, CLS y TBT separando los valores buenos, mejorables y deficientes
Brief para generar la imagen
Ilustración editorial para una guía técnica de Wakaris. Tema: Tabla con los umbrales de LCP, CLS y TBT separando los valores buenos, mejorables y deficientes. Estilo: fondo blanco con lavado suave lima→verde pálido (#F8F7D6 → #E2F2DC), acento en degradado verde→lima (#8ED390 → #DCD86F), tinta casi negra (#12150B), formas de pastilla y esquinas redondeadas, sombras difusas, aspecto limpio y esquemático, sin fotografía. Formato: 16:9, 1440 píxeles de ancho. Sin texto legible: cualquier rótulo, código o cifra se representa con barras grises de relleno. El significado lo lleva el pie de foto, no la imagen. Sin logotipos reales ni marcas de terceros. Sin personas reconocibles. Etiquetas: métricas, rendimiento, tabla, umbrales, lcp, cls, tbt, separando
Pregúntale a tu IA
Si quieres profundizar en tu caso concreto, copia uno de estos dos prompts y pégalo en la IA que uses. Elige según tu situación.
Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo
Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada. Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El hallazgo es: Métricas de rendimiento. Mide tres cosas de tu página: cuánto tarda en mostrar lo principal (LCP), cuánto se mueve el contenido mientras carga (CLS) y cuánto tiempo está el navegador demasiado ocupado para responder (TBT). Referencia: LCP bueno hasta 2,5 segundos; CLS bueno hasta 0,1; TBT bueno por debajo de 200 milisegundos. Pega aquí el resultado de Wakaris: qué métrica te ha salido fuera de umbral, con qué valor, en qué página y, si lo indica, qué elemento la causa. Si no lo tienes, dímelo y te diré cómo obtenerlo antes de seguir. Reglas que debes seguir en todo momento: 1. No asumas nada sobre mi web. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya medido. Si no lo sabes, pregúntamelo antes de afirmarlo. 2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber si este hallazgo me afecta de verdad y por dónde: a) ¿En qué plataforma está tu web? (WordPress, Shopify, web a medida, otra) b) De las tres métricas, ¿cuál te ha salido fuera de umbral? Si son varias, dime los valores de cada una. c) ¿Qué es lo más grande que se ve al cargar la página: una imagen, un vídeo, un banner o carrusel, o sobre todo texto? d) ¿Notas que el contenido se mueva de sitio mientras la página acaba de cargar? e) ¿Cuántas etiquetas de terceros llevas puestas: medición, publicidad, chats, mapas? ¿Sabes cuáles? f) ¿Controlas el servidor, el hosting o la red de distribución, o es un servicio gestionado? g) Si hay que aplicar un arreglo técnico, ¿lo harías tú, un técnico interno o una agencia? 3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me recomiendas algo, explícame por qué aplica a mi caso. 4. Marca siempre tu nivel de certeza. Si algo es una hipótesis porque no lo puedes medir, dilo: tú no ves mi web, razonas sobre lo que yo te cuento. 5. No me propongas cambios técnicos irreversibles o de riesgo (configuración de servidor, borrar recursos, cambios directos en producción) sin avisarme antes del riesgo y de que conviene una copia de seguridad o un entorno de prueba. 6. Si necesitas un dato que solo se obtiene midiendo la web (confirmar el valor real, el elemento exacto, o si el arreglo funcionó), dímelo y recomiéndame volver a pasar la página por Wakaris: eso se mide, no se adivina. 7. La decisión final es mía, no tuya. Tu papel es ayudarme a entender y a preparar la acción, no decidir por mí. 8. Si el arreglo excede lo que puedo hacer yo, o lo va a ejecutar un equipo, ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer, en un formato accionable para esa persona. Fuente de este hallazgo: https://www.wakaris.com/es/guias/rendimiento/metricas-de-rendimiento Para medirlo o volver a medirlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
Aún no lo he medido y quiero comprobar si mi web tiene este problema
Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho. Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El problema que quiero investigar es: Métricas de rendimiento. Mide cuánto tarda mi página en mostrar lo principal (LCP, bueno hasta 2,5 segundos), cuánto se mueve el contenido mientras carga (CLS, bueno hasta 0,1) y cuánto tiempo está el navegador demasiado ocupado para responder (TBT, bueno por debajo de 200 milisegundos). Todavía NO sé si mi web lo tiene: quiero averiguarlo. Reglas que debes seguir en todo momento: 1. Lo primero y más importante: estas tres cosas se MIDEN, y tú no puedes medir mi web desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente. 2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que tenga el problema: a) Cuando abres tu web por primera vez, ¿tarda en aparecer lo principal o se ve rápido? b) ¿Qué es lo más grande que se ve al cargar: una imagen grande, un vídeo, un banner o carrusel, o sobre todo texto? c) ¿Se te mueve el contenido de sitio mientras la página acaba de cargar? ¿Te ha pasado de ir a pulsar algo y que se desplace? d) ¿Se queda la página "pillada" unos segundos justo después de aparecer, sin responder a los clics? e) ¿Es una web con mucho contenido visual y muchas herramientas de terceros instaladas, o más bien ligera? f) ¿En qué plataforma está? (WordPress, Shopify, web a medida, otra; o no lo sé) g) ¿La sensación de lentitud la notas en móvil, en escritorio o en ambos? 3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga, y de cuál de las tres métricas sería la sospechosa, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico. 4. Dime de forma directa que la única manera de saberlo de verdad es medirlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dará el valor real de cada métrica, el elemento concreto que la causa y de paso el estado de las otras áreas. 5. Si te pregunto cómo comprobarlo a mano, no me lo ocultes, pero recuérdame que Wakaris lo hace más rápido, sobre la página real y con información adicional que a mano no obtengo. 6. Si al medirlo resulta que sí lo tengo, dime que el siguiente paso es entender cómo me afecta y cómo solucionarlo en mi caso concreto. 7. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme. Fuente de este hallazgo: https://www.wakaris.com/es/guias/rendimiento/metricas-de-rendimiento Para medirlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Preguntas frecuentes
¿Cuáles son exactamente las Core Web Vitals? +
Son tres: LCP, que mide la velocidad de carga; INP, que mide la respuesta a las interacciones; y CLS, que mide la estabilidad visual. El TBT no es una Core Web Vital: es una métrica de laboratorio que hace de sustituto del INP cuando no hay una persona interactuando con la página.
¿Qué valores se consideran buenos? +
Un LCP de 2,5 segundos o menos es bueno; entre 2,5 y 4 segundos es mejorable y por encima de 4 es deficiente. Un CLS de 0,1 o menos es bueno; hasta 0,25 es mejorable y por encima, deficiente. En TBT se considera bueno estar por debajo de 200 milisegundos.
¿Por qué mis valores salen peor en móvil? +
Porque el móvil tiene conexión y procesador más limitados, y el elemento más grande de la pantalla puede ser distinto al de escritorio. Google mide y evalúa móvil y escritorio por separado, en el percentil 75 de las cargas reales, y el móvil suele ser el más difícil de aprobar de los dos.
¿Estas métricas afectan de verdad a mi posición en Google? +
Google declara que las Core Web Vitals las usan sus sistemas de posicionamiento, pero también que la búsqueda prioriza el contenido más relevante aunque la experiencia sea mediocre. Cuentan sobre todo cuando varias páginas ofrecen contenido igual de útil: desempatan, no sustituyen al contenido.
Fuentes citadas
- web.devWeb Vitals, web.dev: el conjunto de las Core Web Vitals, sus umbrales, el percentil 75 y la relación entre TBT e INP.
- web.devLargest Contentful Paint (LCP), web.dev: umbrales de 2,5 y 4 segundos y separación entre móvil y escritorio.
- web.devCumulative Layout Shift (CLS), web.dev: umbrales de 0,1 y 0,25 y cálculo de la puntuación.
- web.devTotal Blocking Time (TBT), web.dev: umbral de 200 milisegundos, tareas largas de más de 50 milisegundos y su carácter de métrica de laboratorio.
- developers.google.comPage experience, Google Search Central: uso de las Core Web Vitals en los sistemas de posicionamiento y su peso frente a la relevancia del contenido.
Actualizado: 7 de septiembre de 2026.
Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.