Page Speed Checker — Free, Instant, No Signup

Test any URL for Core Web Vitals, LCP, INP, CLS, TTFB, and FCP in seconds. No account. No install. Results explained in plain English so you know exactly what to fix.

How to Use the Page Speed Checker

Step 1 — Enter Any URL Paste the full URL of any webpage into the input field above — your homepage, a product page, a blog post, or a competitor's URL. Any publicly accessible page works.

Step 2 — Run the Test Click Check Speed. Prafero fetches the page in real time and runs the analysis instantly. No queue. No waiting room. Results appear in seconds.

Step 3 — Read Your Results and Fix What's Slow Your results show a performance score alongside individual metrics — LCP, INP, CLS, FCP, and TTFB — each with a clear Good / Needs Improvement / Poor rating. Every result includes a plain-English explanation so you know not just the score, but what it means and what to do about it.

What Is Page Speed?

Page speed is how fast the content of a specific URL loads and becomes usable for a visitor. It is not a single number — it is a collection of metrics that each measure a different part of the loading experience: how quickly the first content appears, when the largest element finishes rendering, how stable the layout stays during load, and how fast the page responds to a tap or click.

Google has been using page speed as a ranking factor since 2010 for desktop and since 2018 for mobile. In 2021 it formalised this with the Page Experience update, which introduced Core Web Vitals — three specific metrics that now form part of Google's ranking algorithm. The March 2026 core update further tightened these signals, elevating Interaction to Next Paint (INP) alongside LCP as a primary ranking metric.

Speed also has a direct business impact that has nothing to do with rankings. According to Google's own research, 53% of mobile users abandon a page that takes longer than three seconds to load. A one-second delay in load time reduces conversions by approximately 7%. Every second you shave off your load time is revenue you recover.

Core Web Vitals Explained: LCP, INP, and CLS

Core Web Vitals are the three metrics Google uses to measure real-world page experience. They are measured from actual Chrome user data via the Chrome User Experience Report (CrUX), collected at the 75th percentile — meaning 75% of real visitors to your page must have a good experience for your page to pass.

LCP — Largest Contentful Paint (Loading) LCP measures how long it takes for the largest visible element on the page — usually a hero image or a main heading — to fully render. It answers the user's first question: is this page actually loading?

• Good: ≤ 2.5 seconds

• Needs Improvement: 2.5s – 4.0s

• Poor: > 4.0 seconds

The most common LCP killers are unoptimised hero images, slow server response (high TTFB), render-blocking JavaScript, and client-side rendering that delays everything. Use Prafero's image optimization checker to identify oversized or uncompressed images that are dragging your LCP score down.

INP — Interaction to Next Paint (Responsiveness) INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Where FID only measured the very first interaction, INP measures the responsiveness of every click, tap, and keypress throughout the entire page visit — making it far harder to game and far more representative of real user experience. According to Chrome UX Report data from early 2026, 43% of websites still fail the INP threshold, making it the most commonly failed Core Web Vital.

• Good: ≤ 200 milliseconds

• Needs Improvement: 200ms – 500ms

• Poor: > 500ms

INP failures are almost always caused by heavy JavaScript — long tasks blocking the main thread, third-party scripts (chat widgets, tag managers, tracking pixels) competing for CPU time, or bloated frameworks running unnecessary code on every interaction.

CLS — Cumulative Layout Shift (Visual Stability) CLS measures how much visible content moves unexpectedly during the page load. If a button jumps just as a user reaches for it, or a block of text shifts when an ad loads in above it, that is CLS in action. It is deeply frustrating and Google penalises it directly.

• Good: ≤ 0.1

• Needs Improvement: 0.1 – 0.25

• Poor: > 0.25

The most common CLS causes are images without explicit width and height attributes, ads and embeds injected without reserved space, and web fonts that swap late and push content around.

Supporting Metrics: FCP and TTFB Beyond the three Core Web Vitals, your results also show First Contentful Paint (FCP) and Time to First Byte (TTFB).

FCP (good: ≤ 1.8s) measures when the first text or image appears on screen — the first signal to the user that something is happening. TTFB (good: ≤ 800ms) measures how long the server takes to respond to the initial request. TTFB is the performance ceiling: no amount of front-end optimisation compensates for a server that takes two seconds to respond before a single byte of content is delivered. If your TTFB is high, the fastest CDN fix is enabling gzip or Brotli compression and ensuring your server is responding efficiently.

