Core Web Vitals for Static Sites in 2026: What to Measure, What to Fix First, and What to Ignore

Performance
Browser DevTools showing Core Web Vitals performance metrics for a static HTML website

Static HTML sites are the fastest thing on the web. No server-side rendering, no database queries, no hydration delays—just files served directly from disk or CDN edge. You would think Core Web Vitals would be a non-issue. They mostly are. But “mostly” is the problem, because a single oversized hero image, an unoptimised font load, or a JavaScript carousel widget can drag your Largest Contentful Paint into the red and cost you rankings you should not be losing.

Google’s Core Web Vitals are three metrics: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). They have been ranking signals since 2021, and in 2026 they remain the primary page-experience metrics that Google measures. The good news is that a well-built static site passes all three almost by default. The bad news is that “well-built” disqualifies a surprising number of sites that look fine visually but fail the performance checks that actually matter.

This guide covers what each metric means for static sites specifically, how to measure them without drowning in data, what to fix first when something is wrong, and what you can safely ignore.

The Three Metrics, Explained Without Jargon

Largest Contentful Paint (LCP)

LCP measures how long it takes for the biggest visible element to finish rendering in the viewport. On most pages, this is a hero image or a large heading block. Google wants it under 2.5 seconds. For a static site on a decent host, you should be hitting under 1.5 seconds without trying hard.

When LCP is slow on a static site, the cause is almost always one of three things: a massive uncompressed image, a render-blocking stylesheet or font that delays text rendering, or a slow hosting provider adding server response latency. The HTML itself is rarely the issue. A static HTML file is measured in kilobytes. The assets it references are where the time goes.

Interaction to Next Paint (INP)

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Where FID only measured the delay before the browser started processing the first interaction, INP measures the entire lifecycle—from user input through event handling to the next visual update—across all interactions during the page visit, then reports a value near the worst case.

For most static sites, INP is essentially free. If your pages have minimal JavaScript, there is nothing to block interaction processing. The metric becomes relevant when you add interactive elements: dropdown menus with JavaScript, form validation scripts, image carousels, or accordion widgets. If any of those handlers take more than 200 milliseconds to process and produce a visual update, INP flags it.

Cumulative Layout Shift (CLS)

CLS measures how much the visible content shifts around unexpectedly after the page starts rendering. An image that loads without width and height attributes pushes content down. A font swap changes text dimensions and shoves adjacent elements sideways. An ad slot that renders late displaces the content below it. Each of these movements is scored and accumulated.

Google wants CLS below 0.1. Static sites without ads or dynamically injected content tend to score well here, but images without explicit dimensions and web fonts with poor fallback matching cause problems with depressing regularity.

Why Static Sites Already Have an Advantage

A static site’s response to a request is a file. No application server assembles a page. No database serves content. No template engine compiles output. The server receives the request, finds the file, and sends it. This simplicity means your Time to First Byte (TTFB) is determined almost entirely by your hosting infrastructure—and on platforms like Cloudflare Pages, Netlify, or even a basic CDN-fronted Apache server, TTFB for a static file is typically under 100 milliseconds.

That head start matters enormously for LCP. A dynamic site might spend 400–800 milliseconds generating the page before the browser even receives the first byte of HTML. A static site has already delivered the complete HTML in that time. The browser can begin parsing and requesting assets immediately.

Similarly, most static sites use little JavaScript, which keeps the main thread clear for interaction handling. A React application might ship 200KB of framework code that must parse and execute before the page is interactive. A static site with a small navigation script and a form validator might ship 5KB total. The INP advantage is structural.

The danger is complacency. Because static sites perform well by default, it is easy to add one heavy widget—a chat bubble, an analytics suite, a poorly optimised image gallery—and assume performance is still fine because “it’s just a static site.” Measure. Do not assume.

How to Measure: The Tools That Matter

You do not need a suite of monitoring tools. Two are sufficient for almost every static site.

PageSpeed Insights

Go to pagespeed.web.dev, enter your URL, and run the test. You get two sets of results: lab data (a simulated test run by Lighthouse in a controlled environment) and field data (real-user measurements from the Chrome User Experience Report, if your site has enough traffic).

