Performance and Core Web Vitals audit

Phase P3 · Stage A — Understand
Timebox: 4–8 hours for a representative audit; 2–5 working days for a template-wide investigation with engineering traces. The 28-day field validation happens after fixes and does not extend the initial audit timebox.
Owner: the technical SEO lead owns scope and acceptance. A performance engineer or senior front-end engineer owns diagnosis; platform, CDN, analytics, design, and product owners contribute where their systems create delay or instability.

This phase converts real-user field evidence and repeatable lab tests into a remediation register tied to URLs, templates, metrics, owners, and done-when tests—not a generic speed score.

Why this phase, and why here

Performance belongs in Stage A because a page that times out is a crawl problem before it is a user-experience problem. A crawler or retrieval agent has a finite request budget. If the origin stalls, redirects repeatedly, or returns an incomplete response, the client may abandon the page before it can evaluate the content. Faster headings, better copy, and stronger schema cannot help content that is not retrieved reliably.

P3 consumes the canonical hosts, intended indexable templates, priority journeys, status-code evidence, and unresolved infrastructure findings from the technical baseline audit . That order prevents false diagnosis. For example, a five-second “page load” caused by a redirect loop is not an image-optimization task, and a fast test of a cached error page is not a pass. P2 establishes that the right URL can be requested and selected; P3 establishes that it can be delivered and used within acceptable time and stability limits.

Running this phase late creates rework. A content team may publish into a template whose hero is always the slowest element, or approve a promotional slot that shifts every product card. The defect then multiplies across new pages.

Inputs and outputs

Inputs make the sample representative. Outputs form the contract with the next phase: exactly which pages are reliably available, which conditions remain weak, and which performance limitations must qualify later measurements.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

Field data and lab data are different evidence

Field data describes what eligible Chrome users actually experienced. The Chrome User Experience Report, usually shortened to CrUX, aggregates measurements from real visits and reports the 75th percentile: the value at or below which 75% of recorded experiences fall. It includes the messiness of real devices, networks, locations, caches, consent tools, sessions, and interactions. Use it to decide whether users pass the published thresholds and whether a shipped change eventually improved the population.

Lab data describes one controlled page load or interaction under declared conditions. Lighthouse is a lab test that applies device and network simulation, captures a trace, and explains likely causes. Use it to reproduce a problem, compare two builds under the same setup, inspect request chains, and identify work. A lab score is useful evidence, but it does not prove that real users pass.

The two sources can disagree without either being wrong. A fast lab run may use a nearby location, warm CDN, and no meaningful interaction, while field visitors include older phones and distant networks. Record the disagreement and investigate its conditions; never average the values or choose whichever looks healthier.

The checklist

Complete these checks in order. Every item states the action, reason, method, tool, and acceptance condition so it can be assigned and retested.

1. Freeze the representative URL and condition matrix

What: define the URLs, templates, device profiles, geographies, consent states, and cache states to test. Why: a homepage-only audit can pass while the product, article, or checkout template fails. How: join the P2 inventory with traffic and business-priority data; select typical, heavy, and conversion-critical examples. Tool: analytics, crawl inventory, release register, and a shared test sheet. Done when: every priority template has an owner-approved production sample and every test records device, network, location, login, consent, and cache assumptions.

2. Capture the CrUX field baseline

What: record available p75 field metrics at URL level and, separately, origin level. Why: the origin can hide a weak template, while an individual low-traffic URL may have no publishable data. How: use the same observation date and 28-day window, label URL versus origin explicitly, and record blank values as “insufficient data.” Tool: AmICited Web Vitals and CrUX. Done when: every sampled URL has LCP, INP, CLS, FCP, and TTFB values or a documented unknown state; source level and window are unambiguous.

3. Verify response reliability before scoring pixels

What: repeat requests and record status, redirects, Time to First Byte (TTFB), timeouts, and inconsistent responses. TTFB is the interval from request start until the first response byte arrives. Why: a page cannot paint before its HTML begins arriving, and an intermittent failure is more severe than a cosmetic slowdown. How: test cold and warm cache behavior from relevant regions, inspect server timing, and correlate anomalies with CDN and origin logs. Tool: request monitor, browser network panel, CDN/origin observability, and Lighthouse waterfall. Done when: priority URLs return the intended 200 response without unexpected hops or timeouts, and every slow or failed response has a logged finding with an owner.

4. Diagnose Largest Contentful Paint

What: identify the Largest Contentful Paint (LCP) element and break its time into server delay, resource discovery, resource download, and render delay. LCP measures when the largest visible image or text block finishes rendering. Why: compressing an image does little when the browser discovers it late, and front-end changes cannot erase a slow origin wait. How: inspect the trace and waterfall, compare cached and uncached runs, check preload priority, responsive image sizing, render-blocking resources, font behavior, and client-side rendering. Tool: Lighthouse, browser performance tools, request waterfall, and image inspection. Done when: the actual LCP element and dominant subpart are named for every failing template, with a reproducible before measurement and a specific fix hypothesis.

