How to Measure Website Performance: Tools and Metrics in 2027

Quick answer: To measure website performance, use Lighthouse (lab data, Chrome DevTools), WebPageTest (detailed waterfall, multiple locations), Google PageSpeed Insights (field + lab data), and Google Search Console (Core Web Vitals report). Key metrics: LCP, INP, CLS (Core Web Vitals), FCP, TTFB, TTI. For real user monitoring (RUM), use SpeedCurve, Calibre, or Datadog. Run Lighthouse before every deployment, WebPageTest weekly, and monitor Search Console monthly. Combine lab data (controlled) with field data (real users) for complete picture.[1][3][4]

Performance measurement is the foundation of optimization. You can't improve what you don't measure. In 2027, with multiple measurement tools and metrics available, knowing which to use and when is critical.

Lab vs field data

Lab data (synthetic)

• What: Simulated tests in controlled environments
• Tools: Lighthouse, WebPageTest
• Pros: Reproducible, detailed, debuggable
• Cons: Doesn't reflect real user conditions
• Use for: Development, debugging, regression testing

Field data (real user monitoring)

• What: Actual user experience data collected from real visitors
• Tools: Google Search Console, Chrome UX Report (CrUX), RUM tools
• Pros: Reflects real conditions, user devices, networks
• Cons: Less detailed, harder to debug
• Use for: Production monitoring, trend analysis

Best practice: Use lab data during development, field data in production. Compare lab vs field to identify discrepancies.[3][4]

Measurement tools

1. Lighthouse (Chrome DevTools)

Best for: Quick audits during development.

How to use:

1. Open Chrome DevTools (F12)
2. Go to Lighthouse tab
3. Select categories (Performance, Accessibility, Best Practices, SEO)
4. Choose device (Mobile/Desktop)
5. Click "Analyze page load"

Metrics reported:

• Performance score (0-100)
• LCP, FCP, CLS, TBT, SI
• Opportunities (specific improvements)
• Diagnostics (detailed analysis)

Limitations: Single run, throttled CPU/network, no real user data.[4]

2. WebPageTest (webpagetest.org)

Best for: Detailed performance analysis, multiple locations.

Features:

• Test from 40+ global locations
• Multiple browsers (Chrome, Firefox, Edge)
• Connection throttling (3G, 4G, cable)
• Filmstrip view (visual load progression)
• Waterfall chart (request timing)
• Repeat view (cached performance)
• Lighthouse integration

Key metrics:

• TTFB, Start Render, FCP, LCP, CLS
• Total bytes, total requests
• Time to Interactive (TTI)

Advanced: Scripted tests, custom metrics, API for automation.[4]

3. Google PageSpeed Insights (pagespeed.web.dev)

Best for: Quick field + lab data for any URL.

Provides:

• Field data from CrUX (if available)
• Lab data from Lighthouse
• Core Web Vitals assessment (Pass/Fail)
• Specific recommendations

Use when: You want both field and lab data without running tests yourself.[4]

4. Google Search Console

Best for: Site-wide Core Web Vitals monitoring.

Core Web Vitals report:

• Shows which URLs pass/fail
• Groups URLs by status (Good, Needs Improvement, Poor)
• Tracks trends over time
• Identifies specific issues per URL group

Use when: Monitoring production performance at scale.[4]

5. Chrome User Experience Report (CrUX)

Best for: Historical field data for any site.

Access via:

• BigQuery (free, SQL queries)
• CrUX API (programmatic)
• PageSpeed Insights (simplified)

Provides: p75 (75th percentile) values for LCP, FID/INP, CLS, FCP, TTFB for real users.[4]

6. Real User Monitoring (RUM) tools

Best for: Continuous production monitoring.

Features: Real user data, performance budgets, alerts, dashboards, historical trends.[3][4]

Key metrics explained

Core Web Vitals

Additional metrics

Performance budgets

