Your Lighthouse score lies. Here's what to check instead.
CheckVibeCode Team
Product & Security Research
You open DevTools, run Lighthouse, see a 98, and close the tab satisfied. Then a real visitor on a mid-range phone over LTE waits four seconds for the page to feel usable. Both things are true at once, because a lab score run once on a fast desktop machine and a real user's experience are measuring different things.
Lab data vs. field data
Lighthouse produces lab data — a single synthetic run, on a simulated connection, on whatever machine ran it. Core Web Vitals as Google actually uses them for ranking and as users actually experience them are field data — the real distribution of real visits, on real devices, on real networks, over the past 28 days. A good lab score with bad field data usually means your dev machine is much faster than your median visitor's phone.
The three metrics that matter
- LCP (Largest Contentful Paint) — how long until the biggest visible element renders. This is what "feels slow" usually means.
- INP (Interaction to Next Paint) — how long the page takes to respond after a tap or click. Bad INP feels like the site is ignoring you.
- CLS (Cumulative Layout Shift) — how much content jumps around while loading. This is what makes you tap the wrong button.
Why AI-generated frontends tend to run heavy
Generated code favors whatever library solves the immediate problem, without much pressure to remove what the previous prompt already added. It's common to find three animation libraries, an unused charting package, and a full icon set imported for four icons — each one adding to the JavaScript the browser has to download and execute before the page responds to a tap.
This compounds across a session, not just a page. Each new feature prompt tends to add a dependency rather than reuse one that's already in the bundle, because the model has no visibility into what's already imported elsewhere in the project. A dashboard built over a dozen prompts can end up with two date libraries, two state managers, and a UI kit that duplicates half of what a component library already provided — nobody chose that; it just accumulated.
Bundle size doesn't just affect load time — it affects INP too, because every extra kilobyte of JavaScript has to be parsed before the main thread is free to handle a click.
Where to actually find field data
PageSpeed Insights shows both lab and field data on the same report — scroll past the Lighthouse score to the "Discover what your real users experienced" section, which pulls from the Chrome User Experience Report (CrUX) if your site has enough traffic to be included. Search Console's Core Web Vitals report shows the same field data grouped by URL, which is more useful for finding which specific pages are dragging the average down.
If your site doesn't have enough traffic for CrUX to report on it yet, WebPageTest run on a throttled "Moderate 3G on a mid-tier device" profile is the closest lab approximation of what a real median mobile visitor experiences — much closer than the fast, mostly-idle machine Lighthouse tends to run on locally.
What to actually check
- Total JavaScript shipped to the page, not just the Lighthouse performance score — a build analyzer (like @next/bundle-analyzer) shows exactly which packages are the heaviest.
- Whether any library is imported in full when only one function from it is used — many packages support named imports that tree-shake the rest away.
- How many third-party scripts load before the page is interactive — analytics, chat widgets, and A/B testing tags each add their own request and execution cost.
- Whether images are served at the size they're displayed at, not a 4000px original scaled down in CSS.
- Field data trends over the last 28 days, not a single run — a score that's improving or degrading over time tells you more than any one snapshot.
Look at field data, not just a single lab run — PageSpeed Insights and Search Console both surface it for free. Check your total JavaScript weight, not just your Lighthouse score. And test on throttled mobile, not on the fastest machine in the room; that's the experience most of your traffic actually has.
