DEV Community: Sonny

Google said my fastest pages were slow: a PageSpeed mystery in three clues

Sonny — Fri, 10 Jul 2026 08:58:59 +0000

My site lans.cloud is 51 static, client-side tools served from one small container. Local Lighthouse scored every page 90+. So when I finally ran the same pages through Google's real PageSpeed Insights (PSI) application programming interface (API), I expected a victory lap.

Instead I got this:

Page	Local Lighthouse	PSI (Google's infra)	PSI Largest Contentful Paint
/classroom-scoreboard	90	100	1.4 s
/my-data	92	100	1.7 s
/spin-the-wheel	93	76	5.6 s
/classroom-timer	95	79	5.2 s
/ (homepage)	92	70	5.6 s

Five pages at 97–100. Five pages at 70–79. Nothing in between — and my local runs had shown no such split. Every failing page failed the same way: a Largest Contentful Paint (LCP) of ~5.5 seconds.

Statically prerendered pages. Same layout, same Cascading Style Sheets (CSS), same fonts. A 5.5-second LCP made no sense.

Clue 1: the "slow" element was innocent

PSI's JSON (JavaScript Object Notation) response tells you which element was the LCP. On every slow page it was… the header description. A server-rendered <p>. Plain text, present in the initial HTML, no image, no font trickery.

The LCP breakdown said: time to first byte, 14 ms. Element render delay, 2,291 ms.

Static text that the browser has from byte one, painting 2.3 seconds late. The element wasn't slow — something was delaying paint itself. Which led to the actually useful query: compare observedLargestContentfulPaint with observedFirstContentfulPaint — the First Contentful Paint (FCP) — in the raw response.

They were identical on every page. Fast pages: LCP = FCP = ~140 ms. Slow pages: LCP = FCP = ~2,300 ms.

So there was never an LCP problem. There was a first paint problem, and the LCP element was just standing nearby when it happened.

Clue 2: it only happened on slow hardware

From my own machine, real Chrome painted every one of those pages in 100–250 ms. Fast club, slow club, no difference.

That's the trap with performance work: my hardware is fast, Google's test runners are deliberately slow. Whatever was delaying paint scaled with processor speed — and disappeared entirely when processing power was cheap.

I diffed everything between a slow page and a fast page: <head> contents, stylesheet lists, script tags, HyperText Markup Language (HTML) byte offsets of the visible text, pending Suspense boundaries. Nearly identical. The slow pages had two extra route-specific JavaScript chunks. That was the whole difference.

Clue 3: the race

Here's the mechanism, and I think it's underdocumented:

Async scripts don't block parsing — but evaluating them blocks the main thread, and paint needs the main thread. On fast hardware, first paint happens long before any script arrives. On a slow machine with fast-arriving scripts, it's a race: if a chunk arrives and starts evaluating before the browser gets around to its first paint, paint waits.

My five slow pages had marginally more JavaScript. Not dramatically more — just enough to tip the race on Google's runners. Five pages painted at 140 ms; five painted after ~2 s of script evaluation.

Then the second mechanism kicks in: PSI uses simulated throttling. It records an unthrottled trace and then a model ("Lantern") estimates what the metrics would be on a slow device and network. The model saw "first paint waited for JavaScript" in the trace and, applying its throttling math to that dependency, projected LCP at 5.5 seconds. The 2.3 s race loss became a 5.5 s headline number.

One trace where paint loses a race by a hair → a model that treats the loss as a structural dependency → a 30-point score gap. That's how five identical-architecture pages split into two clean clubs.

The fix was one line

If paint must win a race, shorten paint's track. My CSS totals ~19 kilobytes, but it shipped as two render-blocking stylesheet requests — the largest fixed cost on the paint path. Next.js has a flag for exactly this:

// next.config.ts
const nextConfig: NextConfig = {
  output: 'standalone',
  experimental: {
    inlineCss: true, // CSS ships inside the HTML — zero blocking fetches
  },
};

With the CSS inlined into the HTML, the browser can paint the moment it has parsed the (single) response. No fetches to wait for, nothing for script evaluation to cut in front of.

Same day, same API:

Page	Before	After
/spin-the-wheel	76	100
/classroom-timer	79	92
/ (homepage)	70	95–99
/random-name-picker	74	96
/classroom-scoreboard (control)	100	99

One caveat from the trenches: the first run right after deploying read lower (68) — cold caches on Google's side. Re-run before you panic; judge trends, not single runs. And inlining CSS is a trade: it's the right call when your CSS is small (mine is ~19 kilobytes and identical across pages); with hundreds of KB of styles you'd be bloating every HTML response instead.

Epilogue: the ghost came back — and proved the point

A week later I probed again on an ordinary evening and nearly relapsed into panic: the homepage read 74. But this time I had a control page — one I hadn't deployed to or changed in any way. It read 95 in the afternoon, 78 an hour after that, 73 by night. Same page, same URL, zero deploys. Back-to-back runs of one page gave first paints of 1.2 s and 3.0 s. And the fingerprint from Clue 1 was back on every page: observed LCP exactly equal to observed FCP, with a two-second "element render delay" pinned on an innocent paragraph.

That's not a website changing three times in an evening — that's shared test runners changing under load. So two rules got added to my monitoring: probe at a fixed quiet hour (mine runs Monday mornings), and always probe a control page you didn't touch. If the control moves with your page, you're measuring Google's infrastructure, not your deploy.

What I actually learned

observedLargestContentfulPaint vs largestContentfulPaint in the PSI response is the single most diagnostic comparison available. Observed is what happened on their hardware; the other is the model's projection. When they diverge wildly, you're debugging the model's inputs, not your page.
LCP problems are sometimes paint problems, and paint problems are sometimes races. If observed LCP equals observed FCP, stop staring at the LCP element.
Local Lighthouse and PSI are different instruments. My datacenter runner was kinder to the slow pages and harsher on the fast ones — systematically. PSI is the number that correlates with how Google sees you; optimize against it.
Get the free API key. The keyless PSI endpoint shares one global quota with the entire internet and is permanently exhausted — I verified by firing at the exact moment of quota reset and still getting a 429. With a key it's 25,000 requests per day, which turned "check PSI sometimes" into a weekly probe in my monitoring.

This is the sequel to my earlier Cumulative Layout Shift (CLS) hunt — same site, same lesson wearing a different costume: the metric that's screaming is rarely the thing that's broken.

The site is lans.cloud — 51 free browser tools, all static, all measured. Happy to answer anything about the setup.

51 tools, one container: build-time reference tables and a CLS bug hunt

Sonny — Thu, 09 Jul 2026 08:49:43 +0000

I've spent the last weeks building lans.cloud: 51 free single-purpose web tools — classroom seating charts, crochet calculators, D&D stat rollers, Minecraft build math. This post is about the three technical decisions that shaped it, and a layout-shift bug hunt that ended somewhere I didn't expect.

The one hard rule: everything computes in the browser

Every tool is client-side. The only server code in the entire project is an anonymous page-view counter (one Postgres upsert) and a feedback endpoint. No accounts, no sessions, and the privacy page can make a claim most sites can't: class lists and student names never reach a server, because there is no code that could receive them.

The payoff is operational: the whole site is statically prerendered by Next.js and served by one 41 MB container behind Traefik on a small VPS. Deploys are docker compose up --build. Capacity planning is "the network port saturates before anything else does."

Reference tables that cannot drift

Every tool page carries reference content — a Minecraft circle block chart, grading tables, dice probabilities, pomodoro preset math. The rule: pages import the tool's own logic library and compute their tables at build time.

<ReferenceTable
  title="Classic tabata 20/10 — total time by number of rounds"
  rows={ROUND_COUNTS.map((rounds) => [
    String(rounds),
    formatTotal(
      totalDuration(buildSchedule({ prepare: 10, work: 20, rest: 10, rounds }))
    ),
  ])}
/>

The table on the page and the timer the visitor runs share one implementation, so they can't disagree. When I added canon Dragon Ball power-level matchups, the lookup throws at build time if a character name doesn't match the data — a typo fails the build instead of publishing a wrong number.

As a side effect, this is SEO content that's genuinely useful and impossible for a scraper to keep current: it regenerates from code on every build.

The CLS hunt: 0.71 → 0

Lighthouse flagged Cumulative Layout Shift 0.71 on the busiest page (threshold for "good": 0.10). Three fixes, each revealing the next problem:

Round 1 — the skeleton mismatch. The interactive tools hydrate behind a Suspense skeleton. The skeletons were ~500px; the hydrated apps were up to 1,186px on mobile. Everything below jumped on hydration. Fix: measure every tool's real hydrated height headlessly at mobile and desktop widths, and put those values as responsive min-height on the wrapper that survives the swap. Result: … CLS unchanged. Correct fix, wrong culprit.

Round 2 — the ad slot. A PerformanceObserver layout-shift trace on the live page showed the entire app area moving as one block: the ad slot above it reserved 90px, but the responsive AdSense unit rendered ~250px. Raised the reservation per breakpoint. Result: better, still failing on one page.

Round 3 — the real culprit. The trace rects made no sense until I measured the <ins> element directly: AdSense's script pre-sizes a full-width-responsive unit to roughly viewport-width height — 412px tall on a 412px phone — before any ad even fills. No reservation short of the viewport width survives that.

The documented escape hatch: give the <ins> an explicit CSS size and remove data-ad-format/data-full-width-responsive. AdSense then serves into exactly that box and never resizes it:

<ins
  className="adsbygoogle block h-[250px] w-full max-w-[336px] lg:h-[90px] lg:max-w-[728px]"
  data-ad-client={CLIENT_ID}
  data-ad-slot={SLOT}
/>

CLS after: 0 on every page I measured. The trade-off is a slightly narrower ad auction than "auto" — but 300×250 is the most-bid display size there is, and CLS is the Core Web Vital that feeds rankings, which feed everything else.

Assorted lessons

A min-height reservation is a guess; a CSS-sized ad unit is a contract.
Measure with PerformanceObserver('layout-shift') sources on the real page — Lighthouse tells you that something moved, the sources tell you what and from where.
If you pipe git commit through tail in a && chain, the pipeline's exit code is tail's. My pre-commit hook failed silently and I deployed a working tree that git didn't have. Check git log origin/master, not exit codes.
Entering browser fullscreen remounts your React tree if the fullscreen branch renders differently. Anything not persisted is gone. Users find this in minutes.

The site is lans.cloud — all free, feedback button on every page. Happy to answer anything about the setup.