Build note

Core Web Vitals Checklist for Static Websites: LCP, INP, and CLS

Published 2026-09-09 by Nguyen LNP. Topic: Core Web Vitals checklist for static websites, static website performance checklist, improve LCP INP CLS, PageSpeed Insights field vs lab data, static site performance testing.

Core Web Vitals checklist for static websites shown as loading, response, and layout symbols

Use this Core Web Vitals checklist for static websites to measure field data, diagnose LCP, INP, and CLS, and verify fixes after deployment.

Data accurate as of September 2026 based on market research

Introduction

A Core Web Vitals checklist for static websites should separate measurement from diagnosis. Check field data, use lab tools to find likely causes, fix the failing metric, and verify the deployed page. Static HTML is a good starting point, but large hero images, late fonts, third-party scripts, and unreserved media can still cause problems.

Google's good thresholds are LCP within 2.5 seconds, INP at 200 milliseconds or less, and CLS at 0.1 or less. The assessment uses the 75th percentile of visits and evaluates mobile and desktop separately. I treat these checks as release evidence, not a one-time score.

Truth Box
Read field and lab data correctly
Fix Largest Contentful Paint
Fix Interaction to Next Paint
Fix Cumulative Layout Shift
Run a release checklist
Compare measurement options
Industry and search context
Common misconceptions
FAQ
Sources
Conclusion

Truth Box

Key point	Practical meaning
Static does not mean automatically fast	The browser still downloads, decodes, lays out, and runs every asset you ship.
Field and lab data answer different questions	Field data describes real visits. Lab data gives repeatable diagnostics.
Each metric has different causes	LCP concerns main content loading, INP concerns interaction latency, and CLS concerns unexpected movement.
The hero needs special treatment	Keep it discoverable, correctly sized, eager-loaded, and high priority when it is the LCP element.
Verification continues after launch	Recheck the live build and watch field data as new visits enter the reporting window.

Read field and lab data correctly

PageSpeed Insights shows CrUX field data under "Discover what your real users are experiencing" and Lighthouse lab data under "Diagnose performance issues." CrUX reflects aggregated field data from eligible Chrome users, not every visitor or browser. Lighthouse runs a controlled lab audit under predefined conditions, and one run can vary.

Evidence	Best use	Main limit
CrUX in PageSpeed Insights	Judge aggregated experience for eligible Chrome users at a URL or origin	A low-traffic URL may have no page-level data
Search Console Core Web Vitals	Find groups of similar pages with field issues	The report is aggregated and not a code trace
Lighthouse and DevTools	Reproduce a problem and inspect resources, rendering, and layout shifts	One lab audit or local recording does not represent the field distribution
First-party real-user monitoring	Tie slow experiences to pages, elements, and interactions	It must be installed and reviewed carefully

The CrUX field data shown in PageSpeed Insights is updated daily and covers the previous 28 days. A fix can improve a lab run while field data still contains older visits. If URL-level data is unavailable, check whether PageSpeed Insights has fallen back to origin data.

Fix Largest Contentful Paint

LCP measures when the largest image, text block, or video visible in the viewport renders relative to navigation. Identify that element in PageSpeed Insights or DevTools, then inspect server response, resource discovery, transfer, and render delay.

For a static page, check these items:

Put LCP content in the initial HTML.
Give an LCP image a real src or srcset the browser can discover early.
Do not add loading="lazy" to the above-the-fold hero.
Test fetchpriority="high" when image priority is the problem.
Serve responsive variants so phones avoid an unnecessarily large desktop file.
Remove CSS and scripts that block the first render without helping the first viewport.
Review web-font delivery when the main heading is the LCP element.

Preload only critical resources, then measure the result.

Fix Interaction to Next Paint

INP measures responsiveness across qualifying interactions. A static build can still have poor INP when JavaScript, event handlers, or third-party code occupy the main thread.

A slow interaction includes input delay, callback processing, and presentation delay. Find the slow part before changing code.

Use field attribution when available. Reproduce the click, tap, or key action in DevTools. Remove unused scripts, delay non-visual work, split long tasks, and reduce DOM or style work.

Lighthouse cannot directly measure INP without real user input. Its Total Blocking Time can expose main-thread risk during page load, but it is not an INP result.

Fix Cumulative Layout Shift

CLS measures unexpected movement of visible content. Google recommends 0.1 or less at the 75th percentile.

Start with space reservation:

Add intrinsic width and height to images.
Give embeds a stable aspect ratio or reserved container.
Keep banners and notices from pushing existing content after first paint.
Review font metrics when a swap changes line breaks.
Test interactions and scrolling, not only the initial load.

Lighthouse can miss shifts that happen later. When field CLS is worse, reproduce post-load behavior in DevTools or collect element-level field attribution.

Run a release checklist

Stage	Pass condition
Baseline	Record field values and repeatable lab results for key templates.
Build	The hero is discoverable, media has dimensions, and non-critical JavaScript does not block the page.
Pre-release	Test mobile and desktop conditions and inspect the failing metric.
Live release	Confirm production HTML, images, fonts, scripts, cache behavior, and analytics.
Monitoring	Watch field trends across important template groups.

The static website SEO deployment checklist covers canonicals, schema, sitemaps, analytics, and live output. The static website analytics guide explains how to verify measurement after deployment.

Compare measurement options

Use PageSpeed Insights for a first check, Search Console for affected URL groups, DevTools for traces, and first-party monitoring when aggregate data cannot name the slow element or interaction. Google uses Core Web Vitals in its ranking systems, but good scores do not guarantee top rankings.

Industry and search context

Name the failing metric, connect it to a resource or interaction, ship one controlled change, and inspect production again. That fits the static-first work in the Nguyen LNP web portfolio and its web build notes.

Common misconceptions

Static pages always pass Core Web Vitals

Static rendering removes some server and rendering work. It does not correct an oversized hero, blocking font, heavy script, or shifting embed.

A Lighthouse score proves what users experience

Lighthouse gives a controlled lab result. Use CrUX or first-party monitoring for real-user evidence and Lighthouse for diagnosis.

A deployed fix should appear in field data immediately

A new lab run can change at once. The CrUX field data in PageSpeed Insights covers the previous 28 days, so older visits remain until new data replaces them.

FAQ

What are good Core Web Vitals scores for a static website?

Aim for LCP within 2.5 seconds, INP at 200 milliseconds or less, and CLS at 0.1 or less at the 75th percentile.

Should I use PageSpeed Insights or Search Console first?

Use Search Console to find affected URL groups. Use PageSpeed Insights and DevTools to investigate a representative page.

Why does PageSpeed Insights show no field data?

The URL or origin may not have enough eligible CrUX samples. You can still use lab data for diagnosis, but label it as lab evidence.

Should a static website lazy-load its hero image?

No, not when the hero is visible in the first viewport or is the LCP element. Use lazy loading for below-the-fold images.

How often should Core Web Vitals be checked?

Run lab checks before and after material releases. Review field trends regularly enough to catch regressions in important templates and traffic paths.

Sources

Conclusion

Set the pass conditions before the next release: one identified LCP element, responsive interactions, reserved layout space, repeatable lab evidence, and a live production check. See the Nguyen LNP web portfolio or email [email protected] for a practical static website review.