Core Web Vitals on a small business site: how we keep PageSpeed green

What Core Web Vitals measure, what a small static site needs to pass, and our before and after: mobile score 90 to 96, first paint 2.86 to 1.70 s.

Published 20 October 2026 · 5 min read · By Kamil HrbáčekwebperformanceSEO

Core Web Vitals are Google's three measurements of how a page feels to real visitors: how quickly the main content appears (Largest Contentful Paint), how quickly the page reacts to a tap or click (Interaction to Next Paint) and how much the layout jumps while loading (Cumulative Layout Shift). A small business site, especially a static one, can pass all three without special tooling. It mostly comes down to not loading things that block the first paint, sizing images properly and keeping scripts light. Below is what the metrics mean, what we changed on flowsmith.online and the measurements before and after, and how we keep it from sliding back.

The three metrics, and the thresholds

Google judges each metric at the 75th percentile of real visits over the last 28 days, the so-called field data from Chrome users. A young or small site often does not have enough visits for field data. Then the only numbers available are lab numbers: PageSpeed Insights loading the page on a simulated mid-range phone over a throttled connection. Lab numbers are stricter than most real visits, which makes them a useful, conservative guide.

Our starting point

We monitor our own sites with Standard, a small quality monitor we built that runs PageSpeed Insights for mobile and desktop on a schedule and keeps the history. On 20 October 2026 the homepage measured:

• Mobile performance 90, accessibility 96, best practices 100, SEO 100.
• Mobile First Contentful Paint and Largest Contentful Paint both 2.86 s.
• The single biggest item: render-blocking web fonts from Google Fonts, about 2.2 s on the simulated phone.

The page is static HTML with no framework. Almost all of the delay came from one external stylesheet request that the browser had to finish before drawing any text.

What we changed

Self-hosted fonts

We moved the two typefaces into the site itself: 16 small WOFF2 files, Latin and Latin Extended subsets, declared inline with @font-face and unicode-range, so a page downloads only the subsets it actually uses. The two weights used above the fold are preloaded. The font files are cached for a year as immutable. This removed the only render-blocking request and two preconnects to third-party hosts.

Images that cannot shift the layout

Every image has explicit width and height, so the browser reserves the space before the file arrives. That is most of what CLS asks of a static site. On this blog, each illustration is served as AVIF with a WebP fallback at two widths, 720 and 1376 pixels, typically 5 to 30 kB, and only the first image on a page loads eagerly. The rest wait until they are scrolled near.

No layout work while the page is parsing

One decorative script measured an element's size synchronously while the page was still loading, which forces the browser to calculate layout early. It now gets its first size from a ResizeObserver instead. A small change, but it is the kind of thing that shows up on a slow phone.

The result

Desktop went to 100 in all four categories. Mobile LCP of 2.55 s in the lab is still just above the 2.5 s line, and we report it as it is. The remaining items are mostly outside the repository: the cache lifetime of a third-party analytics beacon and of the spam-protection widget, the chain of fonts loading after the HTML, and main-thread work on a slow simulated phone. Some are worth fixing, some are trade-offs we accept.

A checklist for a small static site

• No render-blocking requests to other hosts in the <head>: self-host fonts, inline the little CSS the first screen needs.
• Images in AVIF or WebP, at the size they are displayed, with width and height, and lazy loading below the fold.
• The hero image or headline is the LCP element: do not hide it behind a script, a slider or a fade-in animation.
• Third-party scripts only when they earn their place, loaded with defer.
• Long cache lifetimes for fingerprinted or rarely changing assets, set in _headers on Cloudflare Pages.

Keeping it green

Sites rarely get slow in one go. They get slow one embed, one tracking script, one uncompressed photo at a time. Standard scans our production sites daily, and its verdict is deliberately strict: 100 in all four categories on mobile and desktop and no outstanding technical findings, with every exception recorded with a written reason. It does not fix anything itself. It produces a brief for whoever maintains the site, with the scores, likely causes and acceptance criteria. The habit matters more than the tool: measure on a schedule, keep the history, and treat a drop as a ticket.

For the files that make a fast site also findable, see the publishing and discoverability manual and our article on llms.txt. The Cloudflare Pages manual covers headers, caching and preview deploys.

Written from our own production systems. Drafted with AI assistance and reviewed by Kamil Hrbáček.