A core web vitals audit template structures your speed and UX measurement into actionable findings. This guide walks through template components, fill-out mechanics, and how to translate raw metrics into prioritized fixes that improve LCP, INP, and CLS without guesswork.
Start with a table that logs URL, device type, test tool, test date, and the three core vitals: Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Add columns for Time to First Byte and First Contentful Paint because slow TTFB usually explains poor LCP, and FCP isolates render-blocking resources. Include test location—if you run Lighthouse from a Virginia data center but your audience is in Vancouver, you're measuring theoretical performance, not user experience. For Canadian sites, run at least one test from a Toronto or Montreal node to account for CDN routing and server proximity. Record connection throttling settings (4G, cable, unthrottled) because a perfect score on fiber means nothing if half your traffic arrives on mobile data. This sheet is raw data only; analysis happens in the next tab.
Create a second sheet where each performance problem gets a row: issue description, affected metric, suspected cause, and evidence source. For example, 'LCP 4.1s on product pages' links to 'hero image 1.2MB, no size attributes, lazy-load misconfigured' with evidence from the Network waterfall and Layout Shift panel. Group issues by metric—all LCP problems together, all CLS problems together—so you see patterns. A cluster of layout shifts around ad slots points to async script injection without reserved space; multiple LCP failures on image-heavy pages suggests missing srcset or inadequate compression. Use the Opportunities and Diagnostics sections from Lighthouse or PageSpeed Insights as starting evidence, but verify in Chrome DevTools Performance tab because automated suggestions sometimes misdiagnose render-blocking CSS when the real culprit is slow server response. This classification step transforms scores into fixable tasks.
Add columns for traffic share, business value, and estimated fix effort. A page that gets two visits per month can fail every vital and still rank below a high-traffic template with minor shifts. Multiply the page's monthly sessions by the percentage of users experiencing poor scores (field data from CrUX if available, or assume 100 percent if lab-only). Mark effort as low (config change, attribute addition), medium (image optimization pipeline, lazy-load refactor), or high (full framework migration, third-party script replacement). Plot issues on a two-by-two: high impact low effort goes first, high impact high effort gets roadmapped with developer sprints, low impact high effort gets deferred indefinitely. This prevents the common mistake of optimizing a rarely-visited landing page to perfect scores while the homepage crushes interaction latency for thousands of daily users. Canadian agencies often see this with bilingual sites—fixing the English template but ignoring identical issues on the French version because traffic skew makes the problem less visible.
Reserve rows or a separate sheet for implemented fixes: date applied, pages affected, before-and-after scores, and any side effects. When you compress hero images and add explicit width-height, log the LCP change and note whether CLS improved or worsened (sometimes dimension enforcement shifts layout if CSS wasn't already reserving space). Re-test weekly during active remediation, then monthly after the sprint ends, because some fixes degrade over time—CDN cache expires, a plugin update re-introduces render-blocking scripts, a new ad tag causes layout thrash. Track field data from Google Search Console's Core Web Vitals report alongside lab tests; if lab scores improve but field data flatlines, your fixes work on desktop cable but fail on mobile 4G, which is where most Canadian traffic outside major metros actually experiences the site. The delta column is where the template proves ROI or exposes wasted effort.
Dedicated columns for third-party domains, request count, total bytes, and main-thread blocking time isolate the scripts you don't control. Tag managers, analytics suites, chat widgets, and ad networks routinely account for half of total page weight and most INP degradation. For each script, note whether it's async, defer, or blocking, and whether you can lazy-load it below the fold or wrap it in a facade that defers execution until user interaction. Canadian sites often load US-hosted analytics or ad platforms that add 200-400ms of latency on top of execution cost; switching to a Canadian CDN endpoint or self-hosting Google Tag Manager's container file can shave meaningful milliseconds off TTFB and LCP. Document whether removing a script is feasible—some contracts mandate specific tracking pixels—and flag scripts that fire on every page versus those scoped to checkout or contact forms. This section frequently reveals that a minor conversion-tracking script you added two years ago now blocks INP site-wide.
Define update cadence and owner. If the template lives in a shared spreadsheet, assign edit permissions to developers who implement fixes and view-only access to executives who need status visibility. Add a summary tab with pass/fail counts per metric, average scores, and trend arrows so non-technical stakeholders see progress without parsing raw data. Include a notes column for environmental factors—traffic spikes during a sale degraded server response, a CDN outage skewed one week's tests, a CMS update introduced new render-blocking CSS. When handing off to a client or internal team, provide a filled example row and a blank template so they understand the difference between metric collection and issue analysis. Many teams conflate the two and end up with a list of scores but no remediation plan. The template's structure enforces the diagnostic process: measure, classify, prioritize, fix, measure again. Without that workflow, you're just accumulating numbers.
PageSpeed Insights gives you both lab and field data in one view, which populates the metrics columns and provides initial diagnostics. Chrome DevTools Performance panel confirms root causes—slow server response, large DOM, long tasks—before you log them. WebPageTest offers multi-location testing and filmstrip views that help explain why LCP varies by geography. For Canadian audits, WebPageTest's Toronto and Montreal nodes capture realistic latency. CrUX data from Search Console or the API fills field-data columns with real user measurements, not synthetic tests.
Weekly during active remediation sprints so you catch regressions before they compound. Once fixes stabilize and field data confirms improvement, shift to monthly checks. Run an unscheduled audit any time you deploy major changes—new theme, plugin updates, ad network swap—because those frequently reintroduce problems you already solved. Quarterly reviews catch slow drift like image libraries growing unchecked or third-party scripts adding new tracking pixels. The template is a living document, not a one-time snapshot.
Use separate rows within the same template, tagging each test with device type. Mobile and desktop often fail different vitals for different reasons—mobile suffers from slow network and CPU constraints, desktop from oversized hero images and unoptimized video. Splitting into entirely separate files fragments your view of cross-device patterns. A shared template with device and connection columns lets you spot issues that affect both (server response, render-blocking CSS) versus mobile-specific problems (large DOM, unoptimized fonts).
Lab tests show potential under controlled conditions; field data shows actual user experience across variable networks, devices, and geographies. If lab scores pass but field data fails, your test conditions are too generous—try throttling to Slow 4G or testing from a distant server. If lab fails but field passes, the majority of your real users have better connections or hardware than your test simulated. Trust field data for prioritization because Google ranks on user experience, but use lab tests to diagnose why field data is poor.
Document the constraint and the tradeoff. A mortgage calculator with complex client-side logic may never hit ideal INP on low-end Android devices, but you can reduce severity by code-splitting, lazy-loading dependencies, and deferring non-critical computations. If contractual third-party scripts block progress, log the impact and escalate the business decision—accept the performance cost or renegotiate the contract. The template should show you tried every feasible optimization; sometimes acceptable is the best achievable, and the record protects you from revisiting the same dead ends later.
Yes, but add a summary dashboard tab that translates technical findings into business language. Show before-and-after scores, pages fixed, and remaining issues with effort estimates. Clients care about rankings and conversions, not milliseconds, so connect vitals to outcomes—faster LCP reduces bounce rate on mobile, stable CLS improves form completion, better INP makes filtering and sorting feel responsive. Include screenshots or filmstrips that visually demonstrate the improvement. The raw data tabs stay for your diagnostic work; the summary tab communicates progress to stakeholders who don't need to understand render-blocking resources.