Chat on WhatsApp
Core Web Vitals in 2026: What a Lighthouse Score of 97 Took

Core Web Vitals in 2026: What a Lighthouse Score of 97 Took

The changes that moved a trilingual business site to a Lighthouse score of 97: fonts, images, blocking scripts, and the checks that keep the score after launch. Checked October 2026.

By KYN AI Advisory Team — AI implementation specialists, Singapore

Core Web Vitals are the three measurements Google uses to judge how a page feels to a visitor: how fast the main content appears, how quickly the page responds to a tap, and how much the layout shifts while loading. They are a ranking input, and on mobile they decide whether a visitor stays. This is what it took to bring one of our own trilingual sites to a Lighthouse score of 97, and what keeps it there.

Which changes moved the score most?

In order of effect:

  • Fonts. The site loaded a full Chinese font for three characters in the logo. Subsetting that font to the characters used cut hundreds of kilobytes from every page. The display and body fonts were loaded with font-display swap and preloaded, so text appears immediately in a fallback and swaps without a layout jump.
  • Images. Hero and cover images were served at the size they are displayed, in a modern format, with width and height set so the layout does not shift when they arrive. Images below the fold load lazily.
  • Scripts. Analytics and the chat widget loaded after the page was interactive rather than before. Nothing render-blocking remained in the head.
  • Third-party embeds. A video embed was replaced with a poster image that loads the player on click.
  • Server rendering. Pages are rendered on the server and cached, so the browser receives finished HTML rather than a shell that fills in after a script runs.

None of these are exotic. Each is a decision made at build time, which is why a site built for speed outperforms one tuned after launch.

What do fonts and images cost on a phone?

On a Singapore mobile connection, the two largest costs on most business pages are web fonts and images, because each is a file the browser must download before it can show the page as designed.

  • A font family with several weights can exceed the size of all the page's HTML and CSS combined. Load only the weights used, subset to the characters needed, and declare a system fallback.
  • A single unoptimised hero image can weigh more than everything else on the page. Serve it resized to the largest size it will be displayed at, in WebP or AVIF, with explicit dimensions.
  • A multilingual site compounds the font cost: Chinese and Japanese fonts are large. Subsetting is the difference between a fast page and a slow one.

Measure on a throttled mobile profile, not on an office connection. The score that matters is the one a visitor on a train gets.

What blocks the first paint?

The first paint is the moment the browser draws something. Anything that must finish before that moment delays it.

  • Synchronous scripts in the head. Move them to the end or load them deferred.
  • CSS that is larger than the page needs. Ship the styles the page uses; load the rest later.
  • Fonts without swap. The browser hides text until the font arrives.
  • Redirect chains. Each hop is a round trip before the page even starts.
  • A slow server response. Caching rendered pages at the edge removes this for most visits.

From our own builds: the site's pages are statically rendered at build time and revalidated on a timer, so the server response is a cached file and the first paint depends only on what the page itself loads.

How do you keep the score after launch?

Scores decay as people add things. A new chat widget, a tracking pixel, a larger hero image, and the site is back to where it started.

  • Run Lighthouse in the deploy pipeline on the five most visited pages and fail the build if a score drops below a threshold.
  • Set a size budget for images and fonts and check it on every pull request.
  • Review Search Console's Core Web Vitals report monthly; it reflects real visitors, not a lab test.
  • Treat every third-party script as a cost with an owner who can justify it.

The same build guard that protects URLs and titles can protect speed. A failed build is cheap. A slow site is paid for on every visit.

Does speed still affect rankings?

Yes. Core Web Vitals are a confirmed ranking signal, and on mobile they are a visible one: a page that takes four seconds to show its content loses the visitor before the ranking matters. Speed also affects crawl budget on larger sites, and answer engines prefer pages that render cleanly.

Speed is not a separate project. It is the result of decisions about fonts, images, scripts and rendering made when the site is built, and kept by checks that run on every deploy. For a site built that way from the start, see a fast website build.

Frequently asked questions

Is a Lighthouse score the same as Core Web Vitals?

No. Lighthouse is a lab test on one run. Core Web Vitals in Search Console are measured from real visitors over 28 days. Use Lighthouse to find problems and Search Console to confirm they are fixed.

Does a site builder limit the score I can reach?

Builders decide how the page is assembled, which caps what you can tune. Good scores are possible; the top scores usually need control over fonts, rendering and scripts.

Which score should a business site aim for?

Above 90 on mobile for the pages visitors land on. The home page, service pages and the most visited articles come first.

Checked October 2026.

Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.

Start Building →

Every workflow is custom built for you

Want this running in your business?