Razonamiento proporcional para el rendimiento web

Lighthouse te da un número. No te dice si ese número es el problema. Convierte cada fase en un porcentaje del total. El mayor porcentaje es tu cuello de botella. No la fase que supera algún umbral absoluto. Esto cambia qué correcciones realmente mejoran tus Core Web Vitals.

Última revisión por Arjen Karel en marzo de 2026

El problema con los umbrales absolutos

Lighthouse dice "Render Delay es de 350 ms". ¿Qué haces con eso?

Si tu LCP total es de 700 ms, sí, 350 ms de Render Delay es la mitad del problema. Soluciónalo.

Pero si tu LCP total es de 4.200 ms y el TTFB es de 3.800 ms, esos 350 ms de Render Delay son el 8% del total. Reducirlo a cero ahorra 350 ms. Sigues teniendo un LCP de 3.850 ms que falla. El 90% del problema es tu servidor.

Los números absolutos sin contexto llevan a un esfuerzo desperdiciado. Conviértelos a porcentajes y el cuello de botella es obvio.

Soluciona primero el mayor porcentaje

Tanto el LCP como el INP se dividen en fases. Cada fase consume una parte del total. La parte más grande es tu cuello de botella. Soluciona esa primero.

Esto no es complicado. Pero sorprende cuántas herramientas de rendimiento, y ahora agentes de IA, omiten este paso y optimizan lo que sea que supere un umbral fijo.

Ejemplo de LCP

LCP en las páginas de productos móviles: 3.820 ms (deficiente). El desglose de fases de usuarios reales:

• TTFB: 420 ms (11%)
• Load Delay: 2.100 ms (55%)
• Load Time: 680 ms (18%)
• Render Delay: 620 ms (16%)

Reducir a cero el 16% de Render Delay ahorra 620 ms. Solucionar el problema del 55% de Load Delay ahorra más de 2.000 ms. Ambos son problemas reales. Uno es el cuello de botella.

Un Load Delay del 55% significa que el navegador recibió el HTML pero no solicitó la imagen principal (hero image) durante más de dos segundos. El navegador no puede encontrar la imagen. No está en el HTML donde el preload scanner pueda verla. Añade una sugerencia de precarga (preload hint) y reducirás el LCP casi a la mitad.

Ejemplo de INP

El INP en la página de pago (checkout): 350 ms (necesita mejora). El desglose de fases:

• Input Delay: 70 ms (20%)
• Processing: 80 ms (23%)
• Presentation: 200 ms (57%)

Sin porcentajes, un agente optimiza el Input Delay porque 70 ms superan algún umbral. Muéstrale los porcentajes y apuntará a Presentation. El 57% es adonde va el tiempo.

Solucionar Presentation (DOM grande, falta de contención CSS, repintado costoso) reduce el INP de 350 ms a menos de 200 ms. Eso te lleva de "necesita mejora" a "bueno". Reducir el Input Delay de 70 ms a 0 ms (improbable, pero hipotético) ahorra 70 ms. Sigues fallando con 280 ms. Mismo esfuerzo, resultado diferente.

Qué pasa cuando los agentes omiten esto

Un agente de IA sin contexto proporcional hace lo que la herramienta le dice. Lighthouse señala un TBT largo. El agente optimiza el TBT. El cambio es técnicamente correcto. El impacto en el mundo real es mínimo porque el TBT era el 20% del problema y el cuello de botella del 57% sigue intacto.

Veo este patrón constantemente en correcciones de rendimiento generadas por IA. La corrección aborda un síntoma. El cuello de botella permanece. Los datos de campo no mejoran. El desarrollador se pregunta por qué una optimización "correcta" no hizo nada.

Un enfoque te hace perder el tiempo. El otro soluciona el problema real.

Cómo hacer esto sin CWV Superpowers

Puedes hacerlo manualmente. Para el LCP: abre las Chrome DevTools, ejecuta un rastreo de rendimiento (performance trace), encuentra el marcador LCP en la línea de tiempo y mide las cuatro fases. Convierte cada una en un porcentaje del LCP total. Soluciona primero el mayor porcentaje.

Para el INP: usa la extensión de Chrome Web Vitals o un PerformanceObserver con el tipo de entrada event. Registra la interacción INP, obtén las duraciones de las tres fases y conviértelas a porcentajes.

O deja que CWV Superpowers lo haga automáticamente con datos de campo de miles de sesiones reales en lugar de un único rastreo de laboratorio.