Why I stopped chasing the Google Lighthouse performance score

Nikolay Kazmin — Wed, 10 Jun 2026 07:37:33 +0000

I co-founded Domestina in 2014 as a Rails monolith, and for the past 7 years I've been its only engineer. SEO is our main growth channel, so a slow mobile landing page and a Lighthouse score of 44 had me genuinely worried.

Last week I sat down to fix it properly.

The biggest win was unglamorous

One ~360KB CSS bundle was render-blocking every page. It included all of Bootstrap, the full icon set, and two datepickers (react-datepicker, flatpickr) that our landing pages never even load. A landing page was downloading the whole app's CSS just to paint an <h1>.

That monolith used to be a best practice, the app was born on Sprockets, where concatenating everything into one fingerprinted, far-future-cached application.css was the documented best practice. On HTTP/1.1, fewer requests beat smaller payloads. HTTP/2 multiplexing and Core Web Vitals quietly inverted that tradeoff. The problem was also that for 12 years, were were just piling styles into one big file, unrealizing how big it had become.

The optimizations

I restructured the CSS into page-set bundles on the existing cssbundling-rails + dart-sass setup: shared.bundle (Bootstrap subset + global chrome), then public.bundle, funnel.bundle, dashboard.bundle, blog.bundle. A landing page now loads shared + public only.
The icon CSS rules were subsetted, but the actual .woff2 was still the full ~2000-glyph file: 131KB → 10.5KB once properly subset (via subset-font, harfbuzz-wasm, no Python). One gotcha: bin/build_icons.js scans for literal bi-* tokens, so dynamically built names like "bi-#{x}" aren't detected and silently drop from the subset. It also has to scan the Ruby that emits icon markup, not just the views.
Domestina operates in 6 countries, each country running its own instance of the web app, and each comes with its own set of locales. All 9 i18n catalogs, around 754KB, were bundled into every market because require() inside an object literal is eager. The runtime filter only chose which catalog to store, not which one to bundle. I genuinely thought I'd fixed this before. The real fix was generating a per-market active_locales.generated.js from the market's supported_locales.

This moved the score from 44 to the low 70s in one shot. FCP and Speed Index both went from 5.8s to 1.7s.

I pressed further

I deferred a render-blocking script — a no-brainer win — and the score went down. The culprit was LCP at ~7s. But the observed LCP was ~440ms in every run. The page painted fast.

The 7s number wasn't real

The 7s was Lighthouse's Lantern simulation. Lighthouse runs the page quickly, then estimates timings on a throttled profile: Moto G Power, 1.6 Mbps, 150ms RTT, 4× CPU slowdown.

Under that model, simulated LCP collapses toward total bytes divided by bandwidth. The tell was that Lighthouse's own metricSavings for LCP was 0ms on every audit. There was no single fixable resource left.
And the lab score is not what Google ranks on anyway. For that, Google uses CrUX field data: real Chrome users, 28-day window, 75th percentile. Ours was 100% of mobile URLs "Good", zero over 2.5s LCP, stable for weeks.
The page was already fast for real people.

So I called it a day

Hitting a green 90 would mean optimizing for a low-end phone on a connection slower than almost anyone in our market uses. The byte cuts still help genuine low-end users, so they weren't wasted. But past that point I'd be polishing an artifact, not improving the business.

What I'd take away

In Lighthouse simulate mode, a bad LCP can be a function of total page weight divided by throttled bandwidth, not paint timing. Look at observed LCP and metricSavingsbefore believing it.
Judge performance by field data (CrUX / Search Console), not a single-run lab score. That's also what Google ranks on.
On a Rails/Bootstrap monolith, the highest-leverage fix is usually unglamorous: get render-blocking CSS down to critical-only.
"I already fixed that" deserves a second look. Filtering usage is not the same as reducing bundle bytes.
Stop when the fixes stop helping real users.

One honest footnote on the year: I'd tried a version of this last summer and got nowhere. What got me through this time was the latest Claude Code, that could actually follow the thread and push back when I was confidently wrong. I gave it plenty to work with.

Migrating Bootstrap 3 to 5 with Claude Code: every gotcha that isn't in the docs

Nikolay Kazmin — Sat, 23 May 2026 12:35:14 +0000

I started Domestina in 2014, and like many apps from that period, the first version was built on Bootstrap 3.1.

At some point we updated to 3.3, but after that the frontend stack mostly froze, because the migration never made sense commercially. It always looked like 1–2 weeks of focused work, a lot of regression risk, and no visible customer value — while the backlog was full of things that customers actually asked for.

Then came Opus 4.6 and over the last few months I managed to ship a large part of the feature backlog that had been sitting around for months and years. That finally gave me room to attack some old technical debt, and Bootstrap, as by far the oldest lib that I used, was a natural place to start.

The migration was done in two very different phase.The first part was surprisingly fast. I gave my custom orchestrator a structured task brief, let it run, and came back about 4 hours later to a mostly working Bootstrap 5 bundle. It handled the mechanical work pretty well: dependency changes, the new SCSS pipeline, class renames, react-bootstrap 2.x, glyphicon → bootstrap-icons, and so on.

The second part was slower and much more manual: about 2 days of going page by page with Claude, fixing the things that only show up when a real, old production app starts running on Bootstrap 5.

I think that with the new AI tools, we'll have a lot of people starting to pay off technical debt. That's why I decided to summarize and share my experience with this migration with the hope that it will save some time to a lot of fellow devs.

Paste it into Claude, ChatGPT, Cursor, etc. before starting a Bootstrap 3 → 5 migration and it should save you from a lot of the weird bugs that are not obvious from the official docs.

Repo: https://github.com/kazmin/bootstrap-3-to-5-migration-prompt

Framework-agnostic. MIT licensed. PRs welcome.

DEV Community: Nikolay Kazmin