Homepage audit guide
Homepage Speed Diagnosis
How to separate real-user Core Web Vitals from a lab run and trace one failing metric to a buyer-visible bottleneck.
Published · Updated
Short answer
Diagnose homepage performance in two layers. First, use sufficient real-user field data at the 75th percentile when it exists: good Core Web Vitals are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1. Then use a controlled lab run to trace a failing metric to its element, resource, long task, or layout shift. Missing field data is unknown, and one lab run is diagnostic evidence rather than proof of every shopper’s experience.
Why it matters
A single performance score mixes different problems and test conditions. A slow largest element, delayed interaction, and unstable layout require different repairs. Separating field evidence from a matched lab diagnosis helps a merchant change the responsible component instead of compressing every image, removing apps at random, or promising a ranking or conversion result that the test cannot prove.
What to inspect
ReviewMyEcom does not currently automate speed or console-error judgments for customers. The free audit can verify bounded HTTPS evidence, but HTTPS is technical trust evidence, not a speed metric. Complete the field, lab, and buyer-impact diagnosis manually:
- Look for sufficient origin- or URL-level real-user Core Web Vitals and record the time window, device scope, and whether URL-level data was unavailable.
- Read LCP, INP, and CLS separately at the 75th percentile; do not replace a missing metric with zero or a single lab score.
- Run a controlled mobile lab test and trace the failing metric to the actual largest element, resource request, long task, interaction, or layout-shift source.
- Verify the buyer-visible effect in the rendered page, change one bounded cause, and retest under matched conditions.
First-party audit pattern
Why the current speed judgment stays manual
In ReviewMyEcom’s July 15 bounded 17-store cohort, the speed candidate produced 3 true positives, 2 false positives, 11 true negatives, and 1 false negative, or 60% actionable precision. The console-error candidate found no independently confirmed actionable positive and missed six observed cases. Both remain customer-unavailable. The retained HTTPS check produced no false positive in its cohort, but it says nothing about LCP, INP, or CLS.
- The record labels field and lab evidence separately and preserves unknown when real-user data is insufficient.
- A failing metric points to the responsible element, resource, long task, interaction, or layout-shift source.
- The retest uses matched device, network, cache, route, and page-state conditions without claiming a business outcome from one run.
Diagram
Field-to-cause diagnosis
Use real-user evidence to choose the metric, then a controlled run to find the responsible component.
Real-user p75 signal
Record LCP, INP, and CLS separately, or mark insufficient field data unknown.
Controlled trace
Reproduce the page state and identify the element, request, task, or shift source.
Matched verification
Change one bounded cause and compare the same conditions without promising uplift.
Symptoms
- Field data shows one Core Web Vital outside the good threshold at the 75th percentile.
- A lab trace identifies a late largest element, a long interaction task, or a visible layout shift tied to a specific component.
- The first buyer action waits on a blocking script or resource in the controlled page state.
- A merchant treats absent URL-level field data as a pass or uses one lab score as a real-user result.
How to check it
- Record the available real-user Core Web Vitals, their 28-day window, mobile or desktop scope, and whether the source reports URL- or origin-level data.
- At the 75th percentile, compare LCP with 2.5 seconds, INP with 200 milliseconds, and CLS with 0.1; preserve insufficient data as unknown.
- Reproduce the live homepage in a controlled mobile lab state with the same route, consent, promotions, and cache conditions, then inspect the trace for the failing metric.
- Name the responsible element or task, make one bounded change, and repeat the same lab conditions; wait for new field data before making a real-user conclusion.
How to fix it
- For LCP, start with the identified largest element and its request path, render delay, or server response instead of compressing unrelated assets.
- For INP, start with the interaction and main-thread work shown in the trace; split or defer the responsible long task without breaking the shopping control.
- For CLS, reserve the required space or stabilize the identified late-loading component rather than applying a blanket layout rule.
- Keep HTTPS repair separate from performance work: it secures the route but does not make LCP, INP, or CLS pass.
Bad, better, best examples
Bad
Synthetic example: one mobile lab score is called the store’s speed, and every image is compressed without identifying the failing metric or element.
Better
Synthetic example: field LCP is outside the good threshold and a matched lab trace points to the hero resource, but the retest changes several apps at once.
Best
Synthetic example: field evidence chooses LCP, the trace identifies one hero request delay, one bounded repair passes a matched lab retest, and field impact remains pending.
Common mistakes
- Treating a Lighthouse-style score as the same thing as real-user Core Web Vitals.
- Reporting missing field data as zero or as a passing result.
- Combining LCP, INP, CLS, console messages, and HTTPS into one generic speed verdict.
- Changing several assets or apps at once, then attributing a lab difference to one unproven cause.
Questions merchants ask
What are good Core Web Vitals thresholds?
Google’s current guidance uses LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, assessed at the 75th percentile. Read each metric and its device/data scope separately.
Is a lab performance score the same as real-user data?
No. A lab run is a controlled diagnostic sample. Field data summarizes real-user visits when enough data exists. Use field evidence to choose the problem and lab evidence to trace a cause.
Does ReviewMyEcom automatically audit homepage speed?
No. Speed and console-error judgments are currently unavailable to customers. The free audit can provide bounded HTTPS evidence, but HTTPS is not a speed measurement; use this guide for the manual performance diagnosis.
Primary references
Primary guidance on how Google uses real-user Core Web Vitals and the 75th-percentile LCP, INP, and CLS assessment.
Primary metric definitions and current good thresholds: LCP 2.5 seconds, INP 200 milliseconds, and CLS 0.1 at the 75th percentile.
Separate the field signal from the lab diagnosis
Run the free homepage teardown for currently supported HTTPS evidence, then diagnose LCP, INP, and CLS manually with matched field and lab context.
Author and editorial note
Substantially revised from ReviewMyEcom’s July 15 speed, console-error, and HTTPS validation plus current Google/web.dev guidance. AI assisted with structure and drafting; the field/lab method, thresholds, synthetic examples, capability boundary, and claims were checked. No ranking, paid-click, conversion, or before/after outcome is claimed.