Test loading speed, Core Web Vitals & performance score — free & instant
Enter any URL — results appear in ~5 seconds
Initializing…
Desktop
For field data from real Chrome users, also check Google PageSpeed Insights ↗
Our free page speed checker gives you a comprehensive picture of your website's loading performance in seconds. Enter any URL and get instant results covering your overall performance score, all three 2026 Core Web Vitals (LCP, INP, and CLS), First Contentful Paint, Time to First Byte, page size, request count, and actionable optimization recommendations — all without signing up, installing anything, or providing your email address.
This tool tests both desktop and mobile performance — critical in 2026, when mobile traffic represents over 58% of all global web visits and Google's ranking algorithms weight mobile Core Web Vitals as primary signals. Whether you're a website owner monitoring site health, a developer debugging a slow page, or an SEO professional auditing client sites, this tool gives you the performance data you need to take action.
Page speed refers to how quickly a web page fully loads and becomes usable for visitors. It is not a single measurement but a collection of metrics that together describe the user experience of page loading: how fast the first content appears, when the main visual element is painted, how stable the layout is as it loads, and how responsive the page is to user input.
Google has used page speed as a ranking signal since 2010 for desktop and 2018 for mobile. With the full rollout of Core Web Vitals as ranking factors (2021) and their ongoing refinement through 2026, page speed's influence on organic search rankings has only deepened. As of the March 2026 core update, the three Core Web Vitals — LCP, INP, and CLS — each carry equal weight as ranking signals and function as what SEO professionals describe as a "tiebreaker plus filter": when two pages are similar in content quality and authority, the faster one wins, and pages with critically poor scores can lose ranking positions even against less authoritative competitors.
Beyond SEO, page speed directly impacts business outcomes. Research consistently shows that a one-second delay in page load time reduces conversions by approximately 7%, and sites that pass all three Core Web Vitals thresholds see an average of 24% lower bounce rates compared to failing competitors. For e-commerce sites, the financial impact of speed optimization is among the highest-ROI technical investments available.
Core Web Vitals are Google's official set of metrics for measuring real-world user experience. Since March 2024, the three Core Web Vitals are LCP, INP, and CLS. Note: First Input Delay (FID) was permanently replaced by INP — if you see FID referenced in older guides, that information is outdated.
Largest Contentful Paint measures how long it takes for the largest visible content element on the page to be rendered in the browser viewport. This is typically a hero image, a large heading, or a banner — the "main event" of the page from a visual loading perspective. LCP is the Core Web Vital most directly associated with the user's perception of how fast a page loads.
2026 thresholds (updated March 2026 core update):
Primary causes of slow LCP include unoptimized hero images (too large, wrong format, no preload hint), render-blocking resources (CSS or JS that delays painting), slow server response times (high TTFB), and client-side rendering frameworks that delay content until JavaScript executes. LCP improvements deliver the most direct and measurable ranking benefit of any Core Web Vitals optimization.
Interaction to Next Paint replaced First Input Delay (FID) in March 2024 and became an equal-weight Core Web Vitals ranking signal in the March 2026 update. INP measures the time between a user interaction (click, tap, or key press) and the next visual update (paint) that the browser produces in response — across all interactions on the page, not just the first one.
This makes INP fundamentally stricter than FID. A page where the first button click responded in 50 ms (perfect FID score) but every subsequent interaction took 600 ms would have had a "Good" FID but a "Poor" INP. INP exposes pages where JavaScript execution on the main thread causes interaction lag throughout the entire user session.
INP thresholds:
INP is currently the most commonly failed Core Web Vital — approximately 43% of websites fail the 200 ms threshold, according to 2026 CrUX data. The primary cause is JavaScript-heavy pages where tag managers, chat widgets, analytics scripts, cookie consent banners, A/B testing tools, and personalization scripts compete for the main thread, delaying the browser's ability to respond to user inputs. Sites with poor INP see measurable ranking drops averaging 0.8 positions on competitive queries.
Cumulative Layout Shift measures how much page content unexpectedly moves around as the page loads — the frustrating experience of trying to click a button only to have it jump somewhere else because an image, ad, or font loaded and pushed content around. CLS is scored as a dimensionless number (not time-based) representing the total "instability" of visible elements during the page load window.
CLS thresholds (unchanged in 2026):
Common causes of high CLS include images without explicit width/height attributes (so the browser doesn't reserve space), ads with dynamic sizes, web fonts that cause layout reflow when they load, and dynamically injected content (banners, cookie notices, popups) that push other content down. CLS is often the easiest Core Web Vital to fix — in many cases, simply adding width and height attributes to all images resolves a significant portion of layout shift.
| Metric | Abbreviation | What It Measures | Good (2026) | Needs Improvement | Poor | Ranking Signal? |
|---|---|---|---|---|---|---|
| Largest Contentful Paint | LCP | Time for main visual element to render | < 2.0s | 2.0–4.0s | > 4.0s | ✅ Yes (primary) |
| Interaction to Next Paint | INP | Page responsiveness to all user interactions | < 200ms | 200–500ms | > 500ms | ✅ Yes (primary) |
| Cumulative Layout Shift | CLS | Visual stability / unexpected layout movement | < 0.1 | 0.1–0.25 | > 0.25 | ✅ Yes (primary) |
| First Contentful Paint | FCP | Time to first visible content of any kind | < 1.8s | 1.8–3.0s | > 3.0s | ⚠ Indirect |
| Time to First Byte | TTFB | Server response time | < 800ms | 800ms–1.8s | > 1.8s | ⚠ Indirect (affects LCP) |
| Speed Index | SI | How quickly page content is visually populated | < 3.4s | 3.4–5.8s | > 5.8s | ⚠ Indirect |
| Total Blocking Time | TBT | Time main thread is blocked from responding to input | < 200ms | 200–600ms | > 600ms | ⚠ Indirect (lab proxy for INP) |
| First Input Delay | FID | Retired March 2024. Replaced by INP. | No longer a Core Web Vital or ranking signal | |||
Google has been transparent about how page speed integrates with its ranking algorithms. The current framework (as of 2026) works as follows:
Content quality and authority remain the primary ranking signals — a fast page with thin, low-quality content will not outrank a strong, authoritative page that loads in 2.5 seconds. Page speed functions more as a filter and tiebreaker than a primary ranking driver. However, two important points complicate this picture:
First, severe speed failures cause direct ranking drops. Sites with LCP above 4.0 seconds or INP above 500 ms have been documented experiencing ranking drops of 2–4 positions even when their content quality is strong, following the March 2026 core update. These aren't marginal effects — they represent measurable traffic losses.
Second, speed now affects AI Overview eligibility. Google's AI-powered search results (AI Overviews) prioritize sources that load quickly and have clean, structured content. A slow or unstable website creates friction for Google's automated crawlers and reduces the likelihood of being selected as an AI Overview source — a new and increasingly important source of organic visibility.
The practical implication: in 2026, having "good enough" speed is a baseline requirement for full SEO competitiveness, not a nice-to-have optimization. Only 47% of websites worldwide currently pass all three Core Web Vitals thresholds, meaning passing Core Web Vitals immediately places you ahead of more than half the web in terms of technical SEO performance.
| Speed Impact | Business Metric | Source Type |
|---|---|---|
| 1-second delay in load time | 7% reduction in conversions | Multiple e-commerce studies |
| Passing all 3 Core Web Vitals | 24% lower bounce rate vs failing competitors | Digital Applied 2026 analysis |
| LCP above 4.0s (2026) | 2–4 ranking position drop on competitive queries | March 2026 core update data |
| INP above 200ms | 0.8 average ranking position drop | March 2026 core update data |
| Mobile users experiencing 3s+ load | 53% abandon the page | Google/SOASTA research |
| 100ms improvement in load time | 1% increase in revenue (e-commerce) | Deloitte mobile speed study |
The single highest-impact LCP optimization is ensuring your hero image (the one that becomes the LCP element) is correctly handled. Add <link rel="preload" as="image" href="hero.webp"> in your <head> so the browser discovers and begins downloading the image as early as possible, before the CSS and body parse. Convert the image to WebP (typically 25–35% smaller than JPEG at equivalent quality) and serve it at the correct size for each viewport using srcset and sizes attributes. This alone can move LCP from 3–4 seconds to under 2.0 seconds on most pages.
Time to First Byte is the foundation of all other speed metrics — if your server takes 1.5 seconds to respond, your LCP cannot be under 2.0 seconds regardless of other optimizations. TTFB above 800 ms is a red flag that points to one of four causes: underpowered shared hosting, no server-side caching (database queries running on every page load), no CDN (users far from your server), or slow origin infrastructure. Upgrading to a quality VPS with full-page caching (WP Rocket, Varnish, Redis) and serving through a CDN (Cloudflare, Fastly, BunnyCDN) typically reduces TTFB to under 200 ms.
CSS and JavaScript files in the <head> block the browser from rendering any content until they're fully downloaded and parsed. Audit your <head> section: add defer or async to all non-critical <script> tags. Move non-critical CSS to load asynchronously using the onload trick. Inline only the critical CSS needed for above-the-fold content (typically 10–15 KB) directly in the <head>, and load the rest asynchronously. This reduces time-to-first-paint by removing the delay from render-blocking resources.
INP is primarily a JavaScript problem. Every third-party script — tag manager, chat widget, heatmap tool, A/B testing platform, consent banner, retargeting pixel — consumes main thread time and delays the browser's ability to respond to user input. Audit every script on your page with a "does this directly generate revenue or serve legal requirements?" test. Remove or delay (load after first interaction using event listeners) anything that doesn't pass. Replacing large JavaScript libraries (Lodash, Moment.js, full jQuery) with native browser APIs or lightweight alternatives can also significantly reduce TBT and improve INP.
Images typically account for 50–70% of a web page's total data weight. Converting from JPEG/PNG to WebP reduces image size by 25–35% with no visible quality loss. Converting to AVIF (supported in all modern browsers as of 2023) reduces size by a further 20–30% compared to WebP. Serve modern formats using the <picture> element with JPEG/PNG fallback for older browsers. Tools like Squoosh, Sharp, and ImageMagick handle batch conversion. Most content management systems (WordPress, Shopify, Webflow) have plugins or built-in settings to auto-serve WebP.
Native lazy loading (loading="lazy" attribute on <img> and <iframe> tags) prevents off-screen images from loading until the user scrolls near them. This dramatically reduces initial page weight and reduces the number of HTTP requests needed for above-fold rendering. One critical caveat: never apply loading="lazy" to your LCP element (the hero image) — the browser delay this introduces will significantly worsen your LCP score. Apply lazy loading to all below-fold images only.
Adding explicit width and height attributes to every <img> tag is the single most effective and easiest fix for high CLS scores. When browsers know an image's dimensions before it loads, they reserve the correct amount of space in the layout — preventing the content jump that occurs when an unsized image loads and pushes text and buttons out of position. This is especially critical for images loaded via CSS (use aspect-ratio) and embedded content like YouTube videos (use the padding-top aspect ratio wrapper technique).
Configure your server to send Cache-Control headers with long expiry times for static assets (CSS, JS, images, fonts): Cache-Control: max-age=31536000, immutable for versioned assets. This means returning visitors load your page almost instantly from browser cache rather than re-downloading everything. Also enable Gzip or Brotli compression on your server — Brotli typically achieves 15–20% better compression than Gzip for HTML, CSS, and JavaScript files. Most modern web servers (Nginx, Apache, Cloudflare) support both.
Minification removes whitespace, comments, and unnecessary characters from your code files without changing their functionality, reducing file sizes by 15–30% for CSS and JavaScript. Tools: Terser (JavaScript minification), cssnano (CSS), HTMLMinifier. Build tools like Webpack, Vite, and Parcel include minification as a built-in production optimization. For WordPress, plugins like WP Rocket, Autoptimize, and LiteSpeed Cache handle CSS and JS minification automatically. Minification is a low-effort, high-impact optimization that should be standard practice on all production websites.
A CDN stores cached copies of your website's static assets (and optionally your full pages) on servers distributed worldwide. When a user visits your site from Tokyo and your server is in Frankfurt, a CDN serves them assets from a Tokyo edge server — dramatically reducing TTFB and overall load time. Cloudflare offers a generous free CDN plan that works for most small to medium websites. Enterprise options include Fastly, AWS CloudFront, and Akamai. Even for websites with primarily local audiences, a CDN improves performance during traffic spikes and adds DDoS protection as a bonus.
Third-party scripts (Google Analytics, Facebook Pixel, chat widgets, ad tags, Hotjar, Intercom, Trustpilot widgets) are among the most common causes of poor INP and high TBT. Each third-party domain requires a separate DNS lookup, TCP handshake, and TLS negotiation — potentially adding 100–300 ms of latency per domain. Audit your third-party scripts using the Network tab in Chrome DevTools, sorted by domain. Consolidate scripts through a tag manager where possible. Load non-essential scripts asynchronously after the page becomes interactive. Use Partytown for running third-party scripts in a web worker to eliminate main-thread impact.
Web fonts are a common cause of both CLS (text reflow when the font loads) and FCP delay (pages show blank text while waiting for fonts). Add font-display: swap to your @font-face declarations so text displays immediately in a fallback font while the web font loads. Use <link rel="preconnect"> for Google Fonts and other external font sources. Self-host fonts where possible to eliminate cross-origin latency. For Google Fonts specifically, use the display=swap parameter in the Google Fonts URL and consider subsetting fonts to include only the character sets you actually use.
Page speed tools generally produce two types of data, and understanding the difference is essential for interpreting results:
Lab data (also called synthetic data) is generated by running a controlled test in a simulated environment — typically using Google Lighthouse running in a headless Chrome browser with a set of standardized conditions (device type, network speed, CPU throttling). This is what tools like our page speed checker, GTmetrix, and WebPageTest primarily provide. Lab data is useful for debugging specific issues and tracking improvements during development because it's consistent and reproducible.
Field data (also called Real User Monitoring or RUM data) comes from actual Chrome browser users visiting your site with their real devices, real network conditions, and real geographic locations. Google collects this data through the Chrome UX Report (CrUX) and uses it — not lab data — as the actual input to Core Web Vitals ranking signals in Google Search Console and PageSpeed Insights. A page might score 95 in Lighthouse lab testing but have poor field data if it serves ads or personalized content that isn't captured in synthetic tests.
The practical implication: use lab data for development and debugging, but always check your field data in Google Search Console (Core Web Vitals report) or Google PageSpeed Insights to understand what Google is actually seeing and using for ranking purposes.
Google PageSpeed Insights scores pages from 0–100: 90–100 is "Good," 50–89 is "Needs Improvement," and 0–49 is "Poor." However, the performance score is a composite Lighthouse metric used for guidance — what actually affects your Google rankings are the three Core Web Vitals field data scores (LCP, INP, CLS) measured by Google through the Chrome UX Report. Aim for a performance score above 90 on desktop and above 70 on mobile, but prioritize "Good" ratings on all three Core Web Vitals over the composite score.
Different tools use different testing conditions, server locations, and metric weighting. Lighthouse (used by PageSpeed Insights) applies CPU and network throttling to simulate a mid-range mobile device. GTmetrix uses different default settings. Our tool provides a standardized test but lab conditions always vary slightly. For the most authoritative data on how your site performs for Google ranking purposes, always check your field data in Google PageSpeed Insights (which shows Chrome UX Report data) and Google Search Console's Core Web Vitals report.
Yes. Google uses mobile-first indexing, meaning it primarily crawls and ranks based on your mobile page experience. Mobile Core Web Vitals scores are weighted as the primary ranking signal, with desktop as secondary. Mobile performance is also harder to achieve — typical mobile devices have slower CPUs and less reliable networks. In 2026, approximately 58% of all web traffic is mobile, making mobile speed optimization directly tied to the majority of your organic traffic potential.
Interaction to Next Paint (INP) replaced FID as a Core Web Vital in March 2024 and became an equal-weight ranking signal in the March 2026 update. INP is a significantly stricter metric — FID only measured the delay on the very first user interaction, while INP measures the response time of every interaction (click, tap, keypress) throughout the entire page session, using the 98th percentile interaction as the score. This means pages that appeared to have excellent FID scores may now struggle with INP if their JavaScript blocks interaction responses later in the session.
Google uses a 28-day rolling window of Chrome UX Report (CrUX) field data to evaluate Core Web Vitals scores. This means after implementing speed improvements, it typically takes 4–6 weeks for the improvements to fully reflect in your Google Search Console Core Web Vitals report and begin influencing rankings. The lab scores in tools like this checker update immediately, but ranking impact requires real users to experience your improved site and that data to accumulate in the CrUX dataset.
This is extremely common. Mobile devices have slower processors and less reliable networks, and mobile PageSpeed testing applies CPU throttling (4× slowdown) and network throttling (simulated 4G) to reflect real-world mobile conditions. Common causes of poor mobile vs. desktop performance gaps include unoptimized images (too large for mobile viewport), heavy JavaScript that blocks interaction on slower processors, render-blocking resources, and lack of mobile-specific optimizations (responsive images with srcset, touch event handling). Prioritize LCP image optimization, JavaScript reduction, and font optimization for the largest mobile performance gains.
Time to First Byte (TTFB) measures the time from the browser making an HTTP request to receiving the first byte of the server's response. High TTFB (above 800 ms) indicates a server-side problem: slow hosting, no page caching (WordPress running database queries on every load), no CDN, or slow DNS resolution. The most effective fixes are enabling full-page caching (WP Rocket, W3 Total Cache, LiteSpeed Cache for WordPress), upgrading to quality hosting (managed WordPress hosting, VPS instead of shared), and using a CDN with edge caching (Cloudflare). Properly implemented page caching can reduce TTFB from 1–2 seconds to under 100 ms.
The correlation between page speed and e-commerce conversion rates is one of the most studied areas in web performance. Research from Deloitte found that a 100 ms improvement in mobile site speed increased conversion rates by up to 8.4% for retail sites. Amazon estimated that every 100 ms of latency cost them 1% in sales. More recent data shows that mobile users abandon pages that take more than 3 seconds to load at a rate of 53%. For e-commerce sites, page speed optimization consistently delivers among the highest ROI of any technical investment — often outperforming content, email marketing, and paid advertising in terms of revenue per dollar spent.