Core Web Vitals: cómo encontrar qué ralentiza LCP e INP

Revisión del 15 de octubre de 2026: el anuncio de Cloudflare confirma las fases y unidades citadas. Añadimos la precaución de no sumar percentiles de fases como si fueran el percentil del total.

Para saber qué ralentiza una web ya no basta con mirar un único valor de LCP o INP. Cloudflare Web Analytics ahora divide LCP en tiempo de respuesta inicial, espera y descarga del recurso principal, y demora de renderizado; también separa INP en espera de entrada, ejecución y presentación. Ese desglose permite vincular cada cuello de botella con una acción concreta: servidor y caché, prioridad de imágenes, JavaScript, controladores de eventos o trabajo de renderizado. La novedad sirve para diagnosticar con datos de usuarios reales, pero no sustituye pruebas de laboratorio ni garantiza mejores posiciones en Google.

Qué anunció Cloudflare y por qué importa

El 13 de octubre de 2026, Cloudflare incorporó submétricas de Core Web Vitals a Web Analytics. El cambio afecta a su medición RUM, es decir, datos recogidos durante visitas reales. También expone los datos mediante el panel y la API GraphQL Analytics.

La diferencia práctica es importante. Un LCP de cuatro segundos dice que el contenido principal apareció tarde, pero no revela por sí solo si la demora provino del servidor, del descubrimiento de la imagen, de la descarga o del renderizado. Las submétricas convierten ese resultado agregado en una ruta de diagnóstico.

Cómo leer las cuatro partes de LCP

Largest Contentful Paint (LCP) mide cuándo se renderiza el elemento de contenido visible más grande. Google considera buena una medición de 2,5 segundos o menos en el percentil 75, separando móviles y escritorio.

1. Time to First Byte: respuesta inicial

timeToFirstByte refleja el tiempo hasta recibir el primer byte. Si concentra una parte desproporcionada del LCP, conviene revisar la latencia del servidor, consultas de base de datos, procesamiento dinámico, caché, redirecciones y proximidad geográfica. En un comercio electrónico también hay que comprobar si personalización, inventario o sesiones impiden aprovechar la caché.

2. Resource load delay: descubrimiento y prioridad

lcpResourceLoadDelay mide cuánto espera el navegador antes de comenzar a cargar el recurso LCP. Un valor alto suele apuntar a una imagen descubierta tarde, estilos que ocultan el recurso, carga diferida mal aplicada o prioridad insuficiente. Las medidas posibles incluyen colocar el recurso en el HTML inicial, usar preload con criterio y evitar loading="lazy" en la imagen principal visible.

3. Resource load duration: transferencia

lcpResourceLoadTime corresponde a la duración de la descarga. Si domina el total, hay que revisar peso, dimensiones, formato, compresión, caché y distribución mediante CDN. No conviene reducir calidad de forma indiscriminada: primero se debe confirmar cuál es el elemento LCP en los dispositivos y plantillas relevantes.

4. Element render delay: trabajo antes de pintar

lcpElementRenderDelay cubre la espera entre el final de la carga y el renderizado. Suele crecer por CSS o JavaScript bloqueante, fuentes, hidratación de aplicaciones, tareas largas o lógica que mantiene oculto el elemento. Aquí la optimización suele estar en el hilo principal, no en el peso de la imagen.

Cómo interpretar las tres partes de INP

Interaction to Next Paint (INP) evalúa la capacidad de respuesta de una página durante la visita. Un INP de 200 milisegundos o menos se considera bueno en el percentil 75.

1. Input delay: la interacción espera

inpInputDelay indica cuánto pasa desde que la persona interactúa hasta que el navegador puede empezar a procesar el evento. Un retraso alto suele relacionarse con tareas largas que ya ocupaban el hilo principal. Dividir trabajo, reducir JavaScript y posponer tareas no urgentes puede liberar la respuesta.

2. Processing duration: el controlador tarda

inpProcessingDuration mide la ejecución de los controladores asociados. Hay que perfilar la interacción concreta: validaciones, filtros, búsquedas, carritos y componentes de terceros pueden hacer demasiado trabajo dentro de un solo evento.

3. Presentation delay: el cambio tarda en verse

inpPresentationDelay cubre el tiempo desde que termina el procesamiento hasta el siguiente fotograma. Un valor alto puede señalar recalculado de estilos, diseño complejo, pintura costosa o DOM excesivo. El objetivo no es ocultar el indicador, sino reducir el trabajo necesario para presentar la respuesta.

Un procedimiento de diagnóstico en seis pasos

1. Segmenta antes de concluir. Compara móvil y escritorio, país, plantilla, URL y periodo. Un promedio global puede esconder una mala experiencia en el segmento comercial más importante.
2. Usa percentiles. Cloudflare permite consultar P25, P50, P75, P90, P95, P99 y P999. Para evaluar el umbral de Core Web Vitals, prioriza P75.
3. Identifica la submétrica dominante. Determina qué parte explica la mayor proporción de LCP o INP en el segmento afectado.
4. Reproduce en laboratorio. Usa DevTools o Lighthouse para observar solicitudes, tareas largas y renderizado. Los datos reales detectan el problema; el laboratorio ayuda a reproducirlo.
5. Cambia una causa por vez. Documenta versión, fecha y segmento para no atribuir una mejora a la intervención equivocada.
6. Vuelve a medir con tráfico suficiente. RUM depende de visitas reales y de la mezcla de dispositivos, redes y ubicaciones.

