Core Web Vitals Audit

Many teams know that Core Web Vitals matter, but their reviews are too shallow to isolate what is actually failing. Someone checks PageSpeed Insights, sees a red score, and starts fixing random assets without separating field data from lab data, template-wide issues from page-specific issues, or loading problems from interactivity problems.

A Core Web Vitals audit should be more disciplined than that. The purpose is to identify which metric is failing, where it is failing, why it is failing, and which templates or assets are creating the bottleneck.

What a Core Web Vitals Audit Should Answer

A proper audit should give you clear answers to these questions:

• Which metric is failing most often?
• Is the issue affecting one URL, one template, or the wider site?
• Are the failures visible in field data, lab data, or both?
• What page elements are most likely responsible?
• Which fixes will actually change user experience instead of just changing test scores?

Without those answers, performance work often turns into guesswork.

Step 1: Start With Field Data

Always begin with real-world data before you make decisions.

Use sources such as:

• Google Search Console Core Web Vitals reports
• PageSpeed Insights field data
• Chrome UX Report where available

This matters because Google's ranking systems rely on field data, not only on a lab simulation.

What To Check First

Review which page groups are failing most often in the field-data reports, whether mobile performance is materially worse than desktop performance, which metric is failing most consistently across the affected groups, and whether the problem is sitewide or limited to one template family.

If the field data is clean but the lab score is weak, you may still have optimisation opportunities, but the commercial priority is usually lower.

Step 2: Map the Audit by Template

Do not audit one random URL and assume the whole site behaves the same way.

Group the audit by page type, for example:

• homepage
• service pages
• city or location pages
• blog templates
• documentation templates
• tool or calculator pages

This makes it easier to see whether the failure is a template problem or a page-specific anomaly.

Step 3: Audit LCP Systematically

LCP measures how quickly the main visible content loads.

LCP Audit Checks

• identify the actual LCP element on the page
• confirm whether it is an image, text block, hero component, or background visual
• review server response time and HTML delivery speed
• check for render-blocking CSS or JavaScript
• check whether the LCP asset is compressed, resized, and not lazy-loaded
• confirm whether client-side rendering is delaying the visible content

Common LCP Failure Patterns

• oversized hero images
• unnecessary carousel or animation layers above the fold
• slow data loading before render
• bloated JS bundles on public pages
• late-loading fonts or CSS affecting initial paint

If public content relies too heavily on client-side rendering, pair this audit with Rendering & JavaScript.

Step 4: Audit INP Systematically

INP measures responsiveness after user interaction.

INP Audit Checks

• inspect long tasks in browser performance traces
• review third-party scripts that run on load or interaction
• check whether handlers trigger expensive rerenders
• check whether the DOM is overly large or unstable on interaction-heavy templates
• identify where layout recalculation or style invalidation happens after clicks or taps

Common INP Failure Patterns

• chat widgets and tracking scripts competing for main-thread time
• heavy menu or filter interactions
• oversized React trees on public templates
• synchronous calculations triggered by user input
• complex dashboards or tools loaded on pages that should remain lighter

INP work often exposes broader frontend architecture problems, not just one isolated widget.

Step 5: Audit CLS Systematically

CLS measures layout instability.

CLS Audit Checks

• confirm whether all images and videos reserve space correctly
• inspect late-loading banners, embeds, or promo modules
• review whether fonts shift layout after load
• check whether consent bars, chat launchers, or utility notices push visible content
• watch for layout movement above the fold during hydration or delayed component loading

Common CLS Failure Patterns

• images missing width and height
• embeds without stable wrappers
• late-loading carousels or charts
• content inserted above existing text
• font swaps that change line height significantly

If layout shift is concentrated around specific reusable components, the fix usually belongs in the template or component system, not in per-page content edits.

Step 6: Use the Right Tools for the Right Layer

Each tool answers a different question.

Tool	Best use
Search Console	identify field-data failures by page group
PageSpeed Insights	compare field and lab data quickly
Chrome DevTools Performance	inspect long tasks, rendering, and layout shifts
Lighthouse	fast lab debugging and regression checks
WebPageTest	compare waterfalls, asset loading, and render milestones

Use the tool to match the audit question. Do not expect one score to diagnose everything.

Step 7: Prioritise Fixes by Template Impact

Once the issues are identified, rank fixes by:

• number of affected pages
• commercial importance of those pages
• severity of the metric failure
• confidence that the fix addresses the root cause

That usually means template-level fixes come before one-off page tuning.

Examples of high-leverage fixes:

• replacing a heavy global script
• improving hero image handling sitewide
• reducing client-side work on public templates
• stabilising a shared chart, embed, or testimonial component

What To Document in the Audit

A useful audit report should record:

• page or template tested
• data source used
• metric affected
• suspected root cause
• evidence or screenshots
• recommended fix
• expected impact
• implementation owner

Without that structure, performance issues often get rediscovered instead of resolved.

Quick Core Web Vitals Audit Checklist

• Field data checked first
• Failing template groups identified
• LCP element confirmed on priority pages
• Render-blocking assets reviewed
• Long tasks and heavy scripts reviewed for INP
• Layout shift sources reviewed for CLS
• Mobile experience checked separately
• Fixes prioritised by template impact and business value

When To Re-Audit

Re-audit after:

• major design or template releases
• CMS or component changes
• large content or media rollouts
• third-party script additions
• site migrations
• performance-related engineering changes

Core Web Vitals should be audited as part of release discipline, not only when rankings or scores have already dropped.

Key Takeaways

• A Core Web Vitals audit should begin with field data, then move into lab debugging.
• The goal is to identify failing metrics, affected templates, and root causes clearly.
• LCP, INP, and CLS should be audited separately because their causes are different.
• Template-level fixes usually produce more durable gains than page-by-page performance tweaks.
• A documented audit process prevents random optimisation work and improves technical SEO prioritisation.

Tools & Resources (Coming Soon)

• Core Web Vitals Audit Worksheet (Coming soon)
• Performance Regression Checklist (Coming soon)
• Template Performance Review Template (Coming soon)

Related SEO Documentation

• Core Web Vitals Explained
• Site Speed Optimisation
• Rendering & JavaScript
• What Is Technical SEO?
• Core Web Vitals Optimization