Checking website speed is not a matter of pasting the homepage into one tool and saving the score. A useful test separates real-user field data from controlled lab diagnostics, covers representative pages, repeats variable runs, and records enough context to reproduce the result.
This guide is a multi-tool workflow. For a detailed explanation of Google's interface, use the separate PageSpeed Insights guide.
Choose the pages and journeys
Test the URLs people actually visit. A homepage can be fast while a product page, category listing, article, search result, or checkout is slow.
Build a small representative set:
- the homepage;
- one typical and one heavy page from each important template;
- the main organic landing pages;
- a signed-in route if it is part of the product experience;
- a meaningful interaction such as opening a menu, filtering a list, or submitting a form.
Use the final canonical production URL, including the real host and HTTPS redirect path. Record whether the page was tested with a cold or warm cache, whether consent was accepted, and whether ads, chat, personalization, or A/B tests were present.
Start with PageSpeed Insights
PageSpeed Insights is a useful first check because it can show two different data sets on one page.
Field data
When a URL or origin has enough eligible traffic, the Chrome UX Report supplies aggregated real-user data. It covers a rolling 28-day period and reports the 75th percentile for metrics including LCP, INP, and CLS. The result may be URL-level, origin-level, or unavailable, so read the label before drawing a conclusion.
Field data tells you what visitors experienced. It does not show a detailed trace for one request, and it changes gradually after a release.
Lab data
PSI also runs Lighthouse in a simulated environment. Lab data is useful for diagnosis and before-and-after checks. The current performance score combines five weighted metrics: FCP, Speed Index, LCP, TBT, and CLS.
Do not call the Lighthouse number "the score Google sees." It is one controlled test, not a direct ranking score. Does Page Speed Affect SEO? explains the Search relationship.
Capture the report URL or export the result, then write down the test time, device mode, Lighthouse version, metric values, and the first few relevant diagnostics. Avoid turning every audit into a task before checking which one affects the measured bottleneck.
Use DevTools to find the cause
Chrome DevTools Performance is better suited to answering "why". The current Performance panel documentation covers live Core Web Vitals, load recordings, runtime interactions, screenshots, and insights.
For a load issue:
- Open a production-like page in a clean browser profile.
- Open the Performance panel.
- Choose the intended network and CPU settings.
- Record and reload.
- Inspect the LCP element, network dependencies, long tasks, layout shifts, and screenshots.
For an interaction issue, start a runtime recording, perform the slow action, then inspect the event and work that delayed the next paint. This is how you find expensive handlers, forced layout, large rendering updates, and third-party main-thread work that a page-load report cannot reproduce.
DevTools can also show live LCP, CLS, and INP as you use the page. Field INP still requires production observation across real visits; a local interaction trace is a diagnostic sample, not the field percentile.
Use a waterfall for delivery problems
A waterfall makes request ordering visible. Chrome's Network panel is enough for many investigations. WebPageTest is useful when you need a controlled remote location, connection profile, filmstrip, repeat view, or shareable waterfall.
Look for:
- redirect chains before the document or key asset;
- slow DNS, connection, TLS, or server response phases;
- an LCP image discovered late through CSS or client JavaScript;
- resources with no compression or ineffective cache headers;
- duplicate libraries, fonts, or analytics requests;
- large assets delivered before critical content;
- third-party requests that block rendering or occupy the main thread.
Test from a location relevant to the audience. A nearby data center can conceal a slow origin or missing edge cache for distant visitors. Keep the location and connection profile identical when comparing releases.
Repeat tests and compare a median
Performance runs naturally vary. Network routing, server load, cache state, ads, experiments, browser extensions, and machine contention can all change a result.
The Lighthouse project recommends running tests multiple times and using an aggregate such as the median instead of trusting a single result. Lighthouse CI runs three times by default and supports additional runs. For a manual investigation, five equivalent runs often provide a more stable comparison than one; the correct count depends on your variance and decision risk.
Do not simply average different environments. A mobile PSI run, a desktop local run, and a remote waterfall are different experiments. Group like with like, preserve individual reports, and compare the representative run plus the spread.
If results vary widely, investigate the variability itself. Check cache outcomes, third-party responses, A/B variants, server timing, and page content before declaring an optimization successful.
Add performance checks to CI
Lighthouse CI can run production-like pages repeatedly during a build. Start with a small set of stable routes and collect reports before enforcing strict thresholds.
Useful controls include:
- a fixed production build and server command;
- a pinned Node, Chrome, and Lighthouse toolchain;
- several runs per URL;
- assertions on objective facts such as resource size, request count, or specific audits;
- metric budgets with enough tolerance for normal variance;
- stored reports linked to the commit.
CI lab checks catch regressions before release, but they do not replace production field monitoring. Use both: CI protects the build, and real-user data verifies the experience.
Record a useful baseline
A baseline should let another person reproduce the test. Store:
- URL and canonical URL;
- commit or deployment identifier;
- date, region, and test tool version;
- mobile or desktop configuration;
- cold or warm cache state;
- consent and authentication state;
- individual runs and representative median;
- LCP, CLS, TBT, FCP, Speed Index, and available field CWV;
- screenshots, waterfall, and trace for the identified bottleneck.
Then make one focused change and rerun the same scenario. A higher aggregate score with a worse LCP or broken interaction is not a valid win.
Use IndieTools Speed to browse published measurements and their recorded dates. For interpreting a green score without overvaluing it, continue with What Is a Good PageSpeed Score? and How to Get a 100 PageSpeed Score.