No sumes percentiles de fases por separado. La suma de los P75 de cada submétrica no equivale necesariamente al P75 del LCP o INP total: pueden representar visitas distintas. Usa cada desglose para orientar la investigación y valida la interacción o carga concreta antes de atribuir la causa.

Consulta técnica mediante GraphQL

Cloudflare documenta el grupo rumWebVitalsEventsAdaptiveGroups para consultar las subpartes de LCP e INP. Las duraciones se expresan en microsegundos y un valor negativo indica que la submétrica no estaba disponible. Para conexión y TLS se utiliza rumPerformanceEventsAdaptiveGroups, con connectionTimeWithoutTLS y tlsTime.

Esta separación puede ayudar a distinguir latencia de conexión y negociación TLS. No es una invitación a desactivar HTTPS: la acción correcta es revisar red, reutilización de conexiones, configuración y distribución.

Hechos, análisis y recomendaciones

Hechos confirmados

• La novedad es una ampliación de observabilidad de Cloudflare Web Analytics, no un cambio anunciado en el sistema de ranking de Google.
• LCP se divide en cuatro fases e INP en tres; el panel y la API GraphQL muestran los datos.
• Las métricas proceden de usuarios reales y pueden variar por dispositivo, conexión, ubicación y volumen de tráfico.

Análisis

El mayor valor para una pyme o equipo de marketing está en dejar de optimizar “velocidad” como un bloque genérico. Si el problema es TTFB, comprimir más una imagen puede no mover el resultado. Si la descarga ya es rápida pero el renderizado tarda, cambiar de CDN tampoco resolverá el cuello de botella.

La instrumentación también debe tratarse con disciplina. Igual que en una estrategia de telemetría y registros de Cloudflare, conviene recopilar solo lo necesario, documentar retención y evitar exponer datos sensibles. Si la causa está en scripts externos, resulta útil complementar el análisis con controles de seguridad para JavaScript en tiendas online.

Recomendaciones

• Empieza por las páginas que sostienen ingresos: inicio, categorías, productos, formularios y pago.
• No extrapoles una mejora de laboratorio a todos los visitantes sin validarla con RUM.
• Conserva HTTPS y controles de seguridad aunque exista presión por reducir tiempos.
• No prometas una subida de posiciones. Google explica que una buena experiencia de página ayuda, pero no sustituye contenido relevante y útil; su guía de experiencia de página recomienda una evaluación integral. Para separar rendimiento de otros problemas SEO, también puede consultarse el análisis de GitCoders sobre la actualización de spam de Google.

Limitaciones y contexto internacional

La función se ofrece dentro de Cloudflare Web Analytics y su disponibilidad operativa depende de que el sitio utilice esa medición. Los umbrales de web.dev son globales, pero los resultados reales cambian con la calidad de red, la capacidad del dispositivo y la distancia al origen. Por eso una web puede rendir bien en un país y mal en otro.

Los datos negativos o ausentes no deben convertirse en ceros. Tampoco todos los elementos LCP serán imágenes, ni todas las demoras de INP tendrán una causa única. Cuando el tráfico es bajo, el percentil puede ser inestable y requiere una ventana más amplia.

Preguntas frecuentes

¿Cloudflare cambió Core Web Vitals?

No. Añadió un desglose más detallado a su herramienta de analítica. Las definiciones y umbrales citados corresponden a la documentación de web.dev.

¿Debo optimizar LCP o INP primero?

Prioriza la métrica que falla en el percentil 75 para el segmento y las páginas de mayor impacto. Si ambas fallan, empieza por el cuello de botella que afecte más conversiones o tareas esenciales.

¿Un buen resultado garantiza mejor ranking?

No. Core Web Vitals forma parte de la experiencia de página, pero Google prioriza contenido útil y relevante. El rendimiento es una condición de calidad, no una garantía de posición.

¿RUM reemplaza a Lighthouse?

No. RUM muestra lo que viven usuarios reales; Lighthouse y DevTools ayudan a reproducir y depurar causas en un entorno controlado. Se complementan.

¿Qué hago si una submétrica aparece con valor negativo?

Trátala como no disponible, según la documentación de Cloudflare. No la sumes como cero ni concluyas que esa fase fue instantánea.

Fuentes

• Cloudflare: Core Web Vitals sub-part metrics, 13 de octubre de 2026.
• web.dev: Largest Contentful Paint, actualización consultada el 14 de octubre de 2026.
• web.dev: Interaction to Next Paint, consulta del 14 de octubre de 2026.
• Google Search Central: experiencia de página, consulta del 14 de octubre de 2026.

Información verificada el 14 de octubre de 2026 a las 03:06, America/Lima.