--- title: "Blog" description: "Read about the background of our monitoring solution, new features and case studies" canonical: "https://www.rumvision.com/blog/when-not-to-use-google-lighthouse/" --- Breadcrumbs: [Home](https://www.rumvision.com/?format=md) > Blog # How much does a Lighthouse score of 100 cost you? There are numerous tools available for measuring the speed of your website, making it difficult to choose. This article explains why you should not always rely on the most popular tool, Google Lighthouse. One of the fastest sites in our tool, measured on its actual visitors, scores 63 in Lighthouse Pagespeedscore. Not 63 because it's slow. 63 because Lighthouse isn't measuring what your customers feel. It's grading a simulated visit on one throttled device under conditions no real user is ever in. Are you chasing a perfect 100 in Lighthouse score? Is your agency quoting hours to get there? And every one of those hours is being spent on a number Google doesn't rank you with, that your customers never experience, and that can climb while your conversion rate quietly goes the other way... The uncomfortable question isn't "how do we get to 100?" It's: **what is the pursuit of 100 already costing you in revenue you'll never see on a report?** ## The math nobody shows you: what 100 milliseconds is worth Start with the numbers because this is the number your finance director should care about. Google and Deloitte studied 37 retail, travel, luxury, and lead-generation brands across roughly 30 million mobile sessions. They isolated speed and measured what a **0.1-second improvement** did to the business: **Vertical** **Impact of a 0.1s improvement** Retail +8.4% conversions, +9.2% average order value Travel +10.1% conversions Luxury +40.1% progression from product detail to add-to-basket +8.3% improvement in bounce rate on information pages One tenth of a second. Less time than a blink. And on a retail site it moves both conversion rate and order value by more than eight percent. Now hold that against your Lighthouse score. Those gains were measured on real user sessions. Not one of them would have been visible in a lab run what Lighthouse score is, and a lab run can't tell you whether you've captured them or lost them. Here's the part that should sting: while your team spends a sprint moving the score from 88 to 97, a 100ms regression can land on your mobile product pages from a single new marketing tag, and nobody notices for a month. That's the real cost of steering on the wrong number. Not the developer hours. ## 40% of your Lighthouse score measures things a real customer cannot experience The performance score is a weighted average of five metrics. In Lighthouse 12: Metric Weight Measurable on real users? Total Blocking Time (TBT) 30% No, lab only Largest Contentful Paint (LCP) 25% Yes (Core Web Vital) Cumulative Layout Shift (CLS) 25% Yes (Core Web Vital) First Contentful Paint (FCP) 10% Yes (not a Core Web Vital) Speed Index 10% No, lab only Forty percent of the number your team reports upward comes from two metrics that cannot exist on a real visitor. TBT and Speed Index only live inside a lab. And the reverse: The Lighthouse performance score doesn't measure the INP. (Interaction to Next Paint, the Core Web Vitals metric that captures whether your site responds when someone taps add-to-cart, opens a filter, or switches a variant.) You can score 100 and be losing customers on every interaction after the first paint. Plenty of stores are. ## Lighthouse never scrolls, never clicks, never accepts your cookie banner The score grades a cold page load under fixed conditions: a simulated mid-tier Android, throttled connection, one run, no session history, no warm cache, nobody logged in. What that means in practice: - **It doesn't scroll.** Lazy-loaded blocks, carousels, review widgets, recommendation widgets all untriggered. Your customers scroll within seconds. - **It doesn't interact.** No taps, no filters, no menu opens. The entire responsiveness dimension of your store goes unmeasured. - **It doesn't accept your cookie notice.** Every third-party script behind consent stays dormant during the audit. Your tag manager payload, chat widget, A/B testing tool, personalization engine the things that most often wreck real-world performance are invisible to the score for a large share of your traffic. - **It doesn't repeat.** Scores routinely swing 5-10 points between runs on the same page, on the same machine. You've probably re-run a test until you liked the number. Everyone has. A metric that never scrolls and never clicks isn't a measurement of speed. It's a code-quality checklist with a color attached. ## Why Lighthouse is no monitoring tool Three patterns show up in real accounts, constantly: **The JavaScript-delay plugin.** Deferring scripts until first interaction is the fastest way on earth to inflate a Lighthouse score, because 30% of the TBT score is measured during the load window the delay conveniently empties. Your users then hit the whole bundle at the exact moment they try to interact. Score up. INP worse. **Cache invalidation after a deploy.** TTFB degrades because pages have to be rendered again. Lighthouse, running fresh, shows nothing. Real users feel it immediately, and you find out weeks later, if at all. **The already-fast site.** Lighthouse's throttled conditions show a clear LCP improvement that your actual visitors, on decent connections, never notice. You won in the lab but not in the field data. Lab score and real experience are separate systems. Either can move without the other. ## What Google actually grades you on Core Web Vitals are field data: LCP, INP, and CLS collected from real Chrome users, assessed at the **75th percentile** over a rolling 28-day window. Good means LCP under 2.5s, INP under 200ms, CLS under 0.1 and all three must pass at once. Around half of all sites still fail this assessment on mobile. That's not a solved problem you can skip; it's a gap your faster competitors are currently monetizing. ## The challenge: free field data is only the start! Most teams graduate from Lighthouse to PageSpeed Insights, glance at the field section, and stop. But CrUX has limits that make it useless as an operational tool: - **28-day rolling window.** You learn about a regression weeks after shipping it. By then you've shipped four more things and can't tell which one did it. - **No attribution.** A number, not the element, attribute, or script causing it. "Your LCP is 3.4s" tells nobody what to fix. - **A partial audience.** Only opted-in Chrome users with data syncing on. No Safari, no Firefox, a large slice of mobile revenue simply isn't represented. - **One percentile.** No distribution, no segments, no way to see which template, device, or country is dragging you down Google's own guidance is to supplement its data with your own RUM data. That's not a vendor pitch it's in the web.dev documentation on getting started with measuring Vitals. ## If you're a smaller site, free tools show you nothing at all This is the part that gets overlooked, and it's the most important one for a lot of readers. CrUX only reports on origins and URLs with enough qualifying traffic. Below that bar, there is no data. Not "bad data" but "**no data"**. Run PageSpeed Insights on a smaller webshop and the field section is simply absent. Most sites that do have origin-level data still have no URL-level data, which means you can see a vague site-wide average and nothing about the product page that's actually costing you sales. So if you're a specialist retailer, a growing D2C brand, a B2B site with high-value low-volume traffic the free tooling gives you exactly one number: the Lighthouse score. The one that measures the wrong things. And the irony is that speed matters *more* here, not less. A store doing 15,000 sessions a month has no volume to absorb a bad experience. An 8.4% conversion swing on a small base is still the difference between a good quarter and a bad one and unlike a large retailer, you don't have the traffic for the problem to average itself out into visibility. The only way a smaller site can see its real Core Web Vitals is to collect them itself, which means a RUM solution like RUMvision. ## Why p90 should be your target, not p75 Google grades at p75. Passing at p75 means one in four page views can still be a bad experience and you're technically fine. On 400,000 monthly sessions, that's 100,000 visits you've formally declared acceptable. That failing quarter isn't randomly spread either. It's concentrated: older Android devices, mobile networks, your less-served regions, sessions with the heaviest third-party payload and disproportionately, the deep-funnel pages where your acquisition spend has already been committed. You paid for those users. They're the ones having the bad time. **p75 is Google's compliance bar. p90 is a business target.** Steering on p90 does two things: 1. **Coverage.** A healthy p90 means 90%+ of your visitors genuinely have a good experience, including most of the frustrated tail you're currently paying to acquire and then losing. 2. **Buffer.** CrUX moves. Traffic mix shifts seasonally, a campaign sends a wave of mobile users, a device generation ages out. Sitting exactly on the p75 threshold means one seasonal shift flips you to failing and you find out 28 days later. ## The four levels and where your team actually is - **Level 1: Lighthouse.** Lab data. Easy to start with, useful for diagnosing a cold load. A developer tool. - **Level 2: PageSpeed Insights.** Field data, but delayed, aggregated, unattributable and often missing entirely on smaller sites. - **Level 3: Core Web Vitals history.** Trends over months. Better direction, still no drill-down. - **Level 4: Real user monitoring.** Your own visitors, in real time, at any percentile, with element-level attribution and deploy annotations. Lighthouse being level 1 doesn't make it useless. It's a solid diagnostic. It just was never a measurement of how fast your site is, and it should never have become the number you report upward. ## What changes the day you switch - **Minutes, not 28 days.** Depending on traffic, you see the effect of a deploy the same afternoon. - **Attribution.** Not "LCP is poor" but which element, on which template, for which device class. - **Annotations.** Tie every release, theme change, and new marketing tag to the exact moment performance moved and end the argument about whether the last installed script is the cause. - **Segments.** Mobile vs desktop, country, browser, template, campaign source. The aggregate hides the problem; the segment names it. - **Any percentile you want.** Including the one that reflects your customers: p90. ## The bottom line **E-commerce owners:** a green 100 is not evidence that your store feels fast. Ask for p90 on your revenue-critical templates instead it's the only number that tells you what share of the traffic you paid for is having a good time, and 100ms of it is worth 8.4%. **Developers:** keep Lighthouse for diagnosis; it's genuinely good at that. Stop letting it be the reporting metric. **SEOs:** you're graded on field data at p75, on a 28-day lag, with no attribution. p90 in RUM gives you the buffer and the detail to kill a regression before it ever reaches the dataset Google ranks you with.