How to Check Website Performance and Understand Core Web Vitals

Laboratory tests versus real-user data

Lighthouse through PageSpeed Insights (PSI) runs a synthetic laboratory test: software loads the page under a selected set of conditions. Lab measurements help diagnose a reproducible loading problem and compare changes under similar conditions. They cannot represent every visitor or every possible journey. See Google’s PSI explanation of lab and field data.

The Chrome UX Report (CrUX) aggregates observed experiences from eligible participating Chrome users. User settings, supported platforms and site eligibility limit coverage; this is not every visitor, or even every Chrome visit. It describes experience over a collection period rather than a new test performed when you press Analyze. See the CrUX methodology.

Read the scope before the number

Page-level data concerns a particular page. Origin-level data combines eligible observations across pages sharing an origin: the scheme, hostname and port. For example, https://shop.example.com/products and https://shop.example.com/cart share an origin. http://shop.example.com and https://www.example.com are different origins. An origin is neither automatically a registrable domain nor one page. Default ports are implicit in these examples. See MDN’s definition of an origin.

PeerPeek requests the supplied page URL for its PSI lab audit. In Real-user data it requests the origin directly, dropping the path and query, and labels the result Origin measured. Mobile selects CrUX’s PHONE form factor; Desktop selects DESKTOP. Tablet and an all-device aggregate are not offered. PeerPeek does not query page-level CrUX first or fall back from a page record to an origin record. It also does not use field data embedded in a PSI response to populate this view. The CrUX API’s identifier definitions explain the two available scopes.

Keep four different clocks separate

• CrUX collection period: a rolling 28-day aggregation window, updated daily by Google. Read the displayed start and end dates; this is not a live measurement. A newly eligible site need not have observations from every day of that window. See the CrUX collection-period documentation.
• Lab Measurement date: the provider’s recorded time for that Lighthouse run, when available.
• PeerPeek’s analysis timestamps: record creation and completion describe requesting and storing the analysis. They do not redefine when visitors experienced the page.
• Application freshness: determines whether PeerPeek can reuse a recent result without requesting new provider work. Reuse does not move the measurement time or the CrUX window.

PeerPeek’s default reuse window is 24 hours for regular completed outcomes and one hour for degraded outcomes. These are configurable application settings, separate from Google’s collection period and the full report’s retention. A reuse notice explicitly says that no new measurement was requested.

Core Web Vitals

The three Core Web Vitals describe different aspects of experience. Lower values are better, but each number answers a different question. Google recommends judging field values at the 75th percentile, separately for mobile and desktop. See the Web Vitals overview.

LCP: when the main visible content appears

Largest Contentful Paint (LCP) reports the render time of the largest eligible visible content element, such as a large image or text block in the viewport. Imagine a product page where the navigation appears quickly but the main product photo takes longer: that photo may determine LCP. It is not the moment when every resource finishes loading. See the LCP definition and eligible elements.

A late LCP suggests investigating server response, discovery of the important resource, its download and any delay before rendering. The number alone does not tell you which part is slow. Text can be the LCP element too; optimizing an unrelated image would not address it.

INP: how promptly an interaction receives visual feedback

Interaction to Next Paint (INP) assesses responsiveness to qualifying clicks, taps and keyboard interactions throughout a page visit. For example, a visitor taps a menu and waits before it visibly opens. The interaction latency includes time waiting before event handlers run, time processing them and time until the next paint.

INP is not an average of interaction durations. It generally represents the slowest interaction, with an outlier allowance on visits containing many interactions. It is also not simply backend API response time or the duration of a whole asynchronous operation: a search button can paint a loading state promptly while results arrive later. A visit without qualifying interactions may have no INP. See the INP definition and calculation.

CLS: whether content unexpectedly moves

Cumulative Layout Shift (CLS) measures unexpected changes in the position of visible content. Picture a paragraph jumping down when an ad appears above it, making a reader lose their place. CLS is unitless: 0.1 is neither seconds nor 10%.

CLS uses the largest burst of accumulated shift scores, rather than adding every shift across the entire visit. A burst, or session window, groups shifts less than one second apart and lasts at most five seconds. Shifts shortly after qualifying user input are generally excluded; expected movement is not automatically a layout-stability problem. An initial-load lab run can miss shifts caused later by scrolling, injected content or other activity. See the CLS definition and session windows.

Field thresholds and the 75th percentile

The following field assessment boundaries match the current Google PSI threshold table and the metric documentation above.

Scroll horizontally to read every threshold on a small screen.

Hypothetical example: field LCP p75 of 2.5 seconds means approximately 75% of eligible measured experiences had an LCP of 2.5 seconds or better. It is not an arithmetic mean, and it does not describe every visitor. A single Lighthouse LCP is one lab observation, not that field percentile.