Set budgets to prevent regressions:

{
  "budgets": [
    {
      "resourceSizes": [
        { "resourceType": "script", "budget": 170 },
        { "resourceType": "image", "budget": 200 },
        { "resourceType": "stylesheet", "budget": 50 },
        { "resourceType": "total", "budget": 500 }
      ],
      "resourceCounts": [
        { "resourceType": "total", "budget": 50 }
      ],
      "timings": [
        { "metric": "interactive", "budget": 3800 },
        { "metric": "first-contentful-paint", "budget": 1800 }
      ]
    }
  ]
}

Enforce in CI/CD: fail the build if budgets are exceeded.[4]

Automation

Lighthouse CI

# GitHub Actions
- name: Lighthouse CI
  uses: treosh/lighthouse-ci-action@v9
  with:
    urls: |
      https://example.com
      https://example.com/blog
    budgetPath: ./lighthouse-budget.json
    uploadArtifacts: true

WebPageTest API

# Run automated tests
curl -X POST "https://www.webpagetest.org/runtest.php?url=https://example.com&k=YOUR_API_KEY&f=json"

CrUX API

// Fetch field data
const response = await fetch('https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=YOUR_API_KEY', {
  method: 'POST',
  body: JSON.stringify({ url: 'https://example.com', formFactor: 'PHONE' }),
});

Frequently Asked Questions (FAQ)

What is the difference between lab and field data?

Lab data is collected in controlled environments (simulated device, network). Field data is collected from real users. Lab data is reproducible and debuggable; field data reflects actual user experience.[3][4]

Which tool should I use for performance testing?

Use Lighthouse for quick development audits, WebPageTest for detailed analysis, PageSpeed Insights for field + lab data, and Search Console for site-wide monitoring. For production, add RUM tools.[3][4]

How often should I test performance?

Run Lighthouse before every deployment. Weekly automated tests via CI/CD. Monthly comprehensive audits. Monitor Search Console weekly for Core Web Vitals changes.[3][4]

What is a performance budget?

A performance budget sets limits on metrics (page weight, JS size, requests, load times). It prevents performance regressions by failing CI/CD builds that exceed budgets.[4]

How do I test on mobile devices?

Use Chrome DevTools device emulation (throttled CPU/network), WebPageTest with mobile profiles, or test on real devices. Real device testing is most accurate.[3][4]

What is TTFB and why does it matter?

TTFB (Time to First Byte) measures how long the server takes to respond. It's the first performance metric and affects all subsequent metrics. Target: < 200ms. Improve with caching, CDN, and server optimization.[3][4]

Can I automate performance testing?

Yes. Use Lighthouse CI in GitHub Actions, WebPageTest API for scheduled tests, and CrUX API for field data monitoring. Set up alerts for budget violations.[3][4]

What is the difference between FCP and LCP?

FCP (First Contentful Paint) measures when the first text or image appears. LCP (Largest Contentful Paint) measures when the largest content element appears. FCP is about initial feedback; LCP is about main content loading.[3][4]

Related reading on MintSaaS

• How to Improve Website Speed: Complete Performance Guide
• Core Web Vitals and Image Optimization: LCP, CLS, INP Guide
• How to Use CDN for Faster Website Delivery

Sources

[1] MDN Web Docs — Performance: https://developer.mozilla.org/en-US/docs/Web/Performance

[2] Web.dev — Measure performance: https://web.dev/articles/user-centric-performance-metrics

[3] MintSaaS Image Compressor: https://www.mintsaas.net/products/image-compressor

[4] Web.dev — Core Web Vitals: https://web.dev/vitals/

[5] MintSaaS PDF Compressor: https://www.mintsaas.net/products/pdf-compressor

Free tools on MintSaaS

Try our free tools to put this guide into practice:

• Image Compressor
• PDF Compressor
• Image Converter
• MintSaaS Home
• MintSaaS Blog
• How to Compress Images