Page speed in 2026 is about field data, not lab scores
Lab scores from Lighthouse are useful as a development checkpoint but Google ranks based on real-user field data from CrUX. A Lighthouse 95 means nothing if real users on slow networks see 4-second loads. Use both: lab scores for catching regressions before deploy, field data (via the Core Web Vitals Checker) for what Google actually grades.
This page speed test runs Lighthouse against any URL on simulated mobile and desktop, returning Performance, SEO, Accessibility, and Best Practices scores plus the underlying lab metrics: LCP, FCP, CLS, TBT, Speed Index, and TTI.
What each Lighthouse score means
Performance is the headline number, weighted across the lab metrics below. Above 90 is good, 50 to 89 needs work, under 50 is failing. SEO is a basic on-page check (meta tags, robots, link text, crawlability). Accessibility scores ARIA, contrast, and semantic markup. Best Practices flags HTTPS, deprecated APIs, console errors, and image aspect ratios.
SEO and Best Practices scores at 100 are the bar. Accessibility 100 is harder but achievable with a careful template. Performance is where most sites lose points and where work has the largest SEO payoff.
Why lab and field numbers disagree
It surprises people that a page can score 90 in this lab test and still fail Google's field grading, or the reverse. The two measure different things on purpose. The lab test loads the page once, on one simulated device, on one throttled network, from one location, with an empty cache. Field data is thousands of real loads across every device, network, and country your visitors actually use, averaged over weeks. Neither is wrong; they answer different questions.
Use the lab test for what it is good at: a fast, repeatable signal you can run before every deploy to catch regressions, and a detailed list of specific things to fix on this exact page. Use field data, from the Core Web Vitals Checker, for the verdict Google actually applies. When they disagree, trust the field data for ranking decisions and trust the lab data for knowing what to change. They are partners, not rivals.
The lab metrics that drive Performance score
Largest Contentful Paint (LCP) measures when the largest visible element renders. Under 2.5 seconds is good. The largest element is usually the hero image or H1; optimize whichever it is. Common fixes: preload the hero image, reduce render-blocking JS and CSS, upgrade to HTTP/2 or HTTP/3.
First Contentful Paint (FCP) measures when any visible content appears. Under 1.8 seconds is good. Cumulative Layout Shift (CLS) measures visual stability; under 0.1 is good. CLS issues come from images without dimensions, ads, dynamically injected content, and web fonts loading late.
Total Blocking Time (TBT) measures main-thread blocking during load. Under 200ms is good. Heavy JavaScript is the usual culprit. Speed Index measures how visually populated the page is over time. Time to Interactive (TTI) is when the page becomes fully responsive. Both are derivatives of FCP and TBT.
Mobile vs desktop performance
Google primarily uses mobile-first indexing, so mobile scores matter more than desktop for ranking. Mobile is also where most sites fail badly: simulated mobile uses a 4x CPU slowdown and Slow 4G network throttle, which mimics real conditions for users on cheap Android phones.
The classic gap is desktop 95+ Performance, mobile 35 to 50. That gap usually comes from heavy JavaScript that desktop CPUs chew through but mobile cannot. Cutting bundle size, lazy-loading non-critical scripts, and removing unused libraries close the gap fastest.
Common reasons Performance scores stay low
Render-blocking resources are the #1 issue. CSS and JS in the head block first paint. Inline critical CSS, defer non-critical CSS via media queries, and use async or defer on script tags.
Unoptimized images. Serving 4000x3000 JPEGs to mobile phones wastes bandwidth and decode time. Use responsive srcset, modern formats (WebP, AVIF), and lazy-loading on below-fold images.
Third-party scripts. Analytics, chat widgets, A/B test scripts, tag managers, and tracking pixels often add 1 to 2 seconds of load time each. Audit aggressively. Defer or remove scripts that do not justify the performance cost.
How to read the report without chasing the number
The Performance score is a weighted blend, not a measurement of any single thing. Tools like this surface a colored score, but the real signal lives in the diagnostics underneath: the opportunities (things you can change to save load time) and the diagnostics (context that explains why a metric is high). Read those before you touch anything. A score of 62 with one giant unoptimized hero image is a five-minute fix; the same 62 spread across twelve small issues is a week of work.
Treat the lab metrics as a checklist in priority order. LCP and CLS map directly to two of Google's Core Web Vitals, so they earn attention first. TBT is your proxy for the third vital, INP, which Lighthouse cannot measure directly because there is no real user clicking during a lab run. If TBT is high, INP is almost certainly suffering in the field too, even though this test will not show INP itself.
Remember that every run is a single load on a single simulated device. Two consecutive runs can differ by ten points purely from network variance and the state of third-party servers at that moment. Run the test three times and look at the median before you decide a change helped or hurt. One run proves nothing.
Common mistakes people make with this test
The biggest mistake is optimizing for the score instead of for users. It is possible to game Lighthouse: defer everything, lazy-load content that should be visible, strip features. The score climbs while the actual experience gets worse. The score is a thermometer, not the patient. Fix the underlying load behavior and the number follows honestly.
The second mistake is testing the wrong URL. People test their homepage, see a green score, and assume the whole site is fast. But the homepage is usually the most-optimized page on the site. Test the templates that actually carry your organic traffic: product pages, blog posts, category listings. Those are what Google grades, and they are usually heavier and slower than the homepage.
The third is ignoring caching state. The first visit to a page is a cold load with an empty cache; repeat visits are warm and much faster. Lab tools test the cold load on purpose, because that is the worst case and the first impression. Do not dismiss a poor result by saying "but it is fast for me" when you have already cached every asset from previous visits.
What to do after you run the test
Start with the single largest opportunity the report lists, usually render-blocking resources or an oversized LCP image. Fix that one thing, redeploy, and re-test. Resist the urge to change ten things at once; if the score moves you will not know which change did it, and if it drops you cannot roll back cleanly. Performance work is iterative by nature.
Once the lab score is healthy, stop trusting it and switch to field data. Pair this test with the Core Web Vitals Checker to see what real Chrome users experience, and with the TTFB Checker to confirm your server response is not silently capping every other metric. Lab tools catch regressions before they ship; field tools confirm the fix reached real users. You need both, used at different stages.
Page speed and AI search
AI crawlers (GPTBot, ClaudeBot, PerplexityBot) have stricter timeouts than Googlebot. Slow pages get partial parsing or skipped entirely. Sites with consistent sub-2-second load times get cited more often in AI Overviews because the AI parsers can actually finish reading the page before timing out.
There is a deeper reason performance helps AI visibility. Many AI systems fetch a page once and read its raw HTML rather than fully rendering and waiting on JavaScript the way a browser does. A page that ships its meaningful content in the initial HTML response, and ships it fast, is far easier for those systems to extract and quote. Heavy client-side rendering that a slow Performance score warns you about is the same pattern that leaves AI parsers looking at an empty shell.
AI search will not directly show you a "performance ranking" signal, but the correlation between fast, server-rendered pages and frequent AI citations is increasingly clear in observation. A good Performance score is rarely the thing that gets you cited, but a bad one is frequently the thing that gets you skipped.
There is also a crawl-budget angle. Search engines and AI bots allocate a finite amount of time and bandwidth to your site. When every page is slow, crawlers fetch fewer of them per visit, which means new and updated content takes longer to be discovered and re-indexed. Faster pages let the same crawl budget cover more URLs, so performance work quietly improves how completely and how quickly your site gets crawled, not just how a single page is graded. On large sites this compounding effect can matter more than the headline score on any one page.