Page Speed Checker – Test Website Speed & Performance

Page Speed Checker: Reading Core Web Vitals Like It Actually Matters

A page that "feels slow" and a page that fails Google's Core Web Vitals thresholds aren't always the same thing — sometimes a site loads its main content quickly but still scores poorly because of layout shifting or delayed interactivity that a casual visit wouldn't obviously reveal. Getting an actual measurement, not a gut feeling, is the only way to know what's really happening and what's worth fixing first.

Where This Kind of Speed Data Actually Comes From

A page speed checker built on the Google PageSpeed Insights API is making a direct call to Google's own Lighthouse testing infrastructure — the identical engine Google uses internally, not a third-party approximation. This matters because different testing tools can produce meaningfully different numbers depending on their testing conditions; a result sourced straight from Google's own API is the same data Google itself is working from when it factors page experience into search rankings.

The Four Scores, and Why They're Not Interchangeable

Performance measures loading speed and responsiveness specifically. Accessibility checks whether the page can be used by people relying on assistive technology like screen readers. Best Practices covers general web development standards — things like using HTTPS correctly and avoiding deprecated APIs. SEO checks technical on-page factors like meta tags and mobile-friendliness, separate from actual keyword rankings.

A site can score well on Performance while scoring poorly on Accessibility, or vice versa — they measure genuinely different things, so fixing one doesn't automatically improve the others.

Core Web Vitals in Practical, Non-Technical Terms

LCP (Largest Contentful Paint) measures how long it takes for the biggest visible element — usually a hero image or headline — to fully render. Slow LCP often traces back to unoptimized images or a slow server response.

TBT (Total Blocking Time) measures how long the page is too busy running JavaScript to respond to clicks or taps. High TBT usually means too much JavaScript is executing on page load, often from third-party scripts like ads or analytics.

CLS (Cumulative Layout Shift) measures how much content visibly jumps around as the page loads — the classic annoyance of a page shifting right as you're about to tap something. This is almost always caused by images or ads loading without a reserved space, pushing content down after the fact.

Why Mobile Scores Are Almost Always Worse Than Desktop

Google's mobile test simulates a mid-range Android device on a throttled, slower connection — deliberately not testing under ideal conditions. This is intentional, since it reflects the reality that a large share of real visitors are on less powerful devices and slower networks. Because Google uses mobile-first indexing for ranking purposes, the mobile score is generally the more important number to prioritize, even though the desktop number often looks noticeably better.

Turning the Opportunities List Into an Actual Fix Order

Not every flagged opportunity deserves equal priority. A useful approach: start with whatever has the largest estimated time or byte savings attached, since those tend to move the overall score the most per fix. Render-blocking resources and unoptimized images are frequently the highest-impact, lowest-effort fixes — often addressable through basic compression and deferred script loading — before moving on to more involved changes like restructuring how third-party scripts load.

Frequently Asked Questions

How often should I re-test a page after making changes?

Test again immediately after each meaningful change to confirm it actually helped rather than waiting to batch several changes together, since batching fixes makes it harder to tell which specific change moved the score — and re-test periodically afterward, since third-party scripts and ad networks can quietly degrade performance over time without any change on your end.

Why do I get slightly different scores on repeated tests of the same page?

Lighthouse tests run against live network and server conditions each time, so minor fluctuations from server load, CDN caching state, or network variability are normal — a difference of a few points between runs isn't a sign of a broken test, but a large, consistent swing is worth investigating further.

Does a CDN fix every Core Web Vitals metric, or just some?

A CDN mainly helps server response time and therefore LCP by serving content from a location closer to the visitor, but it does nothing on its own for CLS caused by unreserved image space or TBT caused by heavy JavaScript — those require separate fixes at the code and asset level.

Can fixing one metric accidentally make another one worse?

Occasionally — for example, lazy-loading every image can improve initial load time (helping LCP) but sometimes introduces a layout shift if space isn't properly reserved for images as they load in (hurting CLS), which is why it's worth re-testing after each fix rather than assuming improvements are always additive.

Checking more about your site's technical health? Try the Domain Age Checker, Website Traffic Checker, an SSL Certificate Checker, or a Website Uptime Checker to round out your site audit.