Lab data is useful for identifying specific issues. Field data tells you what actual visitors experience. If you only have lab data (common for low-traffic sites), focus on the lab results but remember they simulate a mid-tier mobile device on a throttled connection. Your desktop scores will be higher.

The key sections to look at: the three Core Web Vitals scores at the top, the Diagnostics section for specific recommendations, and the Treemap view to see which assets consume the most bytes.

Chrome DevTools Performance Panel

For deeper investigation, open DevTools in Chrome (F12), go to the Performance tab, check “Web Vitals” in the settings, and record a page load. The timeline shows exactly when LCP fires, which element triggered it, and what delayed it. You can also simulate interactions and see INP-relevant timing.

The Lighthouse tab within DevTools runs the same analysis as PageSpeed Insights but locally. Useful for testing changes before you deploy.

What About GTmetrix, WebPageTest, and Others?

They are fine tools. They are also unnecessary for most static sites. PageSpeed Insights gives you the metrics Google actually uses for ranking. Chrome DevTools gives you the diagnostic depth. Adding more tools adds more data without adding more actionable insight. If you enjoy performance analysis as a hobby, go ahead. If you want to fix your site and move on, stick with the two above.

Common LCP Issues on Static Sites

Uncompressed or Oversized Hero Images

The number one LCP problem on static sites. A 3MB JPEG hero image shot straight from a camera and dropped into an <img> tag. The browser must download all 3MB before it can paint the largest element. On a throttled mobile connection, that alone blows the 2.5-second budget.

The fix is compression. A 1600-pixel-wide hero image should be 80–150KB after compression, not megabytes. JPG at quality 75–80 covers most photographic content. Tools like Squoosh, ImageOptim, or even the Save for Web feature in Photoshop handle this. Width and height attributes on the <img> tag let the browser allocate space immediately, which also prevents CLS.

<img
  src="/images/hero.jpg"
  alt="Workshop interior"
  width="1600"
  height="900"
  fetchpriority="high"
>

The fetchpriority="high" attribute tells the browser this image is critical and should be fetched before other images. Use it only on the LCP image—the hero or the largest above-the-fold image. Applying it everywhere defeats the purpose.

Render-Blocking Fonts

Custom web fonts loaded via @font-face block text rendering until the font file downloads. The browser either shows invisible text (FOIT—Flash of Invisible Text) or waits entirely. Either way, your LCP text element cannot be painted until the font arrives.

Add font-display: swap to your @font-face declarations:

@font-face {
  font-family: 'CustomSans';
  src: url('/fonts/custom-sans.woff2') format('woff2');
  font-display: swap;
}

This tells the browser to render text immediately using a fallback system font, then swap to the custom font once it loads. The text is visible instantly, which satisfies LCP even if the final font arrives a moment later.

For even better results, preload your primary font file in the <head>:

<link rel="preload" href="/fonts/custom-sans.woff2" as="font" type="font/woff2" crossorigin>

Render-Blocking Stylesheets

Every <link rel="stylesheet"> in the <head> blocks rendering until it downloads and parses. For a single small stylesheet, this is negligible. For three or four stylesheets totalling 200KB of unminified CSS—some of which applies only to pages the user has not visited—it adds up.

Consolidate into one stylesheet. Minify it. If your CSS is under 14KB, consider inlining it directly in a <style> tag in the <head> to eliminate the extra network request entirely. This is the approach that consistently produces the fastest LCP on static sites.

CLS: The Silent Ranking Killer

CLS problems are invisible to the site owner who always views the page on a fast connection with a warm cache. Layout shifts happen when resources load slowly and the page reflows around them. By the time you look at the page, everything has already settled.

Images Without Dimensions

This is the most common CLS source on static sites. An <img> tag without width and height attributes occupies zero space until the image loads. When the image arrives, it pushes everything below it down the page. That movement is a layout shift.

The fix is trivially simple—always include width and height:

<img src="/images/photo.jpg" alt="Description" width="800" height="600">

The browser reads these attributes during HTML parsing, before the image downloads, and reserves the correct aspect ratio space. Modern CSS with max-width: 100%; height: auto; still makes the image responsive while preserving the reserved space. There is no reason to omit dimensions in 2026.

