Page Speed Checker (Core Web Vitals)

A page speed checker tells you how quickly a page loads and responds, and why. Our free tool runs Google PageSpeed Insights on any URL for both mobile and desktop, then shows the performance scores, the lab metrics behind them, and the Core Web Vitals that real Chrome visitors experienced: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Each slow area comes with a plain-English fix, so you know what to ask your developer or change in your CMS.

How to use the Page speed checker

1. 1 Sign in and open the checkerLog in to your free account and open the Page Speed Checker from the tools list.
2. 2 Enter the exact pagePaste the full address of the page you care about, such as a product or service page, not just the homepage. The test takes up to a minute because Google loads the page twice.
3. 3 Start with real-user dataRead the Core Web Vitals section first. If Google has enough Chrome data, this is what its page experience signals use.
4. 4 Work through the opportunitiesEach opportunity shows the time it could save and what to do about it. Start with the biggest saving.
5. 5 Retest after changesLab scores update straight away. Real-user data is a 28-day rolling average, so allow about four weeks for fixes to show in full.

What this page speed checker measures

There are two very different kinds of speed data, and this checker shows both. Lab data comes from Lighthouse, the testing engine inside PageSpeed Insights. Google loads your page once on a simulated mid-range phone with a throttled mobile connection, and once on a simulated desktop, and records exactly what happens. Lab data is repeatable and great for diagnosing problems, but it is one visit, from one place, on one device profile.

Field data comes from the Chrome User Experience Report, usually shortened to CrUX. It is collected from real Chrome users who have opted in to sharing usage statistics, and it covers the previous 28 days. Google reports the 75th percentile, which means three out of four visits were at least that fast. Field data is what your visitors actually lived through, on their own phones and connections, and it is the data Google's page experience signals are based on.

The two often disagree. A page can score poorly in the lab because the simulated phone is slow, while real visitors on newer phones have a good experience. The reverse also happens, for example when a cookie banner or chat widget only appears for real visitors. When they disagree, trust the field data for how you are doing, and use the lab data to find out why.

Core Web Vitals explained: LCP, INP and CLS

Core Web Vitals are three measurements Google uses to describe loading, responsiveness and visual stability. Each has a good threshold and a poor threshold, measured at the 75th percentile of visits. A page passes the Core Web Vitals assessment when all three are in the good range.

Interaction to Next Paint replaced First Input Delay as the responsiveness metric in March 2024. INP is stricter: instead of measuring only the delay before the first tap is handled, it looks at how quickly the page visibly responds to taps, clicks and key presses throughout the whole visit. Pages heavy with JavaScript, such as those built with large page builders or loaded with third-party tags, often struggle with it.

• Largest Contentful Paint (LCP): how long until the biggest image or block of text in the first screen appears. Good is 2.5 seconds or less; poor is over 4 seconds.
• Interaction to Next Paint (INP): how quickly the page responds visibly after a tap, click or key press. Good is 200 milliseconds or less; poor is over 500 milliseconds.
• Cumulative Layout Shift (CLS): how much the content jumps around unexpectedly while the page is in use. Good is 0.1 or less; poor is over 0.25.

How the PageSpeed score out of 100 is calculated

The performance score is a weighted blend of five lab metrics. In current versions of Lighthouse, Total Blocking Time carries 30 per cent of the weight, Largest Contentful Paint and Cumulative Layout Shift 25 per cent each, and First Contentful Paint and Speed Index 10 per cent each. Each metric is scored against real-world data from the HTTP Archive, so the score reflects how your page compares with other sites on the web.

Scores from 90 to 100 are shown in green, 50 to 89 in orange and below 50 in red. Mobile scores are almost always lower than desktop, because the simulated phone has a slower processor and a throttled network. A mobile score in the 60s or 70s is common for real business sites and is not a disaster if the field data is good.

Expect the score to move by a few points between runs. Lighthouse runs on shared Google servers, and small differences in server load, network timing and third-party scripts change the result. Do not chase single points; look for big, repeatable differences after a change.

• First Contentful Paint (FCP): when the first text or image appears.
• Speed Index: how quickly the visible part of the page fills in overall.
• Total Blocking Time (TBT): how long the main thread was blocked by long tasks between FCP and the page becoming usable. It is the lab stand-in for INP.

Common causes of a slow page and how to fix them

Most slow small-business sites suffer from the same handful of problems. Oversized images are the most common: a photo straight from a phone can be several megabytes when it only needs to be a hundred kilobytes or so. Resize images to the size they are displayed at, save them as WebP or AVIF, and lazy-load anything below the first screen. Never lazy-load the main hero image, because that delays Largest Contentful Paint.

Slow server response is the next big one. If the server takes more than about 600 milliseconds to start sending the page, everything else is late. Page caching, a content delivery network such as Cloudflare, and better hosting all help. On WordPress, a caching plugin plus decent hosting often halves load times on its own.

Too much JavaScript hurts both Total Blocking Time and INP. Every analytics tag, chat widget, review carousel, heatmap tool and social embed adds work for the browser. Audit your tags once a year, remove what nobody uses, and delay the rest until after the page has loaded or the visitor interacts.

Layout shift usually comes from images and embeds without set dimensions, adverts and cookie banners that push content down, and web fonts that swap in at a different size. Give every image a width and height, reserve space for embeds, and show banners as overlays rather than inserting them above content.

Does page speed affect Google rankings?

Yes, but modestly. Google says Core Web Vitals are used by its ranking systems as part of page experience, and that good page experience on its own does not make a page rank. Relevance and helpful content come first. In practice, speed matters most when competing pages are otherwise similar, and when a page is so slow that people give up before it loads.

The bigger effect is usually on visitors. Slow pages lose people before they see your offer, and that hurts enquiries and sales whatever your ranking. That is why it is worth fixing poor Core Web Vitals even if you are already on page one.

Google Search Console has a Core Web Vitals report that groups your URLs by status using the same CrUX field data. Use this checker to diagnose individual pages and Search Console to watch the whole site over time.

Limits of this checker and what the results mean

The checker uses the free Google PageSpeed Insights API, so it shares Google's daily quota. If the quota is used up, the tool says so and you can try again later. Results are cached for an hour, so testing the same URL twice in a row shows the same answer; that saves quota and avoids hammering your site.

Field data only exists for pages and sites with enough Chrome traffic. If a page does not have its own data, we show the whole-site (origin) figures instead and label them clearly. Brand-new or low-traffic sites may have no field data at all, in which case the lab data is your only guide.

Finally, the lab test only sees what loads without logging in or clicking. Pages behind a login, checkout steps and content that loads after scrolling are not measured. For those, test in Chrome DevTools on your own machine, or use real-user monitoring.

Examples you can copy

<img src="/images/hero-1200.webp" width="1200" height="630"
     fetchpriority="high" alt="Freshly baked sourdough loaves on a counter">

<img src="/images/team.webp" width="800" height="533" loading="lazy" alt="Our team outside the shop">

@font-face {
  font-family: "Brand Sans";
  src: url("/fonts/brand-sans.woff2") format("woff2");
  font-display: swap;
}

<script src="/js/reviews-widget.js" defer></script>

Common mistakes to avoid

Frequently asked questions