Slow page loads cost you visitors. 53% of mobile users abandon sites that take longer than 3 seconds to load. Here is exactly how to identify what is slowing your pages down using built-in browser developer tools — no external tools needed.
Core Web Vitals Benchmarks
Every page load can be measured against four key metrics:
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤2.5s | 2.5s–4.0s | >4.0s |
| FID (First Input Delay) | ≤100ms | 100ms–300ms | >300ms |
| CLS (Cumulative Layout Shift) | ≤0.1 | 0.1–0.25 | >0.25 |
| TTFB (Time to First Byte) | ≤800ms | 800ms–1800ms | >1800ms |
Step 1: Open the Performance Tab
Press F12 (or Ctrl+Shift+I on Windows, Cmd+Option+I on Mac) to open DevTools. Click the "Performance" tab. This is where you record and analyze runtime performance.
Before recording, make sure to:
- Disable browser extensions to avoid noise
- Select "6x slowdown" to simulate mid-tier mobile devices
- Check "Web Vitals" checkbox if your browser version supports it
Step 2: Record a Page Load
Click the record button (circle icon), then reload the page (Ctrl+R). Wait for the page to fully load, including any lazy-loaded images. Stop the recording.
What to look for in the flame chart:
- Long purple bars: JavaScript execution blocking the main thread
- Blue bars: HTML parsing
- Yellow bars: Style recalculation
- Green bars: Rendering and compositing
Step 3: Check the Network Waterfall
Switch to the Network tab and reload. Sort by Time descending to find the heaviest requests.
Key thresholds:
- Total page weight: Keep under 1,600KB for mobile
- Individual image files: Compress anything over 200KB
- JavaScript bundles: Split bundles larger than 300KB
- CSS files: Consolidate files over 100KB using tree-shaking
Step 4: Find Render-Blocking Resources
In the Network tab, look for resources marked with a purple bar in the timing column. These are render-blocking — the browser pauses rendering until they download and parse.
Common culprits:
- Unminified CSS files (saving 15–40% file size when minified)
- Synchronous script tags in
<head> - Font loading CSS (typically 15–30KB per font)
- Third-party analytics or tracking scripts (often 50–200KB)
Step 5: Measure Layout Shifts
Open the Elements panel, then click the Layout pane. Enable "Layout shift regions" to see which elements move during page load.
Common causes:
- Images without explicit width/height attributes (contributes 60% of CLS issues)
- Dynamically injected content above the fold
- Web fonts that cause invisible text flash
Quick Fixes That Deliver Results
Based on data from thousands of audited pages, these optimizations consistently show the biggest impact:
- Add lazy loading to below-fold images — reduces initial payload by 30–50%
- Minify CSS and JS — average 25% file size reduction
-
Use
font-display: swap— eliminates invisible text flash within 2 lines of CSS - Defer non-critical scripts — cuts blocking time by 40–70%
- Set explicit image dimensions — fixes most CLS issues instantly
- Enable gzip or brotli compression — 60–80% reduction in transfer size
How to Verify Your Changes
After making changes, run a full audit 3 times and average the results. Single runs can vary by ±15% due to network conditions and CPU throttling.
Open the Lighthouse tab in DevTools, select Performance only, and click analyze. Check that your LCP is under 2.5 seconds and CLS is under 0.1.
The entire audit process takes about 5 minutes once you know the steps.
Top comments (0)