Font Swap Shifts

When font-display: swap triggers a font replacement, the new font often has different character widths than the fallback. Text reflows, elements shift. You can mitigate this by choosing a system font fallback that closely matches your custom font’s metrics, or by using the size-adjust, ascent-override, and descent-override descriptors in your @font-face rule to fine-tune the fallback to match.

What to Fix First

If your PageSpeed Insights report shows multiple issues, this is the priority order for static sites:

  1. Compress and size your images. This single fix often resolves LCP and reduces CLS simultaneously. It is the highest-impact, lowest-effort change.
  2. Add width and height to every <img> tag. Eliminates CLS from images, takes minutes to implement.
  3. Add font-display: swap to custom fonts. Fixes FOIT and improves LCP for text-heavy pages.
  4. Consolidate and minify CSS. Reduces render-blocking time.
  5. Defer non-critical JavaScript. Move scripts to before </body> or add defer attributes.
  6. Add fetchpriority="high" to the LCP image. Small improvement, but easy to implement.

That list covers ninety percent of the Core Web Vitals issues I encounter on static sites. Work through it top to bottom and re-measure after each change.

What to Safely Ignore

Performance optimisation has a rabbit hole for every metric. Some of those rabbit holes are not worth entering for a static site.

Time to First Byte (TTFB). Important, but on a static site it is determined by your host. If your host is slow, switch hosts. There is no code-level fix for a distant server with cold caches. You cannot optimise your way out of bad infrastructure.

Total Blocking Time (TBT). This Lighthouse-only metric (not a Core Web Vital) measures main thread blocking from JavaScript. If your static site uses minimal JS, TBT is already low. Chasing a perfect score here by micro-optimising a 3KB script is wasted effort.

Performance scores below 100. A PageSpeed Insights score of 94 is not a problem. The score is a weighted composite. Scores above 90 indicate a fast site. Obsessing over the last few points often means implementing fragile optimisations (critical CSS inlining, resource hint tuning) that add complexity without user-perceptible improvement.

HTTP/3 and server push. Yes, modern protocols help. No, configuring them is not your job on a static hosting platform. Cloudflare, Netlify, and Vercel already handle this. Shared hosting generally does not support HTTP/3, and switching hosts is a bigger improvement than any protocol tweak.

How DFM2HTML’s Output Helps

DFM2HTML generates clean, standards-compliant HTML with properly structured elements. Image tags include width and height attributes when the dimensions are known during design. Stylesheets are linked conventionally without inline style sprawl. JavaScript is minimal and placed where it will not block rendering.

This matters because Core Web Vitals problems often originate in the HTML itself—missing image dimensions, inline styles that balloon page weight, scripts loaded synchronously in the <head>. A desktop editor that produces disciplined output gives you a head start. You can review the features page for specifics on how DFM2HTML structures its exported code, and the templates gallery shows the kind of clean, lightweight starting points available.

If you are publishing a folder-based site, your Core Web Vitals audit is straightforward: measure the live pages, work through the fix list above, and re-measure. No build pipeline to reconfigure, no framework cache to invalidate. Change the file, upload it, test it.

For sites using the View Transition API for navigation, note that view transitions do not affect Core Web Vitals scores. CWV measurements apply to the initial page load and in-page interactions, not cross-document transitions. Your transitions can be as elaborate as you like without impacting your performance metrics.

The Bottom Line

Static sites ship fast by default. Core Web Vitals exist to quantify that speed and surface the handful of issues that erode it. For most static sites, the entire optimisation process is: compress your images, add dimensions to your <img> tags, set font-display: swap on custom fonts, and keep your CSS consolidated. That is not a weekend project. It is an afternoon.

Measure with PageSpeed Insights, fix the top issues, re-measure, and move on. The tutorials index covers related topics including image optimisation and CSS delivery if you want to go deeper on any specific area. But for Core Web Vitals specifically, the static site advantage is real—you just need to avoid throwing it away with uncompressed assets and missing HTML attributes.

← Back to Tutorials Download DFM2HTML