Proportional Reasoning for Web Performance

Lighthouse tells you a number. It does not tell you if that number is the problem. Convert each phase to a percentage of the total. The biggest percentage is your bottleneck. Not the phase that exceeds some absolute threshold. This changes which fixes actually move your Core Web Vitals.

Last reviewed by Arjen Karel on March 2026

The problem with absolute thresholds

Lighthouse says "Render Delay is 350ms." What do you do with that?

If your total LCP is 700ms, yes, 350ms of Render Delay is half the problem. Fix it.

But if your total LCP is 4,200ms and TTFB is 3,800ms, that 350ms Render Delay is 8% of the total. Fixing it to zero saves 350ms. You still have a 3,850ms LCP that fails. The 90% of the problem is your server.

Absolute numbers without context lead to wasted effort. Convert to percentages and the bottleneck is obvious.

Fix the biggest percentage first

Both LCP and INP break down into phases. Each phase eats a chunk of the total. The biggest chunk is your bottleneck. Fix that one first.

This is not complicated. But it is surprising how many performance tools, and now AI agents, skip this step and optimize whatever exceeds a fixed threshold.

LCP example

LCP on your mobile product pages: 3,820ms (poor). The phase breakdown from real users:

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

Fixing the 16% Render Delay to zero saves 620ms. Fixing the 55% Load Delay problem saves over 2,000ms. Both are real problems. One is the bottleneck.

Load Delay at 55% means the browser received the HTML but did not request the hero image for over two seconds. The browser can't find the image. It is not in the HTML where the preload scanner can see it. Add a preload hint and you cut LCP nearly in half.

INP example

INP on the checkout page: 350ms (needs improvement). The phase breakdown:

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

Without percentages, an agent optimizes Input Delay because 70ms exceeds some threshold. Show it the percentages and it targets Presentation. 57% is where the time goes.

Fixing Presentation (large DOM, missing CSS containment, expensive repaint) moves INP from 350ms to below 200ms. That takes you from "needs improvement" to "good." Fixing Input Delay from 70ms to 0ms (unlikely, but hypothetical) saves 70ms. You still fail at 280ms. Same effort, different result.

What happens when agents skip this

An AI agent without proportional context does what the tool tells it. Lighthouse flags a long TBT. The agent optimizes TBT. The change is technically correct. The real-world impact is minimal because TBT was 20% of the problem and the 57% bottleneck is untouched.

I see this pattern constantly in AI-generated performance fixes. The fix addresses a symptom. The bottleneck remains. Field data does not improve. The developer wonders why a "correct" optimization did nothing.

One approach wastes your time. The other fixes the actual problem.

How to do this without CWV Superpowers

You can do this manually. For LCP: open Chrome DevTools, run a performance trace, find the LCP marker in the timeline, and measure the four phases. Convert each to a percentage of total LCP. Fix the highest percentage first.

For INP: use the Web Vitals Chrome extension or a PerformanceObserver with the event entry type. Record the INP interaction, get the three phase durations, convert to percentages.

Or let CWV Superpowers do it automatically with field data from thousands of real sessions instead of a single lab trace.