Does Page Speed Affect SEO Rankings in 2026?

Yes — and in 2026, more than ever. Page speed is a confirmed Google ranking factor, and the March 2026 core update strengthened that signal by tightening Core Web Vitals thresholds and elevating INP as a primary ranking metric alongside LCP.

The nuance worth understanding is that speed functions as a tiebreaker and a multiplier, not a trump card. Strong content with quality backlinks still outranks technically perfect pages with nothing to say. But in competitive niches — where multiple pages match the search intent with similar content quality — Core Web Vitals consistently determine which page wins. And given that generative AI has made it far easier to produce decent content at scale, the technical gap between competitors is now often the deciding factor.

Speed also drives rankings indirectly through behaviour signals. A visitor landing on a slow page who clicks back to the search results immediately sends Google a clear signal that the page did not satisfy their intent. That pogo-stick pattern compounds across thousands of sessions and damages rankings even when the underlying content is strong.

Check your overall SEO health alongside your speed score using Prafero's seo score checker — because fast pages that fail on meta tags, headings, or structured data are leaving ranking positions on the table.

How to Improve Page Speed: Fixes for WordPress, Shopify, and Cloudflare

Highest-Impact Fixes for Any Site

The fastest wins, ranked by impact:

1. Optimise your hero image. The LCP element is almost always an image. Convert it to WebP or AVIF (25–35% smaller than JPEG with no visible quality loss), compress it, and add fetchpriority="high" to the <img> tag. Do not use loading="lazy" on the LCP image — this delays it deliberately and tanks your LCP score. Use Prafero's image optimization checker to find every uncompressed or oversized image on the page.

2. Enable compression. Gzip and Brotli reduce the size of HTML, CSS, and JavaScript files transferred between server and browser by 60–80%. Brotli offers 15–30% better compression than Gzip for text assets. Run Prafero's gzip checker to verify whether your server is compressing responses correctly.

3. Configure browser caching. Returning visitors should not have to re-download static assets on every visit. Proper Cache-Control headers tell browsers how long to store files locally, dramatically reducing load time for repeat visitors. Inspect your caching headers with Prafero's browser cache checker.

4. Upgrade to HTTP/2 or HTTP/3. HTTP/2 allows multiple requests to be sent over a single connection simultaneously (multiplexing), eliminating the request queue that slows HTTP/1.1 sites. HTTP/3 adds QUIC protocol for even faster connection setup. Check your protocol support with Prafero's http2 checker.

5. Minify CSS and JavaScript. Removing whitespace, comments, and redundant characters from your CSS and JS files reduces their size and decreases the Total Blocking Time (TBT) that accounts for 30% of the Lighthouse performance score. Audit your minification with Prafero's minification checker.

6. Reduce HTTP requests. Every JS file, CSS file, image, and font on your page is a separate HTTP request. Pages with excessive requests take longer to load, even when individual files are small. Count your page's requests with Prafero's resource checker to identify bloat.

WordPress

• Plugin audit: Every active plugin can add JavaScript and CSS to every page. Use Query Monitor to profile which plugins are slowest. Remove anything unused.
  

• Caching plugin: Install WP Rocket or LiteSpeed Cache for page caching, browser caching, and object caching in one place.
  

• Image compression: Use ShortPixel to bulk-convert images to WebP and compress them without quality loss.
  

• Managed hosting: If your TTFB is consistently above 800ms, shared hosting is your ceiling. Kinsta or WP Engine reduce TTFB by 60–80% via server-level caching and CDN.
  

• Conditional asset loading: Use Perfmatters Script Manager to load plugin CSS/JS only on the specific pages where those plugins are active.

Shopify

• App audit first. Each installed Shopify app can inject its own JavaScript and CSS into every storefront page — even pages where the app is not active — adding 200–500ms per app. Removing unused apps is typically the single fastest speed win on any Shopify store.
  

• LCP image: Do not lazy-load your hero or product image. Add fetchpriority="high" to ensure the browser downloads it immediately.
  

