Test any URL using Google's own PageSpeed Insights API. Get your performance score, Core Web Vitals, and ranked fix opportunities for desktop and mobile.
Results
Core Web Vitals Explained
| Metric | Good | Poor | Ranking Signal |
|---|---|---|---|
| LCP | < 2.5s | > 4s | Core Web Vital |
| INP | < 200ms | > 500ms | Core Web Vital |
| CLS | < 0.1 | > 0.25 | Core Web Vital |
| FCP | < 1.8s | > 3s | Lab diagnostic |
| TBT | < 200ms | > 600ms | Lab diagnostic |
Field Data vs Lab Data
Field data comes from the Chrome User Experience Report (CrUX), reflecting real user experiences over the past 28 days. Lab data comes from Lighthouse in a controlled simulation. Google uses field data for Core Web Vitals ranking decisions, not the lab score. Pages without enough real Chrome traffic show lab data only.
Why Page Speed Is a Business Metric, Not Just a Technical One
Google's own mobile performance research found that bounce probability rises 32 percent as load time goes from 1 to 3 seconds, and Akamai's research puts the conversion cost at roughly 7 percent lost for every additional second of delay.
The numbers compound further at the extremes. The same Google dataset shows bounce probability climbing 90 percent at 5 seconds and 123 percent at 10 seconds compared to a 1-second load. On the revenue side, industry research on 0.1-second speed improvements found conversion gains of roughly 8.4 percent for retail sites and 9.2 percent for average order value, meaning speed affects not just whether someone buys but how much they buy. Google's own internal 2009 study, still cited at nearly every web performance conference since, found that a 400 millisecond delay in search results reduced search volume by 0.59 percent, a fraction that becomes enormous at Google's scale of billions of daily searches.
None of this means chasing a perfect 100 score is the goal. It means treating the metrics this tool reports as inputs to revenue and retention, not just a technical badge.
Mobile-First Indexing Changes What "Fast" Means
Google indexes and ranks the vast majority of sites using the mobile version of a page, not desktop, a policy fully rolled out years ago and still in effect in 2026. This means your mobile PageSpeed score generally carries more ranking weight than your desktop score, even for a site whose real traffic mix skews desktop. If you can only prioritise one device in this tool, prioritise mobile.
Mobile scores are also naturally lower because Lighthouse simulates a mid-range Android device on a throttled 4G connection to represent a realistic slower-end user, while desktop tests assume a fast connection and no CPU throttling. A 40 to 50 point gap between mobile and desktop scores on the same page is common and does not necessarily indicate a bug, it reflects the harsher simulated conditions.
Hosting, CDN, and Server-Side Factors
Front-end fixes like image compression and deferred scripts only go so far if the server itself is slow to respond. Time to First Byte (TTFB), the delay before the first byte of the response arrives, is often the most overlooked lever in a PageSpeed audit.
- Shared hosting is the most common cause of slow TTFB, since server resources are split across many unrelated sites. Moving to a VPS, managed WordPress host, or dedicated plan usually improves TTFB immediately.
- A CDN (content delivery network) caches static assets, images, CSS, JavaScript, at servers physically closer to each visitor, cutting latency for a geographically spread-out audience. Cloudflare, BunnyCDN, and most managed hosts include CDN functionality by default in 2026.
- Server-side caching (object caching, full-page caching, opcode caching like PHP OPcache) avoids rebuilding the same page from scratch on every request.
- Database query efficiency matters heavily for CMS-driven sites. An unoptimised WordPress database with years of accumulated post revisions and orphaned data can slow every page load measurably.
A Practical WordPress Speed Checklist
WordPress powers a large share of the sites tested with this tool, so here is a focused checklist for the platform specifically.
| Action | Why It Helps |
|---|---|
| Use a caching plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache) | Serves pre-built HTML instead of rebuilding on every visit |
| Switch to a modern image format plugin (ShortPixel, Imagify) | Automatic WebP/AVIF conversion without manual re-exporting |
| Limit active plugins to what you actually use | Each plugin adds its own CSS, JS, and database queries |
| Choose a lightweight, well-coded theme | Heavy page builders often ship large unused CSS and JS |
| Use a managed WordPress host with server-level caching | Reduces TTFB more reliably than plugin-only caching |
| Lazy-load below-the-fold images and embeds | Defers work the browser does not need for the initial view |
Beyond Performance: The Other Lighthouse Categories
The performance score is the headline number, but Lighthouse (the engine behind PageSpeed Insights) also audits Accessibility, Best Practices, and SEO in the full report available directly at pagespeed.web.dev. A page can score well on performance and still fail basic accessibility checks like missing alt text or insufficient colour contrast, or fail Best Practices checks like using deprecated APIs or serving images at the wrong aspect ratio. A genuinely fast page and a genuinely well-built page are related but not identical goals.
What Is Agentic Browsing in PageSpeed Insights?New, May 2026
Agentic Browsing is a new Lighthouse category, shipped in Lighthouse 13.3 on May 7, 2026 and rolled into public PageSpeed Insights within weeks, that scores whether an AI agent, not a human or a search crawler, could read your page's structure, trust its layout, and interact with it without guessing. Unlike Performance, Accessibility, Best Practices, and SEO, it reports a pass ratio like 2/3, not a 0 to 100 score.
This tool fetches and displays that category exactly as Google's own API returns it, alongside the four familiar scores, in the badge row at the top of your results. Every check that comes back is shown with a pass or fail state.
Why Google Added a Fifth Category
Search asks whether your content deserves to be discovered and ranked by a crawler. Agentic Browsing asks a different question entirely: could autonomous software, tools like OpenAI's Operator, Google's own Project Mariner, or an AI shopping assistant, actually operate your site well enough to complete a task on a person's behalf? A page can rank well in Google Search and still be genuinely awkward for an agent to navigate, and the reverse is also possible. The two are related but measure different things.
What the Checks Likely Cover
Based on Google's own documentation and early reporting since the May 2026 rollout, the category evaluates machine comprehension rather than keywords or backlinks. The checks commonly referenced include:
| Likely Check | What It Verifies |
|---|---|
| Accessibility tree integrity | Whether the page's underlying structure is well-formed enough for an agent to parse reliably |
| Layout stability | Whether the page shifts unexpectedly (tied to the same CLS metric behind Core Web Vitals), which risks an agent clicking the wrong element |
| llms.txt presence | Whether an AI discovery file exists at your domain root, the same file our llms.txt Generator builds |
| WebMCP tool registration | An emerging, early-stage check for structured agent-callable actions, not yet common on most sites |
Google and reporting outlets both describe the standards behind this category as still emerging, so the exact audits and thresholds may continue to change through the rest of 2026.
Should You Worry About a Low Score Right Now?
Not urgently. Google itself marks Agentic Browsing as experimental and under development, and it explicitly does not factor into your Performance, Accessibility, Best Practices, or SEO scores. A failing result here is a signal to watch, not an emergency to fix overnight. That said, the underlying fixes overlap heavily with things worth doing anyway: a clean accessibility tree, a stable layout with low CLS, and an llms.txt file. If you already run this checker's Core Web Vitals section and our llms.txt Generator, you are likely closer to a passing score than most sites.
Synthetic Testing vs Real User Monitoring
This tool, like GTmetrix and WebPageTest, runs a synthetic test: a single simulated visit under controlled conditions. That is useful for consistent before-and-after comparisons and for catching regressions immediately after a deploy. It is not the same as Real User Monitoring (RUM), which captures actual visitor performance across every device, connection type, and location in production. The CrUX field data this tool surfaces when available is Google's own aggregated RUM dataset. For ongoing monitoring beyond a single spot check, pairing a synthetic tool like this one with a RUM solution gives the fullest picture.
| Fix | Typical Saving | Metrics Improved |
|---|---|---|
| Convert images to WebP or AVIF | 1 to 4s | LCP, FCP |
| Add image width and height | CLS fix | CLS |
| Defer offscreen images | 0.5 to 2s | LCP, FCP, TBT |
| Eliminate render-blocking resources | 0.5 to 3s | FCP, LCP, TBT |
| Enable text compression | 0.5 to 1.5s | FCP, TTFB |