Lighthouse 100 Is a Floor, Not a Ceiling

by Josh Oransky

Every EDS deck on the planet leads with the same screenshot: four green 100s in a Lighthouse scorecard. It's a great line, and it's a starting position. Treating it as the destination is how you end up with a site that scores 100 on synthetic tests and feels mediocre to a real human on a mid-tier Android in a parking lot.

What 100 actually measures

Lighthouse is a static synthetic audit. It tells you the page loaded fast on a simulated network, the layout didn't shift, the largest paintable element rendered in time, and the script didn't block the main thread for too long. Those are real things, and they're worth winning. They are not the same as the experience your customer has on the page.

Real users have flaky 4G, battery-saving CPU throttling, ad blockers and tracker blockers, and a hundred Chrome tabs open. They tap something, wait three hundred milliseconds, and decide the site is broken. Synthetic Lighthouse never has any of those problems.

The Core Web Vitals you should actually obsess over

INP (Interaction to Next Paint) is the one most teams underweight. It measures the time between a user input and the next frame the browser paints in response. The 75th-percentile target is 200ms. Hitting it under field conditions is dramatically harder than hitting an LCP target under simulated 4G.

If your stat dashboard only shows synthetic Lighthouse and lab CWVs, you are flying blind. Wire up real-user monitoring on day one. The aem.live RUM pipeline gives you this for free. Use it.

What "above the floor" looks like

Once you're at 100 on Lighthouse, here's the work that changes what users feel:

Lighthouse 100 is the price of entry. Treat it as the day-one baseline and start the real work.