Page Speed Checker
Enter a URL
About Page Speed Checker
Every second your page takes to load is costing you visitors, conversions, and rankings. That is not a metaphor — it is documented, quantified, and replicated across decades of web performance research. Amazon found that 100 milliseconds of additional latency reduced their sales by 1%. Deloitte's study across 37 major retail sites confirmed that a 1-second delay drops conversion rates by 7%. Google's own mobile performance research shows that when page load time increases from 1 second to 3 seconds, the probability of a visitor bouncing increases by 32%. And with Google's mobile-first indexing and Core Web Vitals now confirmed ranking factors, a slow page is not just losing visitors — it is losing the rankings that bring visitors in the first place.
The DigitalSub Pro Page Speed Checker analyses any URL and returns your page's key performance metrics — load time, Time to First Byte (TTFB), First Contentful Paint (FCP), and the three Google Core Web Vitals (LCP, INP, and CLS) that directly influence your search rankings. This page explains exactly what each metric measures, what the good and poor thresholds are, why they matter for both SEO and revenue, and what to do when your scores are not where they should be.
- What the Tool Shows
- What Page Speed Actually Measures
- Core Web Vitals — Every Metric Explained with Thresholds
- Diagnostic Metrics — TTFB and FCP
- Lab Data vs Field Data — Why Your Score Looks Different Everywhere
- How Page Speed Affects Your Google Rankings
- Page Speed and Revenue — The Business Case in Numbers
- 8 Most Common Causes of a Slow Page
- How to Improve Each Core Web Vital — Specific Fixes
- How to Use the Page Speed Checker
- Who Uses This Tool
- Pro Tips for Page Speed Optimisation
- Related Tools
- Frequently Asked Questions
What the Tool Shows
Enter any URL and the tool returns your page's performance metrics — including all three Core Web Vitals that Google uses in its ranking signals, alongside TTFB and overall load time. Here is a sample result showing a page that passes all three Core Web Vitals assessments.
To pass the Core Web Vitals assessment, all three metrics (LCP, INP, CLS) must be in the "Good" range at the 75th percentile — meaning 75% of real users must experience Good scores, not just your best-case test result.
What Page Speed Actually Measures
"Page speed" is not a single number — it is a collection of metrics that each capture a different aspect of how a page performs for real users. This is why Google moved away from a single speed score toward Core Web Vitals: different dimensions of performance affect user experience in different ways, and a page can be fast in one dimension while being poor in another.
A page might display the first text almost immediately (good FCP) but have a large image that takes 4 seconds to fully load (poor LCP). A page might load all content quickly but shift its layout while loading, causing users to accidentally click the wrong element (poor CLS). A page might render fast but lag badly when a user tries to interact with it (poor INP). These problems are invisible when you only measure total load time — which is why Google's three Core Web Vitals each target a distinct dimension of the user experience.
Core Web Vitals — Every Metric Explained with Thresholds
Core Web Vitals is a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page, according to Google's own documentation. They are the gold standard that Google uses to judge how well your website performs. Passing all three is a confirmed Google ranking signal — failing any one of them means your page does not benefit from this signal, regardless of how it performs on the others.
LCP — Largest Contentful Paint
Measures loading performance — how quickly the largest visible content element appears
LCP measures how long it takes for the largest piece of content visible in the viewport — typically a hero image, a large heading, a video thumbnail, or a large text block — to fully render after a user navigates to your URL. It is the most direct measure of perceived loading speed: users judge "did the page load?" based on when the main content appears, not when every resource has finished downloading.
To provide a good user experience, strive to have LCP occur within the first 2.5 seconds of the page starting to load. Pages between 2.5 and 4 seconds need improvement. Pages above 4 seconds receive a "Poor" rating — the worst tier for this ranking signal.
LCP is weighted most heavily in Google's page experience assessment and is the Core Web Vital most directly correlated with organic traffic. A case study by Web.dev found that a 40% improvement in LCP correlated with 28% more organic traffic. Vodafone achieved a 31% LCP improvement that led to 15% better lead-to-visit rates and 8% sales growth.
- Slow server response time (high TTFB delays everything downstream)
- Unoptimised hero images — large file sizes, no WebP/AVIF format, no compression
- Render-blocking JavaScript and CSS preventing the page from displaying content
- No CDN — serving assets from a geographically distant server
- LCP image not preloaded — browser discovers it late in the waterfall
INP — Interaction to Next Paint
Measures interactivity — how quickly the page visually responds to any user action
INP replaced the previous First Input Delay (FID) metric in March 2024. While FID only measured the delay before the browser could process the first user interaction, INP measures how quickly a page responds to any interaction — tapping a button, selecting a product variant, clicking add-to-cart. This makes it a far more comprehensive measure of interactivity across a user's entire session, not just their first click.
An INP under 200 milliseconds feels instantaneous to users. Between 200 and 500 milliseconds, interactions feel sluggish. Above 500 milliseconds, users typically believe the page has not registered their action and either wait anxiously or click again — causing duplicate form submissions, multiple cart additions, or frustrated abandonment. In checkout flows, this often causes users to click multiple times or abandon the process altogether because they are unsure whether their input was registered.
- Heavy JavaScript execution blocking the main thread during interactions
- Large, unoptimised JavaScript bundles loading synchronously
- Third-party scripts (ads, analytics, chat widgets) competing for the main thread
- Complex DOM manipulation triggered by user interactions
- Inefficient event handlers executing too much work per click
CLS — Cumulative Layout Shift
Measures visual stability — whether content unexpectedly moves while the page loads
CLS measures the total amount of unexpected layout shifts that occur during a page's loading lifecycle. A layout shift happens when visible elements move from one position to another without user interaction — for example, when an image loads and pushes text down, when a cookie banner appears and shifts the page, or when a web font loads and changes the size of text already on screen. CLS is scored as a decimal representing the cumulative impact of these shifts — lower is better, and zero means no unexpected shifts at all.
CLS causes what users experience as the frustrating "I was about to click that button and it moved" phenomenon. It is one of the most user-visible performance problems precisely because it causes real-world interaction errors: users click advertisements instead of content, submit wrong form answers, or navigate to unintended pages — all because the layout shifted at the wrong moment.
- Images without explicit width and height attributes — browser doesn't reserve space
- Ads, embeds, or iframes without reserved dimensions causing late layout shifts
- Web fonts causing text to reflow when they replace fallback fonts (FOIT/FOUT)
- Cookie consent banners, notification bars, or pop-ins inserted above existing content
- Dynamic content injected above the fold after initial render
Diagnostic Metrics — TTFB and FCP
Beyond the three Core Web Vitals, two additional metrics appear in your speed report and serve as diagnostic tools for understanding why your Core Web Vitals scores are what they are. These are not themselves ranking signals but they are leading indicators — a problem with TTFB or FCP almost always explains a problem with LCP.
The time from when a user requests your URL to when the first byte of the server's response arrives in the browser. TTFB is purely a server-side metric — it measures how long your server takes to process the request and begin sending a response. A poor TTFB delays everything: the browser cannot begin parsing HTML, downloading CSS, or discovering other resources until the first byte arrives. If your LCP is high, check TTFB first — slow server response time is the foundation of most page speed problems and no amount of front-end optimisation can compensate for a slow origin server.
The time from navigation start to when the browser renders the first piece of DOM content — any text, image, SVG, or canvas element. FCP is earlier than LCP: it measures when something first appears, while LCP measures when the most important thing appears. FCP is a useful signal for perceived performance — users need to see something quickly to believe the page is responding. A long gap between FCP and LCP suggests that while the page starts rendering, the main content is delayed — often caused by a large hero image taking time to download and display after initial HTML parsing.
Lab Data vs Field Data — Why Your Score Looks Different Everywhere
One of the most common sources of confusion in page speed analysis: you run the same URL through three different tools and get three different scores. This is expected — and it is not a bug. The difference comes down to whether the tool uses lab data or field data, and these measure fundamentally different things.
A controlled test run on a single machine under fixed conditions — typically a mid-range mobile device on a simulated 4G connection. Fast, repeatable, and consistent.
- Same result every time (no variability)
- Shows what your site could score in ideal conditions
- Useful for debugging and tracking improvements
- Does not reflect real-world network variance, device variety, or geographic spread
- Used by Lighthouse, WebPageTest, many speed checkers
Aggregated from Chrome users who have opted to share usage data, reflecting your actual visitors on their actual devices, networks, and locations.
- Reflects the 75th percentile — 75% of real visits must be "Good"
- Varies based on your actual user base (device types, connection speeds, geography)
- What Google uses for the Core Web Vitals ranking signal
- May not exist for low-traffic pages (insufficient data)
- Accessed via PageSpeed Insights, Google Search Console, CrUX dataset
The critical implication: for aggregations with sufficient data in all three metrics, the aggregation passes the Core Web Vitals assessment if the 75th percentiles of all three metrics are Good. This means 75% of your real users must experience Good scores — not just your average or best-case test. A page with a good lab score but a poor field score means your real users are experiencing slower performance than your controlled test suggests — often because they are on slower devices, older browsers, or slower network connections than the lab simulation.
How Page Speed Affects Your Google Rankings
Page speed has been a Google ranking factor for desktop since 2010 and for mobile since 2018. The Page Experience update rolled out from 2021 to 2022 made Core Web Vitals specifically a ranking signal. Core Web Vitals are a confirmed Google ranking factor — but understanding how they function within Google's broader ranking system is important for setting the right expectations.
Core Web Vitals are one of over 200 signals in Google's ranking algorithm. A page with excellent Core Web Vitals does not automatically rank number one — topical relevance, content quality, backlinks, and E-E-A-T remain more dominant signals. The practical impact of Core Web Vitals is most significant at the margins: when two pages are closely matched on content quality and authority, the faster page has an advantage. As competition for ranking positions grows and more sites improve their performance, this tiebreaker becomes increasingly meaningful.
The more direct speed-to-ranking relationship comes through user engagement signals. Google uses real-world behavioural data — click-through rates, dwell time, bounce rate patterns — as relevance signals. A slow page that users immediately abandon sends negative engagement signals that compound over time, dragging down rankings independently of any direct speed signal. This is why a slow site faces a double penalty: fewer visitors convert into customers (the direct speed-to-conversion impact), and fewer people find the site in the first place because it ranks lower in search results.
The 75th Percentile Rule — What Google Actually Measures
Google does not use your average page speed or your best-case test result for the Core Web Vitals ranking signal. It uses the 75th percentile of field data from real Chrome users. This means that even if most of your visitors experience fast load times, if 25% are experiencing poor performance (perhaps due to slow mobile networks or older devices), those users are dragging your 75th percentile score into the "Needs Improvement" or "Poor" range — and that is the score Google uses to evaluate your page experience signal.
Page Speed and Revenue — The Business Case in Numbers
The financial argument for page speed optimisation is one of the most well-documented in all of digital marketing. These are not estimates or projections — they are measured outcomes from controlled experiments and retrospective analyses at scale.
The critical insight: the curve is steepest between 1 and 3 seconds. Going from a 1-second load to a 3-second load loses nearly a third of your visitors. The practical implication for any business: improving a 4-second page to 2 seconds does not merely feel better — it measurably increases the number of people who see your products, read your content, and complete your desired actions. For a site making £5,000 per day, even a conservative 5% conversion improvement from speed optimisation represents £91,000 in additional annual revenue.
8 Most Common Causes of a Slow Page
Most page speed problems come from a consistent set of root causes. Understanding which cause is responsible for your poor scores tells you exactly what to fix — and prevents wasting time on optimisations that will not move your Core Web Vitals scores.
How to Improve Each Core Web Vital — Specific Fixes
Each Core Web Vital has its own set of targeted improvements. Here are the highest-impact fixes for each metric, organised so you can prioritise based on which score needs the most attention.
Preload the LCP Image
Add <link rel="preload" as="image" href="hero.webp"> in your <head>. This tells the browser to start downloading the LCP image immediately — before it discovers it through normal HTML parsing. One of the highest-impact single-line LCP improvements available.
Upgrade Hosting / Reduce TTFB
If TTFB is above 600ms, your LCP will struggle regardless of other optimisations. Switch to a faster host, enable server-level page caching (Redis, Nginx FastCGI), or move to a managed WordPress host with built-in caching. No front-end fix can compensate for a slow server.
Convert Hero Images to WebP/AVIF
WebP reduces image size by 25–34% over JPEG with equivalent quality. AVIF reduces by 50%+. For a 300KB hero image, switching to AVIF saves 150KB+ — a direct, proportional LCP improvement. Use <picture> element with AVIF and WebP sources for automatic browser-appropriate format selection.
Break Up Long JavaScript Tasks
Any JavaScript task running for more than 50ms on the main thread blocks the browser from responding to user interactions. Use setTimeout to yield between tasks, or the modern scheduler.yield() API. This breaks monopoly of the main thread and allows interaction handling between task chunks.
Defer Non-Critical Third-Party Scripts
Third-party scripts (analytics, chat, ads) compete with your own JavaScript for main thread time. Load them with defer, or inject them after a user interaction using a facade pattern. This reduces main thread contention during the initial page load when INP sensitivity is highest.
Add Width and Height to All Images
The single most impactful CLS fix for image-heavy pages. Add explicit width and height attributes to every content image. The browser uses these to calculate and reserve the exact space the image will occupy before it loads — eliminating the layout shift when the image arrives.
Reserve Space for Ads and Embeds
Ads, iframes, and embedded widgets that load after initial render cause large layout shifts. Set explicit min-height on ad containers so space is reserved before the ad loads. For iframes, use the aspect-ratio CSS property or explicit dimensions that match the expected embedded content size.
Use font-display: swap or optional
Web fonts that cause text to reflow when they replace fallback fonts contribute to CLS. Using font-display: swap shows fallback text immediately while the web font loads, then swaps — better than invisible text but still a small shift. font-display: optional skips the swap if the font is not cached, avoiding the shift entirely for repeat visitors.
Enable a CDN
A CDN reduces geographic latency for all assets, improving TTFB, FCP, and LCP simultaneously. It also reduces origin server load, which improves server response consistency — reducing the variance that pushes 75th percentile scores into "Needs Improvement" even when median scores are good.
How to Use the Page Speed Checker
Enter Your URL
Paste any publicly accessible URL — a homepage, landing page, product page, or blog post. Test your most important pages first — those that drive the most traffic and conversions.
Run the Test
Click Check. The tool runs a performance analysis against the URL and returns all six key metrics — LCP, INP, CLS, TTFB, FCP, and total load time — within seconds.
Read the Scores
Green = Good. Yellow = Needs Improvement. Red = Poor. Check which Core Web Vitals fail their thresholds — each one points to a specific category of performance problem.
Fix and Retest
Use the failing metric scores to guide your optimisation priorities. After implementing fixes, retest to confirm improvements. Aim for all three Core Web Vitals in the "Good" range to pass Google's assessment.
Who Uses the Page Speed Checker
SEO Professionals — Technical Audits
Core Web Vitals are a required component of any technical SEO audit in 2025. Testing key pages for failing metrics, identifying the metric responsible, and prescribing targeted fixes is a standard deliverable. The page speed checker provides a quick, shareable assessment without requiring a full Google Search Console account.
eCommerce Owners — Conversion Optimisation
For online stores, every second of load time is quantifiably costing revenue. Testing product pages and checkout flows with the speed checker identifies which pages are underperforming and giving competitors a speed advantage. The combination of speed improvement and conversion rate improvement is one of the highest-ROI technical investments available.
Web Developers — Pre-Launch Validation
Before launching a new site, redesign, or significant code change, running the speed checker confirms that performance metrics meet acceptable thresholds. Catching a poor LCP or high CLS before launch is far less costly than fixing it after a ranking drop has accumulated from real-user field data.
Bloggers and Content Creators
For publishers who depend on organic search traffic, Core Web Vitals are the technical SEO foundation. A blog with excellent content but poor page speed is competing at a disadvantage against similarly good content on a faster site. Regular speed checks catch performance regressions from new plugins, theme updates, or ad network additions before they affect rankings.
Pro Tips for Page Speed Optimisation
6 Speed Optimisation Habits That Make the Most Difference
- Test on mobile first — not just desktop. Only 48% of mobile pages and 56% of desktop pages pass all three Core Web Vitals. Mobile performance is consistently worse than desktop, and Google's mobile-first indexing means your mobile Core Web Vitals score is what Google uses for your ranking signal. A site that performs well on desktop but poorly on mobile is, from Google's perspective, a slow site.
- Fix TTFB before anything else. If your Time to First Byte is above 800ms, no amount of image optimisation or JavaScript reduction will bring LCP into the Good range. TTFB is the foundation — everything else depends on it. Confirm TTFB first, fix it if needed, then optimise front-end metrics. This is the correct diagnostic order that most speed optimisation guides get wrong.
- Test multiple pages — not just your homepage. Your homepage may be heavily cached and optimised while product pages, blog posts, or category pages are significantly slower. Google measures Core Web Vitals at the page level — a slow product page is a speed problem even if your homepage is fast. Test your highest-traffic pages and your most conversion-important pages, not just the front page.
- Treat the 75th percentile, not the median. Even if most of your visitors experience fast load times, a quarter of your users experiencing poor performance is enough to push your 75th percentile field data into the "Needs Improvement" category — and that is the number Google uses. Optimise for your slowest visitors (older devices, slower connections) as much as your average visitor.
- Pair CLS investigation with the Screen Resolution Simulator. Layout shifts are often device-specific — a shift that only occurs on mobile viewports or specific screen widths may not appear on your desktop test. Use the resolution simulator at 375×667 (iPhone) and 768×1024 (tablet) while speed testing to identify CLS issues that are viewport-dependent.
- Track Core Web Vitals over time in Google Search Console, not just point-in-time. The Page Indexing and Core Web Vitals reports in Search Console show trends over time — you can see whether new code deployments, plugin updates, or content changes have degraded performance before the field data fully catches up to a ranking signal. Use the speed checker for spot checks and Search Console for longitudinal trend tracking.
Frequently Asked Questions
What is a good page speed score in 2025?
Rather than a single "score," focus on passing all three Core Web Vitals thresholds:
- LCP under 2.5 seconds — how quickly the main content appears
- INP under 200 milliseconds — how quickly the page responds to interactions
- CLS under 0.1 — no significant unexpected layout shifts
For supporting diagnostic metrics: TTFB should be under 800ms and FCP under 1.8 seconds. For total load time, Google's practical recommendation is under 3 seconds on mobile. The average page load time for a typical website is 1.8 seconds for mobile pages and 1.6 seconds for desktop sites — and sites that load faster than these averages are at a competitive advantage.
Why is my Google PageSpeed Insights score different from what this tool shows?
Different tools use different testing methodologies and data sources. Google PageSpeed Insights shows both lab data (from a simulated Lighthouse test) and field data (from real Chrome users via the CrUX dataset). The lab score (the 0–100 number) is a synthetic test result — useful for tracking improvements but not directly comparable to real-world user experience.
This tool's results and PageSpeed Insights may differ because: testing conditions vary (network speed, device emulation, server cache state at time of test), different tools weight metrics differently in composite scores, and point-in-time tests can vary based on server load at the moment of testing. For the most authoritative data about your ranking impact, Google Search Console's Core Web Vitals report — based on real user field data — is the definitive source.
What is INP and how is it different from FID?
INP replaced First Input Delay (FID) as the official responsiveness metric in March 2024. The key differences:
- FID only measured the delay before the browser could process the user's very first interaction on a page — it ignored all subsequent interactions entirely
- INP measures the response delay for every interaction throughout the entire page session — clicks, taps, key presses — and reports the worst interaction (with some outlier tolerance)
This makes INP a much more comprehensive measure of how responsive a page feels in practice. A page with fast FID but slow responses to all subsequent clicks would score well on FID but poorly on INP. For most sites, improving INP requires reducing main thread blocking by JavaScript — heavy scripts, large bundles, and third-party tools are the primary culprits.
How long does it take for Core Web Vitals improvements to affect Google rankings?
Google's Core Web Vitals field data — which is what affects rankings — comes from the Chrome User Experience Report (CrUX), which updates daily but aggregates data over a 28-day rolling window. This means:
- Improvements you make today will gradually influence the field data over the following 28 days
- The full ranking benefit of a Core Web Vitals improvement may take 4–6 weeks to fully reflect in Google's assessment
- You can see the trend changing in Google Search Console's Core Web Vitals report before the full effect appears in rankings
This also means that improvements to lab scores (like Google PageSpeed Insights' 0–100 score) do not immediately translate to ranking changes — the field data, reflecting real user experiences over the past 28 days, is what actually matters for the ranking signal.
My Core Web Vitals pass in testing but fail in Search Console. Why?
Lab tests (like this tool and PageSpeed Insights' Lighthouse test) simulate a controlled user on a specific device and connection. Google Search Console's Core Web Vitals report uses field data — real experiences from actual Chrome users visiting your site. These populations are different:
- Real users have a wide variety of devices — many older and slower than the lab simulation
- Real users are on various network connections — many slower than the simulated 4G
- Real users may trigger different code paths (logged-in states, A/B test variants, personalised content)
- The 75th percentile requirement means 25% of your slowest experiences pull the score down
The solution: prioritise field data over lab data when diagnosing ranking signals. Good lab scores are a helpful indicator that you are on the right track, but Google's ranking signal comes from your CrUX field data — make sure that is in the Good range at the 75th percentile.
Is the Page Speed Checker completely free?
Yes — completely free, no account, no sign-up, and no usage limits. Test as many URLs as you need. This applies to all 47+ tools on DigitalSub Pro.