Skip to main content
Beta: Front-End Checklist is currently in beta. Some issues are still being fixed. Thanks for your patience.

Perform browser-based performance audits

Conduct performance audits in a full browser environment to capture accurate runtime metrics and layout shifts.

Utilities
Quick take
Typical fix time 10 min
  • Use real browser engines to capture runtime metrics (LCP, CLS, INP)
  • Synthetic tests in full browsers reveal execution bottlenecks
  • Verify performance across different device and connection simulations
Why it matters: Static analysis alone cannot simulate the complex rendering, script execution, and layout processes of modern web browsers, which is essential for capturing real-world performance.

Rule Details

While static analysis can catch some performance issues, many critical metrics can only be measured during page execution in a real web browser.

Code Examples

Using Lighthouse CLI for Browser Audits

Lighthouse runs a full Chrome instance to audit your page.

# Install Lighthouse
npm install -g lighthouse
 
# Run an audit on a URL
lighthouse https://example.com --view --chrome-flags="--headless"

Scripting Browser Audits with Puppeteer

You can automate browser-based checks using Puppeteer or Playwright.

const puppeteer = require('puppeteer');
 
(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
 
  // Throttling network and CPU
  const client = await page.target().createCDPSession();
  await client.send('Network.emulateNetworkConditions', {
    offline: false,
    latency: 100,
    downloadThroughput: 750 * 1024 / 8, // Fast 3G
    uploadThroughput: 250 * 1024 / 8,
  });
 
  await page.goto('https://example.com');
  const metrics = await page.metrics();
  console.log('Browser Metrics:', metrics);
 
  await browser.close();
})();

Why It Matters

  • Accurate Metrics: Core Web Vitals like Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) require a rendering engine to be calculated.
  • JavaScript Execution: Only a browser can measure the impact of JavaScript on main-thread blocking and interaction latency.
  • Real-World Simulation: Browsers allow for throttling CPU and network speeds to simulate real-world user conditions.
  • Visual Feedback: Browser-based tools provide screenshots and videos of the loading process, helping to identify "jank" and layout shifts.

Best Practices

Use a real browser pass alongside Lighthouse (opens in new tab) so layout shifts, main-thread work, and interaction delays are measured in an environment that actually executes the page.

Automate in CI: Run browser-based audits on every pull request to catch regressions early. ✅ Throttling: Always test with network and CPU throttling to see how your site performs for users on slower devices. ✅ Use Multiple Regions: Audit from different geographic locations to understand the impact of latency. ✅ Mobile-First: Prioritize audits using mobile device emulation.

Don't Rely Solely on Dev Machines: Your high-end developer laptop doesn't reflect the experience of a user on a budget smartphone. ❌ Avoid Unthrottled Tests: Testing on a gigabit connection will hide most performance bottlenecks.

Tools & Validation

Standards

  • Use web.dev: Learn Performance as the standard for measuring the final production behavior, not just local synthetic output.
  • Use Chrome Developers: Lighthouse overview as the standard for measuring the final production behavior, not just local synthetic output.

Verification

Automated Checks

  • Measure the affected page or flow in Lighthouse, PageSpeed Insights, or DevTools and confirm the targeted metric improves.
  • Inspect the network waterfall or performance timeline to confirm the intended resource or execution change actually took effect.

Manual Checks

  • Verify the change on a throttled mobile profile, not just local desktop.
  • If this rule maps to a budget or Web Vital, confirm the page now stays within that threshold.

Use with AI

Copy these prompts to use with your AI assistant, or install the MCP server to use directly from Claude, Cursor, or Windsurf.

Check

Verify implementation

Ensure that performance audits are conducted in an environment that executes JavaScript and renders the page (e.g., Lighthouse, Puppeteer).

Fix

Auto-fix issues

Integrate browser-based testing tools like Lighthouse or WebPageTest into the development workflow and CI/CD pipeline.

Explain

Learn more

Explain the limitations of static analysis for performance and why a full browser environment is necessary.

Review

Code review

Review the routes, assets, and loading behavior that affect Perform browser-based performance audits. Flag exact files, requests, or rendering steps that add unnecessary network, CPU, or layout cost, and describe the measurement method used to confirm the issue.

Sources

References used to support the guidance in this rule.

Further Reading

Tools and supplementary material for exploring the topic in more depth.

PageSpeed Insights
pagespeed.web.devTool

Rules that often go hand-in-hand with this one.

Optimize web font loading

Use efficient font formats and loading strategies to prevent layout shifts and invisible text.

Performance
Avoid JavaScript-based redirects

Detects JavaScript resources that return 3XX redirects to reduce latency

Performance
Avoid serving legacy JavaScript to modern browsers

Detects ES5 polyfills and legacy JavaScript code to reduce bundle size and improve execution

Performance
Convert animated GIFs to video

Large animated GIFs are replaced with more efficient video formats like MP4 or WebM to reduce page weight.

Performance

Was this rule helpful?

Your feedback helps improve rule quality. This stays internal for now.

Loading feedback...
0 / 385