Core Web Vitals & Page Speed Audit Template

Free editable Core Web Vitals & Page Speed Audit Template. Copy, personalize, or download the Word .docx template from UNmiss.

Core Web Vitals are the user-experience metrics Google uses to measure real-world loading, interactivity, and visual stability: LCP (<=2.5s), INP (<=200ms), and CLS (<=0.1). This template walks you through benchmarking each metric with field and lab data, diagnosing the root cause, applying proven fixes, and re-testing to confirm the gains stick. Work through the variants in order, or jump straight to the metric that is failing for your URLs.

6 ready-to-use variants

Benchmark & Field vs Lab Data

Establish a baseline for each Core Web Vital before changing anything, and learn which data source to trust for scoring versus debugging.

Set your baseline

Before you optimize anything, capture where each metric stands today for [Page URL]. Google ranks on field data (real Chrome users, the CrUX dataset, a rolling 28-day window), so that is the number that matters for Search. Lab data (Lighthouse, a single simulated load) is for debugging, because it is repeatable and gives you actionable traces.

  • Field source: Pull CrUX data from PageSpeed Insights or Search Console's Core Web Vitals report for [Property].
  • Lab source: Run Lighthouse (Chrome DevTools or PageSpeed Insights) to reproduce and trace issues.
  • Record thresholds: LCP good <=2.5s, INP good <=200ms, CLS good <=0.1; note your current value and the "75th percentile" pass/fail for each.

Field and lab data will disagree, and that is expected. Lab loads on one device and network; field aggregates many. Use lab to find the cause and field to confirm the cure.

Output: a baseline table noting each metric, its current field value, lab value, and pass/fail status for [Date].

Largest Contentful Paint (LCP) Fixes

Diagnose and fix slow LCP so the main content element renders within 2.5 seconds for most visitors.

Make the main content appear fast

LCP measures when the largest visible element (usually a hero image, video poster, or heading block) finishes rendering. The target is <=2.5s at the 75th percentile. Identify the LCP element in Lighthouse, then attack the four phases that delay it.

  1. Time to first byte: reduce server response for [Origin] with caching, a faster host, or edge rendering.
  2. Render-blocking resources: defer non-critical CSS and JavaScript so the browser can paint sooner.
  3. Resource load delay: add preload for the LCP image and set [fetchpriority=high] on it so the browser fetches it early.
  4. Resource render delay: ensure the LCP image is not lazy-loaded and is served in a modern format at the right size.

Avoid loading the hero image via CSS background or client-side JavaScript, since the browser discovers it too late. A directly referenced, preloaded, correctly sized image almost always wins.

Verify: re-run Lighthouse and confirm the LCP element and its load timeline for [Page URL] dropped below 2.5s.

Interaction to Next Paint (INP) Fixes

Improve responsiveness so the page reacts quickly to clicks, taps, and key presses, replacing the older FID metric.

Make interactions feel instant

INP replaced FID as a Core Web Vital in March 2024. It measures the latency of interactions across the whole page visit, reporting roughly the worst one. The target is <=200ms. Poor INP almost always traces back to JavaScript hogging the main thread when the user acts.

  • Find long tasks: use the DevTools Performance panel to spot main-thread tasks over 50ms during interaction on [Page URL].
  • Break up JavaScript: split long tasks into smaller chunks and yield to the main thread so input can be processed.
  • Reduce main-thread work: remove or defer unused scripts, especially heavy third-party tags like [Tag name].
  • Optimize event handlers: debounce expensive work and defer non-urgent updates until after the next paint.
  • Minimize DOM size and layout cost: a large or deeply nested DOM makes every interaction more expensive.

The goal is to keep the main thread free when users click and tap, so the browser can paint a response within the 200ms budget.

Verify: test real interactions and confirm field INP trends toward good for [Property].

Cumulative Layout Shift (CLS) Fixes

Stop content from jumping around during load so the layout stays visually stable below a CLS of 0.1.

Stop the layout from jumping

CLS measures unexpected layout shifts of visible content during the page's lifespan. The target is <=0.1. Shifts frustrate users and cause misclicks, and they nearly always come from elements that load without reserved space.

  • Size your media: always set width and height attributes (or a CSS aspect-ratio) on images, video, and iframes so the browser reserves space before they load.
  • Reserve space for embeds and ads: give slots for [Ad or embed] a fixed min-height container so they do not push content down.
  • Never insert content above existing content: avoid injecting banners, notices, or cookie bars that shove the page down after render.
  • Prevent font swap shifts: preload key fonts and use [font-display] wisely to limit reflow.
  • Reserve dynamic UI space: hold room for elements added by JavaScript so they expand into pre-allocated space.

Treat any "jump" you can see during load as a defect to eliminate.

Verify: watch the load filmstrip and confirm no visible shifts on [Page URL].

Asset & Delivery Optimization

Trim and accelerate the resources a page ships, images, JavaScript, CSS, caching, and CDN, to lift every metric at once.

Ship less, deliver it faster

