“The site feels slow” isn’t actionable. Performance testing turns it into numbers you can improve: how long until the server responds, until the main content appears, until the page responds to input. Good testing combines lab tests (controlled, repeatable) with field data (what real visitors experience).
Lab vs field data
| Type | Tools | Pros | Cons |
|---|---|---|---|
| Lab | Lighthouse, PageSpeed Insights (lab section), WebPageTest, DevTools | Repeatable, detailed diagnostics | Simulated device and network |
| Field (RUM) | Chrome UX Report (CrUX), PageSpeed Insights (field section), Search Console, web-vitals JS |
Real users, real devices | Needs traffic; 28-day aggregation in CrUX |
Use lab tests to find and fix problems, and field data to confirm real-world improvement.
Core Web Vitals
| Metric | Measures | Good |
|---|---|---|
| LCP (Largest Contentful Paint) | When the main content appears | ≤ 2.5 s |
| INP (Interaction to Next Paint) | Responsiveness to clicks and taps | ≤ 200 ms |
| CLS (Cumulative Layout Shift) | Visual stability | ≤ 0.1 |
| TTFB (supporting metric) | Server response time | ≤ 0.8 s |
See Core Web Vitals and server performance.
Tools
PageSpeed Insights (pagespeed.web.dev): Lighthouse lab results, plus CrUX field data for your URL and origin. The first stop.
Lighthouse in Chrome DevTools, or from the command line, for repeatable runs:
npx lighthouse https://example.com --preset=desktop --output=html --output-path=report.html
npx lighthouse https://example.com --only-categories=performance --quiet --chrome-flags="--headless"WebPageTest: tests from real browsers in many locations and connection types, with waterfalls, filmstrips, and repeat-view caching analysis. Great for comparing regions and CDN effects.
DevTools Network and Performance panels: waterfalls, request sizes, cache hits, long tasks.
Test the server side directly
Separate server speed from frontend weight:
curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer} total %{time_total}\n' https://example.com/Run it several times (cold and warm cache), and from different regions (a small VPS in another location works well). High TTFB points to the server, the application, or caching. See WordPress TTFB and choosing a VPS location.
A repeatable workflow
- Baseline: PageSpeed Insights (mobile and desktop) for key pages (home, a product or article, checkout), plus
curlTTFB. - Fix the biggest issues first:
- slow TTFB → page caching, PHP/DB tuning. See Nginx FastCGI cache;
- heavy images → WebP/AVIF, sizing. See WebP and AVIF;
- render-blocking and unused JS/CSS → see minify CSS and JS;
- caching headers → see HTTP caching headers;
- layout shifts → image dimensions, reserved space for ads and embeds.
- Re-test under the same conditions (Lighthouse varies run to run: use the median of 3–5 runs).
- Watch field data over the next weeks (CrUX updates on a 28-day window).
Automate it
- Lighthouse CI in your pipeline, with performance budgets (fail the build if the JS bundle or LCP regresses).
- sitespeed.io or scheduled WebPageTest runs for trend dashboards.
- Real user monitoring with the
web-vitalslibrary, sending metrics to your analytics or Prometheus. See observability basics.
Performance vs load testing
Performance testing measures one user’s experience. Load testing measures how the server behaves under many concurrent users. You need both. See load testing with k6.
Quick reference
| Question | Tool |
|---|---|
| How fast for real users? | CrUX / PageSpeed field data |
| Why is it slow? | Lighthouse, WebPageTest waterfalls |
| Is the server slow? | curl -w TTFB, from several regions |
| Did a change regress? | Lighthouse CI budgets |
| Can it handle traffic? | k6 / wrk load tests |
Related: website speed optimization and CDN for websites.