// SPEED TEST
Website speed test
Measures Core Web Vitals, server response time, and page weight — then tells you what to fix first.
What this measures
This test runs your page through Google's PageSpeed Insights (the same Lighthouse engine behind Google's own tooling) and distills the result into what matters: the performance score, the Core Web Vitals, real-visitor field data where Google has it, the three fixes worth doing first, and what third-party scripts are costing you.
How to read your result
- The performance score
- Lighthouse's 0–100 lab score. 90 or above is good; 50–89 needs work; below 50 is poor. It is a weighted blend of the loading metrics below, so a low score always has a specific metric behind it.
- LCP — good under 2.5 s
- Largest Contentful Paint: when the biggest image or text block finishes rendering. Google's threshold for a good experience is 2.5 seconds or less, measured at the 75th percentile of visits.
- INP — good under 200 ms
- Interaction to Next Paint: how quickly the page responds when someone taps or clicks. 200 ms or less is good. INP replaced First Input Delay (FID) as a Core Web Vital in 2024, so ignore any advice still built around FID.
- CLS — good under 0.1
- Cumulative Layout Shift: how much the page jumps around while loading. A score of 0.1 or less is good. Shifts are usually images or ads inserted without reserved space.
- Lab vs field data
- The lab result is one simulated load from Google's test device; field data is what real Chrome visitors experienced over the past 28 days. When the two disagree, trust the field data — it is what Google's ranking systems use, and it appears here whenever your site has enough traffic.
- Top fixes and third-party cost
- The fix list leads with your worst-scoring metrics, then fills in Lighthouse's highest-impact opportunities, so start at the top. The third-party table shows what analytics, chat widgets, and embeds cost — script weight your hosting cannot fix.
Common causes & fixes
- Oversized images
- The most common LCP killer. Serve images at the size they are displayed, compress them, and use modern formats like WebP or AVIF. If an image is the LCP element, preload it.
- Render-blocking scripts and CSS
- Scripts loaded in the head stop the page from painting. Defer non-critical JavaScript, inline the small amount of CSS needed for the first screen, and load the rest asynchronously.
- Slow server response
- Every metric waits behind TTFB — a slow first byte pushes LCP and FCP back before the page has rendered a single pixel. If TTFB is your top fix, run the dedicated TTFB test here to see which phase is at fault.
- Heavy third-party scripts
- Tag managers, chat widgets, and ad scripts run on your visitors' devices and drag down INP. Remove the ones you do not use, and load the rest after the page is interactive.
Frequently asked questions
What are Core Web Vitals?
Google's three user-experience metrics: LCP (loading, good at 2.5 s or less), INP (responsiveness, good at 200 ms or less), and CLS (visual stability, good at 0.1 or less). Google measures them at the 75th percentile of real visits and uses them as a ranking signal.
Why does my score change between runs?
The lab test is a single simulated load, so network conditions, server load, and A/B tests on your own page all move the number. Treat the score as a range and the metric breakdown as the signal.
Is the lab score what Google ranks me on?
No — ranking uses field data from real Chrome users, not the lab score. The lab run exists to diagnose problems on demand; the field section on this page shows the ranking-relevant numbers when your site has enough traffic to have them.
Which fix should I do first?
The top item in the fix list. It leads with whichever metric is failing worst on this page, then the highest-impact opportunities — fixing the top item usually moves the score more than several small ones combined.
Related guides