Most page-speed problems come down to shipping too many bytes or sending them too slowly. Optimizing delivery improves LCP, INP, and CLS together because the browser has less to download, parse, and execute.

  • Images: serve modern formats (such as WebP or AVIF), size them to the displayed dimensions, and compress; lazy-load only below-the-fold images, never the LCP image.
  • JavaScript: minify, tree-shake, and code-split so each page loads only what it needs; defer or async non-critical scripts.
  • CSS: minify, remove unused rules, and inline the critical CSS for above-the-fold content on [Template].
  • Caching: set long cache lifetimes for static assets and use fingerprinted filenames so updates bust the cache safely.
  • CDN: serve assets from edge locations near users and enable compression (Brotli or gzip) at [CDN provider].

Audit third-party scripts ruthlessly, since they are a common, hidden cause of slow loads and poor responsiveness.

Verify: compare total transfer size and request count before and after for [Page URL].

Re-test & Monitor

Confirm fixes worked in field data and set up ongoing monitoring so regressions are caught early.

Confirm the win and keep it

A fix is not done until field data confirms it. Because CrUX uses a rolling 28-day window, real-user improvements take time to appear, so validate in two stages: lab first for instant feedback, then field over the following weeks.

  1. Re-run lab tests: use Lighthouse or PageSpeed Insights to confirm the trace-level issue on [Page URL] is resolved.
  2. Watch field data: track CrUX in Search Console's Core Web Vitals report and wait for the 28-day window to refresh before declaring success.
  3. Set targets: hold every URL group to LCP <=2.5s, INP <=200ms, CLS <=0.1 at the 75th percentile.
  4. Monitor continuously: add real-user monitoring (RUM) or scheduled audits for [Property] so regressions surface fast.
  5. Guard against drift: re-audit after major releases, new third-party tags, or template changes.

Performance is not a one-time project; treat it as an ongoing budget you defend with every deploy.

Output: a before/after report and a monitoring cadence noted for [Date].

How to use this template

  1. Run PageSpeed Insights on your key URLs and record both the field data (CrUX) and lab data (Lighthouse) values for LCP, INP, and CLS.
  2. Compare each metric against Google's good thresholds: LCP <=2.5s, INP <=200ms, CLS <=0.1 at the 75th percentile, and flag every metric that fails.
  3. For failing LCP, identify the LCP element, then preload it, set high fetch priority, remove lazy-loading, and cut render-blocking resources and server response time.
  4. For failing INP, open the DevTools Performance panel during interaction, find long main-thread tasks over 50ms, and break up or defer the JavaScript causing them.
  5. For failing CLS, add width and height (or aspect-ratio) to all images and embeds, reserve space for ads and dynamic content, and stop inserting content above existing content.
  6. Optimize asset delivery by serving modern image formats, minifying and code-splitting JS and CSS, enabling compression and a CDN, and setting long cache lifetimes.
  7. Re-run Lighthouse to confirm each lab-level issue is fixed, then monitor CrUX field data in Search Console, allowing for the rolling 28-day window to refresh.
  8. Set up ongoing monitoring with RUM or scheduled audits and re-test after every major release to catch regressions before they reach users.

Pro tips

  • Trust field data (CrUX) for whether you pass and lab data (Lighthouse) for diagnosing why; expect the two numbers to differ.
  • Never lazy-load your LCP image, and never load it via a CSS background or JavaScript, because the browser discovers it too late.
  • INP problems are almost always JavaScript on the main thread; auditing and deferring heavy third-party tags is often the single biggest win.
  • Eliminate any visible jump during load by reserving space up front; if you can see content move, your CLS will suffer.

Frequently asked questions

What are the three Core Web Vitals and their good thresholds?

Largest Contentful Paint (LCP) should be 2.5 seconds or less, Interaction to Next Paint (INP) should be 200 milliseconds or less, and Cumulative Layout Shift (CLS) should be 0.1 or less. Each threshold must be met at the 75th percentile of real-user visits to be considered good.

What happened to First Input Delay (FID)?

INP replaced FID as a Core Web Vital in March 2024. FID only measured the delay before the first interaction was processed, while INP measures the full latency of interactions throughout the entire page visit, giving a more complete picture of responsiveness.

What is the difference between field data and lab data?

Field data comes from real Chrome users in the CrUX dataset over a rolling 28-day window, and it is what Google uses for ranking. Lab data comes from a single simulated load in a tool like Lighthouse; it is repeatable and ideal for debugging, but it does not reflect what real users experience.

Why does my Lighthouse score differ from the CrUX field score?

Lighthouse runs one load on a specific simulated device and network, while CrUX aggregates many real users on varied devices, connections, and cache states. Disagreement is normal. Use lab data to find and fix the cause, and field data to confirm the fix worked for real users.

Why didn't my Core Web Vitals improve right after I deployed a fix?

Field data updates slowly because CrUX uses a rolling 28-day window, so improvements take weeks to fully appear. Confirm the fix in lab tools like Lighthouse for instant feedback, then watch the field report in Search Console as the window gradually refreshes with post-fix data.

What is the most common cause of poor INP?

Long JavaScript tasks blocking the main thread when a user interacts. When the main thread is busy, the browser cannot process the input and paint a response within the 200ms budget. Breaking up long tasks, deferring non-critical and third-party scripts, and yielding to the main thread are the most effective fixes.