PeerPeek displays the available field LCP, INP, CLS and TTFB values with individual ratings and distribution bars when supplied. The bars show shares of observations in the record’s bands. It does not calculate an overall Core Web Vitals pass/fail or a combined field score. TTFB is a supporting metric, not a fourth Core Web Vital.

For context, Google’s PSI assessment passes an aggregation when all three Core Web Vitals have good p75 values. If INP has insufficient data, good LCP and CLS can still produce a pass. Without sufficient LCP or CLS data, the aggregation cannot be assessed. That is Google’s assessment rule; it is separate from PeerPeek’s individual metric display and a Lighthouse score.

Other report metrics

PeerPeek’s lab summary displays FCP, LCP, TBT, CLS and Speed Index when reported. The field view requests LCP, INP, CLS and TTFB; it does not request field FCP. Time values may be displayed in milliseconds (ms) or seconds (s); 1,000 ms equals one second. Lab values prefer Lighthouse’s own formatted display value.

• First Contentful Paint (FCP): time until the first eligible content, such as text or an image, appears. A logo can appear before the article or product content, so FCP does not establish that the main content is ready. FCP definition.
• Time to First Byte (TTFB): elapsed time from navigation until the first response byte arrives. It can include redirects, service-worker startup, DNS, connection and TLS setup, and waiting for a response. It is not a direct measurement of application execution alone. Early responses such as Early Hints can affect interpretation. PeerPeek shows the available CrUX p75 TTFB, not a standalone lab TTFB summary card. TTFB definition and timing caveats.
• Speed Index: a lab measure of how quickly visible content is populated during loading, calculated from visual progression. It is a time value, not a percentage of resources downloaded. The loading filmstrip, when available, helps explain what appeared. Lighthouse Speed Index.
• Total Blocking Time (TBT): accumulated blocking portions of long tasks on the browser’s main thread during the lab measurement window after FCP, normally ending at Time to Interactive. Only the portion beyond 50 ms of each long task contributes. Hypothetical example: a 120 ms task contributes 70 ms of blocking time. TBT is measured in milliseconds. TBT definition and measurement window.

TBT is not INP. Loading work can provide clues about responsiveness, but low TBT does not prove that later menus, filters or keyboard interactions respond quickly. INP needs observations of interactions; PeerPeek does not substitute a lab TBT value for it.

Lab metric ratings use Lighthouse’s own scores for that run. Field p75 boundaries are not universal lab scoring rules: do not apply the field threshold table indiscriminately to FCP, Speed Index, TBT or every lab result.

Lighthouse category scores

PeerPeek currently requests and displays Performance and SEO, on a 0–100 scale. It does not request or display Accessibility or Best Practices category scores in this checker. A missing score remains unavailable; it is not a score of zero.

The Performance score is a weighted calculation from performance metric scores, not a simple average of the four Lighthouse categories. The weights and scoring curves can change between Lighthouse versions. PeerPeek displays Lighthouse version when the provider supplies it; the application does not pin one universal version for all stored reports. Consult the official Performance scoring explanation for the relevant version rather than assuming fixed weights.

The SEO category checks selected technical basics of the tested page, such as crawlability and page metadata. It does not measure backlinks, keyword rankings or a whole SEO strategy. These are automated page checks, not a sitewide verdict. The Lighthouse overview describes the tool’s audit categories.

In Lighthouse more generally, Accessibility covers automated checks, with additional manual evaluation needed; a score cannot establish full accessibility or legal compliance. Best Practices checks selected browser and web-development practices, including some security-related checks, and is not a complete security audit. Those categories are useful context when reading other Lighthouse reports, rather than additional PeerPeek results. See accessibility scoring and manual checks. A score of 100 in any category does not guarantee an issue-free site.

Use the evidence behind the score

Where the stored lab report is available, PeerPeek presents loading screenshots, a filmstrip, Performance checks and SEO checks. Performance groups include Opportunities and Diagnostics, with separate groups for passed, manual, errored, informative and not-applicable checks when present. A manual or unavailable check is not a successful check.

The Needs attention summary links to relevant metrics and available audit details. Some details include requests, elements or screenshot context when Lighthouse supplies usable evidence; a summary number alone does not identify an exact culprit. Estimated savings can overlap, so do not add them together or treat them as a promised improvement.

Why results differ or data is missing

Repeated lab runs can differ without a code change. Content experiments, ads, third-party scripts, network routing and server load can change what was loaded and how long it took. Use comparable runs to understand the range rather than treating one score as permanent. See Lighthouse’s guide to measurement variability.

Mobile and Desktop select different PSI test strategies, while CrUX’s device filters describe groups of actual devices. They are not identical devices or network conditions. Field data also covers earlier visits and a different population from today’s lab run. An origin-wide field result includes other pages; a fast homepage test cannot explain every experience across that origin.