5. Diagnose Interaction to Next Paint

What: test the Interaction to Next Paint (INP) path for real actions such as menu opening, filtering, adding to cart, form input, and consent dismissal. INP measures the delay from a user interaction until the browser displays the next visual update, using a high-latency interaction from the visit. Why: a page can appear complete but still ignore the user while JavaScript occupies the main thread. How: reproduce important actions, inspect long tasks and event handlers, test third-party scripts, and separate input delay, processing time, and presentation delay. Tool: CrUX, browser performance trace, interaction profiling, and a realistic device. Done when: every important interaction has been exercised, the slow interaction and responsible task are identified for failing templates, and the fix has a repeatable interaction test.

6. Diagnose Cumulative Layout Shift

What: locate unexpected movement contributing to Cumulative Layout Shift (CLS). CLS is a unitless score representing unexpected visual movement during the page’s life. Why: a late banner, unsized image, swapped font, ad, or hydrated component can move the link a user is about to click and can change where automated extraction finds content. How: use layout-shift regions and a filmstrip, test delayed assets and consent states, and inspect elements without reserved dimensions. Tool: CrUX, Lighthouse trace, browser rendering diagnostics, and visual regression capture. Done when: each material shift has a source element, trigger, and reserved-space or rendering fix; expected movement caused immediately by a user action is documented separately.

7. Use FCP to separate blank-screen delay

What: measure First Contentful Paint (FCP), the time until the browser renders the first text, image, canvas, or SVG content. Why: FCP distinguishes an early sign of progress from a page that remains blank, even though it does not prove that the main content is ready. How: compare FCP with TTFB and LCP, then inspect blocking CSS, fonts, scripts, server-rendered markup, and streaming behavior. Tool: CrUX, Lighthouse, and the network/performance trace. Done when: every slow FCP is assigned to server delay, render blocking, client-only rendering, or another evidenced cause, rather than described merely as “the page feels slow.”

8. Rank findings by severity, reach, and dependency

What: order the backlog by failure band, affected traffic and templates, business criticality, and upstream dependency. Why: fixing five yellow scores can consume the sprint while one red TTFB failure delays every page on the origin. How: place reliability failures first, then poor metrics before needs-improvement metrics; within the same severity, fix shared platform causes and TTFB before downstream LCP work. Tool: findings register, analytics, template inventory, and engineering estimate. Done when: every finding has a severity, affected URL count or template scope, evidence, owner, effort, dependency, and explicit priority.

9. Validate implementation in the lab

What: compare the changed build with the recorded baseline under identical conditions. Why: field data cannot provide immediate release feedback, and an unrepeatable “after” run cannot establish that the code change caused the difference. How: run multiple controlled samples, compare medians rather than the single best run, inspect the trace for regressions, and test critical interactions and layouts. Tool: Lighthouse, browser performance tools, staging or controlled production release, and request monitoring. Done when: the intended cause is removed, the target metric passes the agreed lab budget across repeated runs, no other critical metric regresses, and evidence is attached to the finding.

10. Annotate the release and wait for field confirmation

What: record deployment time, scope, expected metric, and validation dates. Why: CrUX is a rolling 28-day window, so pre-release visits remain in the reported percentile after the fix ships. How: monitor errors immediately, check directional field movement as new data arrives, and make the final comparison only when enough post-release days represent the window. Tool: deployment log, AmICited Web Vitals, CrUX, and monitoring. Done when: immediate technical checks pass, the release annotation is visible, and a named owner and date exist for field confirmation; the finding is not marked “verified” from lab evidence alone.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Tools in AmICited

Open https://app.amicited.com/audit/web-vitals to compare your domain with tracked competitors using real-user CrUX data. The audit places LCP, INP, CLS, FCP, and TTFB in one table, marks your domain, and makes missing field data visible rather than turning it into a misleading zero. Use the comparison to answer two questions: whether the domain passes the published thresholds, and whether a competitor serving the same audience has demonstrated a materially better field outcome.

The Performance Impact feature connects page-level performance with citation position and likelihood. Treat the relationship as prioritization evidence, not proof that speed alone caused a citation change. If a slow cited page and a fast uncited page differ in authority, relevance, or content, performance is only one variable. The useful signal is that an affected page is valuable enough to fix and monitor.

For product operation, follow How to Check Your Core Web Vitals in AmICited . This playbook defines audit scope, decisions, and handoff; the tutorial covers the clicks and readings, so duplicating it here would create two instructions that can drift.

