Rendimiento web
Core Web Vitals: guía para diagnosticar LCP, INP y CLS
Cómo distinguir datos de campo y laboratorio, localizar problemas de carga, interacción y estabilidad, y priorizar mejoras sin perseguir solo una puntuación.

Una web puede parecer rápida en tu ordenador y resultar lenta para visitantes con otros dispositivos o conexiones. También puede cargar pronto y bloquearse al abrir un menú. Por eso el rendimiento necesita varias medidas y escenarios, no una única nota.
Las Core Web Vitals evalúan carga percibida, respuesta a interacciones y estabilidad visual. Los umbrales de referencia que recoge web.dev se valoran en el percentil 75 de las visitas, con segmentación entre móvil y escritorio.
Qué mide cada métrica
| Métrica | Qué observa | Umbral de experiencia buena |
|---|---|---|
| LCP: Largest Contentful Paint | Cuándo aparece el mayor elemento de contenido visible. | Hasta 2,5 segundos. |
| INP: Interaction to Next Paint | La latencia de respuesta visual a interacciones durante la visita. | Hasta 200 milisegundos. |
| CLS: Cumulative Layout Shift | Desplazamientos inesperados del contenido. | Hasta 0,1. |
Estos valores no son garantías de conversión ni cubren toda la accesibilidad o usabilidad. Aprobar las tres métricas tampoco demuestra que un formulario llegue a destino o que el contenido responda a la búsqueda.
Separa campo y laboratorio antes de actuar
Los datos de campo representan experiencias reales. PageSpeed Insights puede mostrar datos de Chrome UX Report cuando hay cobertura suficiente; Search Console agrupa URLs con problemas de experiencia. Si no aparecen datos, no significa que la web apruebe: puede faltar muestra.
Las pruebas de laboratorio, como Lighthouse o las herramientas de rendimiento del navegador, ejecutan un escenario controlado. Sirven para reproducir problemas y explorar causas, pero no sustituyen al campo. Una prueba sin interacciones reales no describe por sí sola el INP de una visita completa.
En PageSpeed Insights comprueba si los datos de campo corresponden a la URL o al origen. Una agregación de todo el dominio puede esconder diferencias entre plantillas. Anota dispositivo, página, fecha y condiciones antes de comparar pruebas.
Diagnostica LCP: encuentra el elemento y su camino de carga
Primero identifica qué elemento determina el LCP en la página que estás revisando: puede ser una imagen o un bloque de texto. No empieces comprimiendo todas las imágenes sin saber cuál afecta a la apertura.
Revisa la secuencia de carga en las herramientas del navegador:
- Si el HTML tarda en llegar, investiga respuesta del servidor, caché y red antes de culpar al componente.
- Si el recurso principal se descubre tarde, comprueba si depende de JavaScript o de una cadena de estilos.
- Si la imagen pesa demasiado, utiliza dimensiones y formatos adecuados para el tamaño presentado.
- Si el contenido está descargado pero tarda en mostrarse, revisa estilos bloqueantes, fuentes y trabajo del hilo principal.
No uses carga diferida indiscriminada en la imagen principal visible al abrir la página. Tampoco precargues todos los recursos: compiten entre sí y pueden empeorar la prioridad del contenido importante. Repite el escenario tras cada cambio para comprobar el efecto.
Diagnostica INP: prueba acciones que hacen los usuarios
Recorre interacciones concretas: abrir navegación, filtrar una lista, elegir un producto o enviar un formulario. Graba una traza de rendimiento y busca trabajo prolongado alrededor de la interacción que responde tarde.
Las causas pueden incluir manejadores pesados, JavaScript de terceros, renderizados costosos o cálculos de layout. El cambio útil depende de la causa: reducir JavaScript innecesario, dividir trabajo prolongado, limitar lo que se actualiza o diferir tareas que no son necesarias para el siguiente resultado visual.
No añadas un indicador de carga como sustituto de investigar un bloqueo. El feedback puede ayudar cuando una operación realmente tarda, pero la interfaz debe seguir respondiendo. Prueba varios tipos de interacción y no solo la que sale bien en un portátil rápido.
Diagnostica CLS: reserva espacio y observa la sesión completa
Mira qué se desplaza y qué aparece justo antes. Imágenes sin dimensiones, contenido incrustado, avisos y cambios de fuentes son candidatos, pero hay que observarlos en la página real.
Reserva espacio coherente con el contenido que se va a mostrar. Define dimensiones o proporciones para imágenes y embeds, y evita insertar bloques encima de contenido que el visitante ya está leyendo. Si cambia una fuente, revisa la geometría del texto y las alternativas usadas durante la carga.
Una carga inicial estable no descarta desplazamientos posteriores. Recorre la página, espera contenido diferido y prueba estados dinámicos. Usa las herramientas de detección de desplazamientos para vincular cada problema con su elemento, no con una sospecha general sobre el diseño.
Prioriza por alcance y evidencia
Elige primero una plantilla o recorrido importante y registra el problema antes de modificarlo. Una incidencia compartida por muchas páginas puede justificar intervenir en el layout; una exclusiva de una ficha no necesita un refactor global.
Puedes usar este registro:
| Campo | Ejemplo de información, no un resultado medido |
|---|---|
| Página y dispositivo | URL exacta y escenario móvil o escritorio. |
| Evidencia | Dato de campo disponible y traza de laboratorio reproducible. |
| Causa candidata | Recurso tardío, tarea prolongada o inserción que desplaza contenido. |
| Cambio acotado | Ajuste concreto y archivos afectados. |
| Comprobación | Mismo escenario de prueba y regresiones a revisar. |
| Seguimiento | Qué datos reales revisar cuando reflejen la nueva versión. |
El texto de ejemplo no debe convertirse en cifras publicadas. Conserva el estado anterior y no des por demostrado un efecto que todavía no se ha medido.
Verifica la mejora sin confundir publicación con resultado
Tras un cambio, repite las pruebas con condiciones similares y comprueba navegación, formularios y contenido. Una optimización que oculta el elemento principal o rompe una interacción no es una mejora válida.
Los datos de campo agregados no cambian instantáneamente al desplegar. Espera a que representen la versión nueva y comprueba su cobertura. Si solo has probado en local o laboratorio, comunica ese límite: no afirmes que la experiencia de los visitantes ya ha mejorado.
El rendimiento es una parte del SEO técnico, no una promesa de posición en Google. La guía oficial de contenido útil de Google recuerda la importancia de responder a las necesidades de las personas; una página rápida con contenido insuficiente sigue siendo insuficiente.
Si necesitas localizar prioridades en una web existente, revisa el servicio de optimización web WPO. Para dudas de rastreo e indexación, consulta SEO técnico. Puedes compartir tu URL y el problema observado sin asumir antes que necesitas reconstruir toda la web.