Core Web Vitals for Content Sites: Fixes That Matter

Our home page scored 99 on Lighthouse’s mobile performance test on 7 October 2026 (the median of 3 runs), with a Largest Contentful Paint of 1,605 ms, and a guide page scored 100 and painted its largest element in 1,513 ms. Those numbers come from a site made of static HTML, local fonts, one stylesheet and no third-party script on the guide pages. That is the main lesson of this guide: on a content site, Core Web Vitals are mostly decided by what you decline to add.

The three thresholds, and what Google leaves unsaid

Each of the three metrics comes with a fixed threshold, and these are the numbers web.dev publishes.

Google judges them at the 75th percentile of page loads, separately for mobile and desktop. In practice, three visits out of four must reach the largest element within 2.5 s for the page to pass on LCP. A fast run on your own laptop proves little, because the quarter of visits at the slow end is the one that decides.

Google’s documentation says these metrics align with what its ranking systems try to reward. It does not say how much they weigh against the relevance of the content, and nobody outside Google can supply that number. Our reading is to pass the thresholds and then stop, because speed is no substitute for a page that answers the query.

Two kinds of data exist. Field data comes from real visitors and feeds the Core Web Vitals report in Search Console. Lab data, from tools such as Lighthouse, comes from a simulated visit and is for debugging. A new site with little traffic may have no field data to show, so the lab is where most small sites begin.

Our numbers, and how far to trust them

These are Lighthouse mobile results for two pages of this site, measured on 7 October 2026.

The home page scored 96, 99 and 100 over the 3 runs, with a Total Blocking Time of 0 ms in 2 of them and 174 ms in the other; the guide page scored 100 every time. TBT is a lab metric often used as a stand-in for responsiveness, but it is not INP. Our server sends the first byte of a guide page in about 85 ms, the median of 7 requests with curl from our own machine, connection included. Both pages shift almost nothing, 0.002 and 0.000 against the 0.1 budget. A page with a header photograph and web fonts is where we would look first if that figure grew.

To get comparable numbers for your own pages, run Lighthouse from the command line, which makes repeated runs easy to compare:

npx lighthouse https://example.com/ --only-categories=performance --form-factor=mobile --view

Read these as a lab result. Lighthouse’s mobile profile simulates a slower phone and network, and a default page-load run does not measure INP at all, since INP needs real interactions. The numbers say our pages are light. They do not say that visitors on slow phones pass at the 75th percentile, and we have no field report to quote.

Six levers for a site made of articles

1. Make the main image arrive first. On many article pages the largest element is the header image or the first heading, and Lighthouse names the element it measured in its LCP audit. Give the main image fetchpriority="high", do not lazy-load it, and offer several widths so a phone does not download the desktop file. Our header images follow this pattern, and the markup is in the image SEO guide.
2. Give every image dimensions. width and height attributes, or a CSS aspect-ratio, let the browser reserve the box before the file arrives. It is the standard cure for layout shift caused by images.
3. Serve fonts from your own domain. A font host on another domain costs a DNS lookup and a new connection before text can use the font. We bundle Inter and Fraunces at build time and serve them from our own /_astro/ path with font-display: swap. Swap shows text at once in a fallback font but can move the text when the web font arrives, and a fallback @font-face with a size-adjust value narrows the gap. The font files are split by script, so a visitor only fetches the subsets a page’s characters need.
4. Ship little JavaScript. Our pages are static HTML generated at build time, and our guide pages load no third-party script at the moment. INP depends on the main thread being free when someone taps, and every analytics, chat, testing or consent script competes for it. Measure a page before and after you add one, and leave out the ones you cannot justify.
5. Reserve space for what arrives late. Ads, embeds, consent banners and anything inserted by script need a minimum height or an overlay position. The CSS for ad slots is in our ad placement guide, and it matters twice: a late ad is the classic shift, and an ad script is a third-party script.
6. Answer fast and cache well. A static file served by nginx has little to do, and our server response of about 85 ms reflects that. Compress text, cache fingerprinted assets for a long time, and revalidate the HTML so edits appear immediately. Keep redirects to a single hop, because every extra hop is a round trip before the first byte; the HTTPS guide shows the one-step chain.

This is the relevant part of our nginx configuration:

gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css application/javascript application/json image/svg+xml application/xml;

# In the server block: HTML is revalidated on every visit
add_header Cache-Control "no-cache" always;

# Fingerprinted assets never change under the same name
location /_astro/ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

One nginx rule is worth knowing here: add_header directives are inherited from the level above only if the current level defines none. That is why the asset location can set its own Cache-Control without inheriting the no-cache from the server block. The same rule also drops any security headers set at the server level, a trap our security headers guide walks through.

Where to start, and when to stop

Open PageSpeed Insights on a typical article page, on the mobile tab. If it shows field data, read that first, since it is what Google evaluates, and then read the lab results below it. Fix the cheapest problems in this order: image weight, dimensions and priority; fonts; scripts. None of them needs a redesign.

Re-run the lab test and compare the result with the three thresholds, not with 100. Then give the Search Console report time. Field data builds up from real visits, so a fix appears there only after visitors have loaded the fixed pages, and a site with modest traffic may wait a while.

Stop when the three metrics are good. Google gives no weighting, so the difference between 95 and 100 is not worth a day of work, and the same day spent on a page that answers its query better (search intent check) is more likely to matter. Our SEO checker reports server response time, HTML weight, text compression, image dimensions and external scripts for any page, which covers the lab-side causes of the problems above.