Why Lighthouse 90+ is about money, not speed

We have lost count of how many client dashboards show the same pattern: a beautiful page, a strong offer, and a bounce rate that quietly eats the budget. The culprit is almost never the copy or the design. It is speed. Lighthouse is not a vanity score you paste into a deck. It is a measurable forecast of how many visitors give up before your page is usable, and every one of them is a lead you paid to acquire and then lost.

Every second costs you conversions

A decade of case studies points to the same brutal curve: as load time climbs from one second to three, the probability that a mobile visitor leaves without acting rises sharply. On a B2B landing page doing 10,000 sessions a month, the difference between a 2-second and a 4-second time-to-interactive can be 300 to 500 fewer qualified leads a month. At a cost per lead of even 500 rubles, that is 150,000 to 250,000 rubles of wasted acquisition spend every month, before you have changed a single word on the page.

The damage is not only lost leads. Slow pages also punish the paid channels that feed them. Quality Score in Yandex Direct and Google Ads reacts to landing experience, so a sluggish page raises your cost per click and pushes ads down the auction. You pay more to send people to a page that converts worse. Speed is therefore not a development line item. It is a lever on your entire acquisition economics.

Speed is a revenue metric, not a tech vanity

Teams often treat performance as something the engineering lead cares about and the business ignores until launch week. That framing is expensive. When you frame speed as a conversion and acquisition metric, the investment decisions change. Suddenly it is worth shipping fewer third-party scripts, delaying a fancy animation, or paying for a better hosting tier, because each move has a visible line in the ROMI calculation. The companies that win on unit economics are usually the ones that treated 200 milliseconds as a financial decision, not a technical footnote.

What actually drives speed

Most performance problems come from a short, repeatable list of culprits. We audit each one before it reaches production rather than firefighting after launch.

• JavaScript bundle size and the number of network requests. Every kilobyte of unused framework code is a tax on every visitor.
• Server-side rendering of critical content so the first paint shows real information, not a blank shell.
• Image optimization with modern formats like webp and avif, served at the exact dimensions the layout needs.
• Aggressive caching plus a CDN that puts static assets close to the user, wherever they are.

Core Web Vitals and how search reads them

Core Web Vitals have been a confirmed ranking factor for years, and they map directly onto user behavior. Largest Contentful Paint measures when the main content is visible. Cumulative Layout Shift measures how much the page jumps while loading, the kind of jump that makes you tap the wrong button. Interaction to Next Paint measures how quickly the page responds to a tap. A page that scores poorly on these is not only ranked lower, it feels broken to the person using it.

The practical takeaway is that you cannot optimize the score in isolation. You optimize the real experience, and the score follows. Chasing a green number with hacks that leave the page feeling slow is the exact mistake we see in sites built by teams that treat Lighthouse as a checkbox. Our 90+ scores are a side effect of pages that genuinely load fast, not the goal itself.

Performance starts in design

By the time a page is in code, most of its speed fate is already sealed by the design. Heavy hero videos, eleven font weights, and full-bleed carousels are decisions made in Figma, and each one carries a performance cost the developer has to absorb. We push back on those choices early, proposing lighter patterns that keep the brand intact while protecting the load curve. Design and performance are the same conversation, not sequential departments.

We don't chase a number for its own sake. Lighthouse 90+ is a side effect of a fast site that actually sells.

How we measure and ship

Every project we ship runs through a performance gate before it goes live. We profile on real mobile hardware, not a fast office connection, because that is where your customers actually are. If a change drops the real-world load time, it does not ship. This is not optional polish. It is part of the definition of done.

• Field data from real users via CrUX and Metrica, not just lab tests.
• A performance budget per page: a hard limit on script and image weight agreed up front.
• Weekly regression checks during the build so speed never silently erodes.

The bottom line

If you remember one thing, remember this: a slow site is the most expensive mistake in your funnel because it taxes every other channel you pay for. Fixing it is not a developer favor, it is the highest-leverage ROMI move available to most businesses. Treat speed as money, measure it like revenue, and the results show up in the only column that matters: the leads that actually convert.