Decision rules: what bad looks like

Judge Core Web Vitals from field data at the 75th percentile. “Good” means the p75 value is at or below the good boundary. A value on a boundary belongs to the better band; for example, LCP of exactly 2.5 seconds is good. Supporting FCP and TTFB thresholds guide diagnosis and acceptance, but they are not part of the three-metric Core Web Vitals pass assessment.

Use these priority rules:

1. Failed requests, timeouts, and invalid responses outrank scores. Reliability is the delivery gate.
2. Fix poor bands before needs-improvement bands. Red is a demonstrated bad experience, not a polishing opportunity.
3. Fix TTFB before LCP when TTFB is failing. LCP cannot occur before the response begins, so backend delay consumes the LCP budget before the browser can render anything.
4. Prefer shared causes over isolated symptoms. One cache-policy repair across four templates outranks four separate image tweaks with smaller reach.
5. Use traffic and journey value inside the same severity. A poor checkout INP or high-traffic article LCP outranks a low-traffic archive at the same band.
6. Do not call a blank CrUX value good. It is unknown. Use repeatable lab evidence and a comparable template until field volume exists.
7. Do not promise instant field movement. Validate the deploy now, then allow the rolling window to replace older experiences before accepting or rejecting the field outcome.

Deliverable: the performance remediation register

Hand engineering one register plus its evidence folder. A spreadsheet, issue tracker, or structured project table is acceptable if it preserves these fields and permits filtering by template, severity, owner, and status:

ID and finding:
Affected URLs and templates:
Priority journey and traffic context:
Metric and field band:
CrUX level, p75 value, and 28-day window:
Lab configuration and repeated baseline:
Observed cause and evidence reference:
Expected condition and target:
Recommended change:
Severity and priority rationale:
Owner, dependency, and effort:
Release date and annotation:
Immediate lab acceptance result:
Field confirmation date and result:
Status: Open | Planned | Lab accepted | Field verified | Accepted risk

Attach the URL matrix, CrUX export, lab traces, waterfalls, filmstrips, interaction recordings, layout-shift evidence, and release annotations. Deduplicate by cause: if the same uncached origin query creates poor TTFB across three templates, create one parent finding with three affected scopes rather than three competing diagnoses.

“Accepted risk” needs a named approver, reason, affected scope, expiry or review date, and monitoring condition. It is not a substitute for an owner. The handoff is complete when an engineer can reproduce the failure and the next-phase owner can identify which results remain limited by performance.

What goes wrong

Treating Lighthouse as the verdict. A score of 100 in one lab run does not override poor p75 field data. Preserve Lighthouse as diagnostic evidence and CrUX as population evidence.

Testing only the homepage. Sample every high-value template plus a heavy example, or template defects will escape the audit.

Optimizing the LCP image before checking TTFB. The asset may be small while the origin spends two seconds generating HTML. Break LCP into its components and fix upstream time first.

Using the single fastest run. Cache warmth, background activity, and network variation can create a flattering outlier. Keep the configuration fixed and compare repeated-run medians.

Declaring victory the day after release. The lab can prove that code and delivery changed immediately; the 28-day field window cannot. Annotate the release and schedule field acceptance.

Marking missing CrUX data as zero. No data means the eligibility or traffic threshold was not met. It says nothing about performance quality.

Chasing the composite score instead of the failing experience. A summary score can improve while a checkout interaction still stalls or a hero still shifts. Accept named metrics and journeys, not cosmetic score movement.

Removing useful functionality to win a test. Deleting consent, personalization, analytics, or accessibility behavior from the lab variant produces a result users never receive. Optimize the production requirement or make an explicit product decision.

Ignoring regressions outside the target metric. Deferring scripts can improve LCP but create poor INP on first interaction; reserving the wrong dimensions can replace a load delay with CLS. Retest all five metrics and the critical journey.

Next phase: AI accessibility and agent readiness

The AI accessibility and agent readiness phase receives the representative URL matrix, response-reliability evidence, TTFB distribution, unresolved performance findings, and a statement of which content is present in the initial response. Its owner uses that evidence to distinguish an access-policy failure from a delivery failure and to reproduce the real conditions under which an agent fetches the page.

The next phase may proceed when critical URLs respond reliably and no unresolved performance defect makes retrieval evidence uninterpretable. It may proceed with a written limitation when a needs-improvement metric affects users but does not prevent stable access. It should pause for affected templates when requests time out, return intermittent errors, or the main response regularly exceeds the agreed critical threshold.

The handoff is complete when the next owner knows which URLs represent each template, the test conditions, the remaining delivery failures, and whether P3 evidence already explains a slow agent fetch.

FAQ

Frequently asked questions