No CrUX record is neither a good nor a bad performance result. There may be insufficient eligible observations for the origin and selected device, or other eligibility requirements may not be met. Google does not publish an exact visitor-count threshold. See CrUX eligibility requirements.

PeerPeek distinguishes these outcomes:

• No record: a CrUX no-record response is a completed, normal outcome. The report explains that no record exists for this origin. Trying another device or a lab audit answers a different question; it does not fill in the missing field observation.
• Missing individual metrics: available values are shown, with a note naming unreported metrics. A record containing none of the requested metrics is marked incomplete. Missing values are never filled with zero.
• Partial lab result: Lighthouse runtime errors or a missing primary measurement produce a partial-result notice. Run warnings and runtime error details are shown when supplied; do not interpret them as successful checks.
• Request or analysis failure: an upstream request failure is an error state, separate from a valid CrUX no-record answer. A timeout or service failure does not establish that the site has no field data or poor performance.
• Unavailable full report: expiry or a failure loading stored detail can leave summary metrics readable while screenshots and individual audits are unavailable. That is a report-availability issue, not a new measurement.

What to investigate first

Start from the visitor’s symptom, then choose evidence that can test a plausible explanation. The following scenarios are diagnostic approaches, not findings about your site.

A. Main content appears late

Symptom → metrics: the header appears but the main photo or headline arrives late. Examine LCP, then supporting FCP, Speed Index and available field TTFB. Field TTFB and a lab LCP come from different observations; their values cannot be subtracted to produce a proven delay breakdown.

Evidence → possible action: inspect PeerPeek’s available filmstrip and LCP-related audit evidence. Use a browser performance recording and network waterfall to identify the actual LCP element and separate response time, resource discovery, transfer and rendering delay. If evidence points to slow document delivery, investigate redirects, server work or caching. If an important image is discovered late, consider earlier discovery and avoid lazy-loading that image. If transfer dominates, investigate image dimensions, compression and delivery. If rendering waits on scripts or styles, reduce that blocking work. Verify the bottleneck before choosing a change. See Google’s LCP diagnostic approach.

B. The page is visible but interactions feel delayed

Symptom → metrics: a filter, menu or keyboard action responds late. Field INP can support investigating responsiveness, but PeerPeek’s origin p75 does not identify which page or interaction was slow. Lab TBT may suggest loading-time main-thread pressure; it is not conclusive evidence about that interaction.

Evidence → possible action: reproduce the affected action on a relevant device and record it in browser developer tools. Inspect input delay, event-handler work and rendering before the next paint. Depending on that evidence, break up long tasks, reduce handler work, simplify rendering or give immediate visual feedback before asynchronous work completes. Profiling the actual interaction is a separate diagnostic step, not something a loading score performs for you. See Google’s INP investigation guidance.

C. Elements move while the visitor reads or interacts

Symptom → metrics: text jumps, a button moves or an embed pushes content aside. Inspect CLS in both sources. Higher field CLS than initial-load lab CLS is a reason to look beyond startup, not proof that an ad caused the problem.

Evidence → possible action: reproduce the visit, including scrolling and delayed content, and inspect layout-shift events in a browser recording. Look for images without reserved dimensions, injected banners, resizing embeds or ads, and font swaps that change text layout. If confirmed, reserve space with suitable dimensions or aspect ratios, stabilize embed containers, avoid inserting content above existing reading positions, or improve font loading and fallback metrics. Inspect the cause of movement as well as the displaced element. See Google’s CLS investigation guidance.

Verify improvements

Compare the same page URL, source and strategy, with comparable content and relevant test conditions. Record the Lighthouse version and Measurement date when available. Inspect the changed metrics and audit evidence as well as the headline score: an improvement in one metric can coexist with a regression in another.

Use multiple comparable lab runs to judge variability, making sure they are actually new observations. PeerPeek may reuse a recent completed result or follow an equivalent running analysis, and tells you when it does. Reopening a saved result, switching tabs or viewing audit details does not run another test.

CrUX changes gradually as newer observations enter its rolling collection window and older ones leave. Traffic mix, deployment coverage and eligibility also matter. There is no exact date on which a fix is guaranteed to produce a particular field value. Compare the same origin and device and check the collection-period dates.

Keep a record of what was observed

PeerPeek gives an analysis its own result URL. Copy that address to share the recorded result. Download JSON, when available, exports the stored provider report rather than just the visible summary. The report can contain details not rendered in the interface.

Full reports are retained for 30 days by default, independently of the reuse window; configured retention may differ. After expiry, the stored summary can remain while JSON, screenshots and detailed checks are unavailable. A storage or loading failure is different from planned expiry. Download useful evidence while it is available.

Stored reports represent their recorded observations, not continuous monitoring. Return to the Performance Checker to choose the relevant lab or real-user view, and read its scope, dates and reuse notice before comparing results.