A Lighthouse 100 certifies a five-metric average that stops at first interactivity

Total Blocking Time counts a specific window. It sums every stretch where the main thread is blocked for more than 50 milliseconds, between First Contentful Paint and interactivity, according to the dev.to write-up on the score's composition ^[6]. The window closes at interactivity. A handler that blocks the thread for 300 milliseconds when a visitor opens a filter panel ten seconds after load falls outside it, and none of the other four weighted metrics measures input latency either ^[4].

The weights come to 100 exactly: 30 for TBT, 25 each for Largest Contentful Paint and Cumulative Layout Shift, 10 each for First Contentful Paint and Speed Index ^[1]. Eighty of the hundred points go to blocking time, largest paint and layout stability ^[2]. The score omits Interaction to Next Paint, which replaced First Input Delay, entirely ^[7][8]. TBT alone carries three times the weight of FCP, which the write-up gives as the reason two pages with the same first impression can land twenty points apart ^[2].

Each metric is scored on its own log-normal curve built from real HTTP Archive data, anchored at two fixed points: the 25th percentile of real sites scores 50, and the 8th percentile scores 90 ^[3]. A metric at 90 is faster than about 92 per cent of the sites in that dataset ^[3]. Between roughly 50 and 92 the curve is close to linear, so time shaved off a slow metric buys a predictable number of points; above 96 the same saving buys a fraction of a point ^[4]. The write-up attributes that flattening to the scoring function ^[5].

The run is one simulated load on a fixed device and network profile ^[17]. Since Lighthouse v6, desktop and mobile have used separate scoring curves calibrated to different real-world data. The mobile profile is throttled deliberately, so 100 on desktop and 74 on mobile is expected behaviour ^[11]. For a mobile score to say anything about your traffic, the devices and connections in that traffic have to resemble the throttled profile.

Chrome's scoring documentation lists A/B tests, ad-serving changes, shifting internet routing, device load, browser extensions and antivirus software as normal sources of run-to-run variance, before anything you deployed enters into it ^[9]. Ninety-four one minute and 88 the next is usually the same page measured under slightly different conditions ^[10].

PageSpeed Insights shows lab and field data side by side. Google is explicit that it does not combine them: the 0 to 100 is based entirely on the lab run, and Chrome UX Report data is reported separately ^[12]. Chrome's documentation says good lab data does not necessarily mean real-user experiences will also be good ^[13]. Core Web Vitals is field data at the 75th percentile of real visits over a rolling window. That is what Google's ranking systems read, and a site can hold 100 in the lab while failing in the field ^[14].

Most sites lose more to script execution than to image weight, even though images get blamed and fixed first ^[15]. The remedy in the write-up is sequencing. Defer what the first paint does not need. Split the bundle so the browser is not parsing code for features below the fold, and load third-party scripts after first interaction, since visitors came for something else ^[16].

The write-up documents what the composite contains and how much a single run moves; it does not count how many teams gate a release on the number. Chasing it does force real fixes ^[18]. In my view a 100 is an honest certificate for the simulated load and nothing more, and the responsiveness check belongs on field INP.