On 6 October 2026 we measured the SANOCEA insights page with Lighthouse and fixed what it found: a 333 KB logo displayed at 24 px tall, render-blocking third-party fonts, and low-contrast badges. A repeated before-and-after comparison (three runs each, medians) shows page weight down from 882 KiB to 594 KiB, first contentful paint from about 3.0 s to 1.5 s, layout shift from 0.089 to 0.0007, and accessibility from 95 to 100. It does not show a reliable gain in the overall Lighthouse performance score or in largest paint: on our test machine the same page scored anywhere from 35 to 76 between runs. We have no field data for this site yet, so we are not claiming that sanocea.com passes Core Web Vitals.
1. What Google Actually Measures
Google’s Core Web Vitals are three metrics. Google’s guidance is to judge a page by the 75th percentile of real page loads, segmented across mobile and desktop.
| Metric | What it measures | “Good” threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading performance | 2.5 seconds or less |
| Interaction to Next Paint (INP) | Interactivity | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Visual stability | 0.1 or less |
The part most teams skip: Google calls Core Web Vitals “first and foremost, field metrics”, meaning data from real users, and says lab measurement “is not a substitute for field measurement”. A Lighthouse score is useful for finding problems and catching regressions. It is not the thing Google assesses.
2. How We Measured, and Why One Run Is Not Enough
Our first pass was a single Lighthouse run before and a single run after, and it produced a tidy story: a performance score of 47 before and 69 after. We nearly published that. Then an unchanged page (this very article) scored 75 on one run and 47 on the next. A lab score from one run on a busy machine is a coin flip with a decimal point.
So we measured properly. We kept the release that was live before the fixes and served it next to the current release on the same server, then ran Lighthouse three times on each, alternating between them, and compared medians and ranges:
npx lighthouse@12 http://127.0.0.1:PORT/insights/ --only-categories=performance,accessibility --chrome-flags="--headless=new"
| Insights page, mobile, Lighthouse 12 (3 runs each) | Before: median (range) | After: median (range) |
|---|---|---|
| Total page weight | 882 KiB | 594 KiB |
| Colour-contrast failures | 6 | 0 |
| Accessibility score | 95 (95–95) | 100 (100–100) |
| First Contentful Paint | 3.0 s (2.6–4.3) | 1.5 s (1.4–2.9) |
| Cumulative Layout Shift | 0.089 (0–0.119) | 0.0007 (0–0.0007) |
| Performance score | 66 (35–76) | 57 (53–60) |
| Largest Contentful Paint | 4.7 s (3.9–8.1) | 5.3 s (5.2–5.6) |
| Total Blocking Time | 326 ms (286–1,900) | 852 ms (562–1,660) |
How to read it. The rows with no spread are deterministic and trustworthy: weight, contrast and accessibility. First paint and layout shift improved by margins larger than the noise. The last three rows are inconclusive: the overall score, largest paint and blocking time moved in different directions with ranges that overlap or are huge, so we make no claim about them. Six runs is not statistical proof, and the machine was under other load while we measured, which we believe explains most of the spread.
Two more honest limits. Earlier that day Google’s PageSpeed Insights gave the same page a mobile performance score of 71; scores are only comparable within one tool and setting. And PageSpeed Insights showed “no data” for real-user experience on this site, so there is no field result to pass or fail. We have not re-run PageSpeed Insights since the changes.
3. Finding 1: A 333 KB Logo Shown at 24 px
Lighthouse flagged one file for about 332 KB of wasted bytes: the site’s own wordmark. The PNG was 1685 by 241 pixels and 333,025 bytes, displayed 24 pixels tall in the header (22 in the footer), and it was preloaded on every insights page. Every visitor, including those on phones, downloaded a 1685-pixel-wide image to draw a small logo.
| Logo file | Dimensions | Size |
|---|---|---|
| Before | 1685 × 241 px, RGBA PNG | 333,025 bytes |
| After (shown on pages) | 480 × 69 px, palette PNG | 7,830 bytes |
We compared the two renderings side by side at the size they are displayed and could not tell them apart. We kept the full-size original under a new name for social-media preview images and structured data, so those did not shrink. We do not attribute a specific share of the score gain to this change, because we shipped the fixes together.
4. Finding 2: Render-Blocking Third-Party Fonts
The pages loaded their three font families from Google Fonts through a stylesheet that blocks rendering. In a single Lighthouse run it estimated about 830 ms of blocking for that request, plus about 154 ms for the site’s own stylesheet. Google’s guidance on web fonts and layout shift is that swapping a fallback font for the web font moves the text and the content around it, and that loading critical fonts early is part of the remedy.
We stopped depending on a third party. We self-hosted the three families (14 files, covering the Latin and Latin-Extended subsets, which includes the rupee sign), inlined the small font-face rules, and preloaded the two files that matter most. The files sit under a path that is already cached for 30 days, and the page makes no third-party font requests. In the repeated comparison, layout shift fell from a median of 0.089 to 0.0007 (the original page ranged up to 0.119, above Google’s 0.1 “good” line), and first contentful paint fell from about 3.0 s to 1.5 s. Those two moved by more than the run-to-run noise. We cannot separate the fonts from the logo in the first-paint gain, because we shipped both together.
Google’s guidance also lists further options we did not need to use: font-display: optional, which avoids a re-layout by only using the web font if it is ready at first layout, and the size-adjust family of overrides that match a fallback font’s metrics to the web font. They are the next step if a shift reappears.
5. Finding 3: Badge Text That Failed Contrast
Lighthouse reported six colour-contrast failures, all on the small category badges. The badge text used the bright brand colour on a pale tint of the same colour.
| Badge | Contrast before | Contrast after |
|---|---|---|
| Automate (violet) | 4.06 : 1 | 7.75 : 1 |
| Grow (teal) | 3.99 : 1 | 5.01 : 1 |
Normal-size text needs at least 4.5 : 1 under WCAG 2 level AA, and Lighthouse applies that threshold. The design system already had darker text colours defined for exactly this purpose; the badges simply were not using them. The fix was two lines of CSS that switched the badge text to the existing tokens. The accessibility score went from 95 to 100.
6. What We Did Not Fix
- Unused JavaScript. Lighthouse still reports roughly 116 KiB of unused JavaScript on the insights page. These are static pages that still load React to hydrate. Removing that is a larger change we have not made.
- Largest paint. In our lab runs it stayed around 5 s, well above Google’s 2.5 s “good” line, and our repeated runs show no reliable change. We have not yet pinned down what holds it back.
- Field data. We cannot say how real visitors experience the site until it has enough traffic for Google to report it.
- The homepage. Its design and code were not changed in this pass.
7. A Checklist for Your Own Store
List your largest image requests and check each against the size it is drawn at. Logos and icons are the usual offenders.
A preloaded small logo competes with the stylesheet and fonts that the page needs first.
Check that characters such as the rupee sign are covered before you drop a subset.
A change that removes blocking can introduce a visible shift. Measure both.
Small badges and labels are where brand colours most often fall below 4.5 : 1.
Keep the old version available, alternate runs, publish medians and ranges, and record the date and environment next to every number.
A good lab score is a reason to look closer, not a result.
If you would like this kind of measured pass on your own site, write to hello@sanocea.com. We will measure before and after the same way we did here: repeated runs, medians and ranges.
Sources
- Google, web.dev: Web Vitals (metrics, thresholds, 75th percentile, lab versus field).
- Google, web.dev: Optimize Cumulative Layout Shift (web fonts and layout shift, font-display, preloading, fallback metric overrides).
- Our own measurements: Lighthouse 12 (three alternating runs on each of the before and after releases) and one Google PageSpeed Insights run, on 6 October 2026.