PageSpeed Insights: understand and improve your score
Page Speed & TTFB Test
Free, no sign-up. We only fetch the public URL you enter.
Short answer
PageSpeed Insights is Google’s free tool for measuring page speed. Enter a URL at pagespeed.web.dev and it shows two things: field data from real Chrome users (the Core Web Vitals LCP, INP and CLS over the last 28 days) and lab data from a Lighthouse test with a performance score from 0 to 100. Good values are LCP up to 2.5 s, INP up to 200 ms and CLS up to 0.1; a score of 90+ is “good”. Field data decides whether you pass Core Web Vitals; the lab score helps you find causes. The free test above is not PageSpeed Insights: it measures your server’s DNS, connection, TLS and time to first byte from Germany, the part of the load time that starts on your server.
- Field data: real users, Core Web Vitals, 28 days, 75th percentile.
- Lab data: Lighthouse score 0–100 with concrete improvement hints.
- Slow server response (TTFB) delays every other metric.
PageSpeed Insights is the first stop for anyone who wants to know how fast a website is in Google’s eyes. It is also one of the most misunderstood tools: two runs give different scores, the mobile score is much lower than desktop, and a page can fail Core Web Vitals with a score of 95 or pass them with a score of 60. This page explains what PageSpeed Insights measures, how the score is calculated, how to read lab and field data, which fixes help most, and how to measure the server part of your load time with the free test above.
What PageSpeed Insights is
PageSpeed Insights, often shortened to PSI, is a free web tool from Google at pagespeed.web.dev. It analyses a single URL on mobile and desktop and reports how fast the page loads, how quickly it reacts to input and how stable its layout is. It combines two data sources: the Chrome User Experience Report (CrUX) with measurements from real Chrome users, and a Lighthouse test that loads the page in a controlled environment.
Developers also use the PageSpeed Insights API to run tests automatically, and the same Lighthouse engine is built into Chrome DevTools, so you can run lab tests locally as well.
Field data vs. lab data
The upper part of the report, “Discover what your real users are experiencing”, shows field data from CrUX. It is based on visits by real Chrome users over the last 28 days and reports the 75th percentile, meaning three out of four visits were at least this fast. If your page has too little traffic, PSI shows data for the whole origin or nothing at all.
The lower part, “Diagnose performance issues”, shows lab data from a single Lighthouse run. Mobile tests simulate a mid-range phone on a slow 4G connection, which is why mobile scores are usually much lower than desktop scores. Lab data is reproducible and explains causes; field data reflects reality and is what Google uses for the page experience signal.
The Core Web Vitals
Largest Contentful Paint (LCP) measures when the largest visible element, often a hero image or headline, has rendered. Interaction to Next Paint (INP) measures how quickly the page responds visually to clicks, taps and key presses, across the whole visit; it replaced First Input Delay in 2024. Cumulative Layout Shift (CLS) measures how much content jumps around while loading.
PSI also shows First Contentful Paint and Time to First Byte in the field data. They are not Core Web Vitals, but they help with diagnosis: a slow TTFB makes a good LCP almost impossible.
How the performance score works
The score from 0 to 100 is calculated from five lab metrics: Total Blocking Time, Largest Contentful Paint, Cumulative Layout Shift, First Contentful Paint and Speed Index. Each metric is converted to a score based on real-world distributions and then weighted. 90 to 100 is good, 50 to 89 needs improvement, below 50 is poor.
The score varies between runs because network conditions, server response times and third-party scripts vary. Differences of a few points are normal. Run the test several times and compare medians, and do not chase 100: a fast page with a score of 85 is better than a slow one that games the test.
Reading the opportunities and diagnostics
Below the metrics, PSI lists opportunities and diagnostics: render-blocking resources, unused JavaScript and CSS, images that are too large or in old formats, missing caching headers, long main-thread tasks, too many DOM elements, layout shifts caused by images without dimensions or late-loading fonts. Each entry shows estimated savings and the affected files.
Work through them by impact, not by count. The largest gains usually come from a few items: the LCP image, heavy JavaScript, third-party tags and the server response time.
The most effective fixes
On CMS sites, a good caching plugin, image optimisation and a critical look at plugins and tracking scripts often solve most problems.
- Speed up the server response: caching, faster hosting, fewer database queries, a CDN
- Optimise the LCP element: correct size, modern format (WebP/AVIF), preload, no lazy loading above the fold
- Reduce JavaScript: remove unused scripts, defer non-critical code, limit third-party tags
- Prevent layout shifts: width and height on images and embeds, reserved space for ads and banners
- Load fonts efficiently: self-host, preload, use font-display
- Improve INP: break up long tasks, reduce work in event handlers
Why server response time matters
Everything a browser does starts after the server has sent the first byte of HTML. If time to first byte is 1.5 seconds, the page cannot reach a good LCP on a slow connection, no matter how optimised the images are. Slow server responses come from uncached dynamic pages, slow database queries, overloaded shared hosting, distant servers or external API calls during rendering.
The free test above measures exactly this part: DNS lookup, TCP connect, TLS handshake, time to first byte and total time for the HTML, from a server in Germany, without rendering. Use it to check whether the server is the bottleneck before you optimise the front end, and repeat it after changes to hosting or caching.
Mobile vs. desktop results
Mobile results are stricter because the lab test throttles CPU and network to simulate a typical phone. Field data on mobile also comes from real phones on real networks. Since Google indexes mobile-first, focus on mobile. If desktop is fast and mobile slow, look at JavaScript execution and image sizes, which hit phones hardest.
PageSpeed Insights and SEO
Core Web Vitals are part of Google’s page experience signals. They are a ranking factor, but a modest one: relevant, helpful content ranks above fast but weak content. Speed matters more directly for users: faster pages have lower bounce rates and higher conversion rates. Treat PSI as a tool for better user experience, with SEO as a side effect.
DNS lookup 18 ms TCP connect 24 ms TLS handshake 46 ms Time to first byte 612 ms Total (HTML) 688 ms · 84 KB
Alternatives and complements
Lighthouse in Chrome DevTools runs the same lab test locally. WebPageTest offers detailed waterfalls, many locations and real devices. GTmetrix and Pingdom Tools present load times and waterfalls in an accessible way. Search Console’s Core Web Vitals report groups field data for many URLs. Real user monitoring tools collect Core Web Vitals from all visitors, not just Chrome users.
Monitoring speed over time
A single PSI test shows one moment. Speed problems often appear after plugin updates, new tracking tags or traffic growth. Run lab tests after each release, watch the Core Web Vitals report in Search Console monthly, and monitor server response time continuously. monitordefend measures each website’s response time every five minutes and emails you when it exceeds your threshold; it does not calculate Lighthouse scores or Core Web Vitals.
Frequently asked questions
What is a good PageSpeed Insights score?
90 to 100 is good, 50 to 89 needs improvement and below 50 is poor. More important than the score is passing Core Web Vitals in the field data.
Why does my PageSpeed score change every time?
Lab tests depend on server response, network conditions and third-party scripts, which vary between runs. Compare several runs.
Why is my mobile score so much lower than desktop?
The mobile test simulates a mid-range phone with a slow connection and throttled CPU, so heavy JavaScript and large images hurt much more.
What does “no field data” mean?
The page or site does not have enough Chrome visits in the last 28 days for CrUX data. Only lab data is shown.
Is the test on this page the same as PageSpeed Insights?
No. It measures DNS, connection, TLS, time to first byte and HTML download time from a server in Germany. It does not render the page or calculate Core Web Vitals.
Do Core Web Vitals affect rankings?
Yes, as part of page experience, but relevance and content quality matter much more.
How can I improve LCP quickly?
Speed up the server response, serve the LCP image in the right size and a modern format, preload it and avoid lazy loading it.
Related pages
Monitor your server response time continuously
Start for free and set up your first check in minutes.
Start for free