• Defer non-critical JS: Tracking pixels, chat widgets, and review carousels that are not needed for the first paint should be deferred until after the main content loads.
  

• Use Dawn or a performance-optimised theme. Heavy third-party themes are a common source of render-blocking code.
  

• Shopify's Cloudflare CDN is enabled by default — ensure all assets are served through it rather than from third-party hosting.

Cloudflare

• Auto Minification: Speed › Optimization → enable for HTML, CSS, and JS.
  

• Brotli compression: Speed › Optimization → enable Brotli (Cloudflare applies it automatically without touching your origin server).
  

• HTTP/2 and HTTP/3: Enabled by default on all Cloudflare plans — verify it is active with the http2 checker.
  

• Browser Cache TTL: Caching › Configuration → set a minimum cache TTL of 1 month for static assets.
  

• Rocket Loader: Speed › Optimization → Rocket Loader defers JavaScript loading to prevent render-blocking. Test on staging first — it can affect some scripts.
  

Also check your site is fully mobile-ready alongside speed — use Prafero's mobile-friendly test since Google's mobile-first indexing means your mobile score is the one that determines rankings.

How to Read Your Page Speed Results

Performance Score (0–100) This is the Lighthouse composite score, a weighted average of FCP (10%), Speed Index (10%), LCP (25%), TBT (30%), and CLS (25%). Score 90–100 is Good (green). Score 50–89 Needs Improvement (orange). Score 0–49 is Poor (red). A high score is a useful health indicator, but the individual Core Web Vitals — which use real user field data — are what Google actually ranks on.

Good / Needs Improvement / Poor Labels. Each Core Web Vital is rated against Google's official thresholds. Good means the metric is passing. Needs Improvement means you are below the threshold but not critically failing — a focused fix will move you to green. Poor means the metric is actively damaging your rankings and user experience and needs immediate attention.

Lab Data vs. Field Data Lab data (Lighthouse) is a single simulated test run from one device under controlled conditions. Field data (CrUX) is aggregated from real Chrome users visiting your page over the past 28 days. Google uses field data for its ranking signals. If your lab score looks good but your CrUX data shows Poor for LCP, real users are having a worse experience than the simulation suggests — usually because of third-party scripts that behave differently in real conditions.

Common Page Speed Issues and How to Fix Them

1. LCP above 4 seconds. The most common cause is an unoptimised hero image being loaded without priority. Fix: convert to WebP, compress below 100KB where possible, add fetchpriority="high", remove loading="lazy" from the LCP element, and preload it with <link rel="preload">.

2. INP failing at 200ms+ Heavy JavaScript is blocking the main thread. Fix: audit third-party scripts (remove what you don't need, defer the rest), break up long tasks over 50ms using setTimeout or the Scheduler API, and reduce your JavaScript bundle size. On WordPress, this is usually a plugin; on Shopify, it is usually an app.

3. High CLS from shifting layout Images or embeds loading without reserved dimensions. Fix: add explicit width and height attributes to every image and iframe. Reserve space for ads, cookie banners, and dynamic content before they load. Use font-display: swap for web fonts and pre-load critical fonts.

4. TTFB above 800ms. Your server is slow to respond. Fix: enable server-side caching, use a CDN to serve from edge nodes closer to your users, upgrade hosting from shared to managed, and enable Gzip/Brotli compression. A CDN alone reduces TTFB by 60–80% for geographically distributed audiences.

5. Render-blocking CSS and JavaScript Scripts in the <head> block the browser from rendering anything until they fully download and execute. Fix: add defer or async to non-critical JavaScript, inline critical CSS for above-the-fold content, and load non-critical CSS asynchronously.

6. Score varies between tests. PageSpeed scores are not perfectly reproducible — they vary based on server load, network conditions, and CPU benchmarks at test time. Run three tests and take the median. For ranking purposes, focus on your 28-day CrUX field data in Google Search Console, not individual lab test scores.

7. Desktop passes but mobile fails. Google uses mobile-first indexing — your mobile score determines your rankings, not your desktop score. If mobile is failing, the usual culprits are render-blocking JavaScript that a slower mobile CPU cannot process as quickly, unoptimised images being served at desktop dimensions to mobile screens, and third-party scripts that are especially slow on 4G connections.