Web Performance Audit Checklist: 25 Essential Steps

Check CrUX data via PageSpeed Insights or BigQuery for your highest-traffic pages. Field data from real users is the ground truth Google uses for ranking — lab scores from Lighthouse can differ significantly because they do not account for real device diversity, network conditions, and user behavior.

Use Chrome DevTools Performance panel to find the Largest Contentful Paint element (usually a hero image or main heading). Trace every step in its loading chain: DNS, connection, server response, download, render. The slowest step in this chain is your LCP bottleneck.

INP measures responsiveness of clicks, taps, and key presses. Use Chrome DevTools' Performance panel to record interactions and identify long tasks blocking the main thread. Common culprits: synchronous state updates, layout thrashing, and expensive event handlers that process data instead of deferring to web workers.

Enable 'Layout Shift Regions' in Chrome DevTools Rendering tab and reload each page slowly. Blue highlights show elements that shift during load. Common causes: images without dimensions, late-loading fonts, dynamic ad slots, and injected cookie consent banners.

Run PageSpeed Insights tests for both mobile and desktop. Mobile scores are typically 20-40 points lower due to CPU throttling and network simulation. Since Google uses mobile-first indexing, your mobile scores are what actually matter for rankings — desktop scores that pass while mobile fails create a false sense of security.

Use Webpack Bundle Analyzer, Vite's `rollup-plugin-visualizer`, or Chrome DevTools Coverage tab to map your JS payload. Find the three largest modules — they typically account for 50-70% of your total JS size. Tree-shaking misses, full library imports, and polyfills for modern browsers are common offenders.

Use Chrome DevTools Network tab filtered to third-party domains to measure the total weight and request count of external scripts. Tools like Google Tag Manager, chat widgets, analytics, and A/B testing scripts regularly add 500KB-2MB of JavaScript. Evaluate each script's business value against its performance cost.

Open Chrome DevTools Performance tab, record a page load and user interaction, and look for yellow 'Long Task' bars. Tasks exceeding 50ms block user input and cause jank. Break them up using `requestIdleCallback`, `setTimeout(fn, 0)`, or move computation to web workers.

Check your build output for multiple JS chunks rather than one monolithic bundle. Use dynamic `import()` for routes and heavy components so users only download the JavaScript needed for the current page. A single-bundle SPA forces users to download code for every page on first visit.

Open Chrome DevTools Coverage tab, load your page, and interact with key features. Red lines show code that was downloaded but never executed. If more than 40% of a file is unused, it is a candidate for code splitting or removal. Focus on the largest files first.

Inspect image responses in the Network tab and verify they serve WebP or AVIF, not just PNG/JPEG. AVIF is 50% smaller than JPEG at equivalent quality; WebP is 25-30% smaller. Use `<picture>` with fallbacks or an image CDN that auto-negotiates format based on browser support.

Check that `srcset` and `sizes` attributes are set on images so mobile devices download 400px-wide images instead of 2000px-wide ones. A desktop hero image served to a mobile phone wastes 80% of the bytes downloaded. Use your image CDN's resize parameters or build-time processing.

Check that images not visible in the initial viewport have `loading='lazy'`. Without lazy loading, the browser downloads every image on the page during initial load, competing with critical resources for bandwidth. Verify the LCP image does NOT have lazy loading — it must load eagerly.

Every `<img>` and `<video>` must have `width` and `height` attributes or CSS `aspect-ratio` so the browser reserves space before the resource loads. Missing dimensions are the most common cause of CLS — the page jumps as each image loads and pushes content down.

Add `<link rel='preload' as='image' href='...' fetchpriority='high'>` for your LCP image in the `<head>`. Without preloading, the browser discovers the image only after parsing the CSS and HTML, adding hundreds of milliseconds to LCP. This is especially impactful for CSS background images.

Check TTFB in WebPageTest from multiple locations. TTFB above 600ms is a red flag — it means your server is slow to generate responses. Common causes: unoptimized database queries, missing server-side caching, no CDN for static pages, and cold-start latency on serverless functions.

Check that JS, CSS, images, and fonts return `Cache-Control: public, max-age=31536000, immutable` with content-hashed filenames. Without long cache lifetimes, browsers re-download unchanged files on every visit. Use short cache lifetimes only for HTML documents that change frequently.

Check your CDN's analytics dashboard for cache hit ratio — it should be above 90% for static assets. Low hit rates mean your CDN is re-fetching from the origin server on most requests, negating its purpose. Common causes: `Vary` headers that are too broad, short TTLs, and cache-busting query parameters.

Verify your server or CDN returns `Content-Encoding: br` for HTML, CSS, JavaScript, JSON, and SVG responses. Brotli compression is 15-20% more efficient than gzip. Check by inspecting the `Content-Encoding` response header in DevTools — if you see `gzip` instead of `br`, your compression is suboptimal.

Add `<link rel='preconnect' href='https://...'>` for every third-party domain that loads on the critical path (fonts CDN, API server, analytics). Each new origin requires DNS lookup + TCP + TLS handshake, adding 200-500ms. Preconnect completes this work in parallel with HTML parsing.

Verify fonts use `font-display: swap` or `font-display: optional` so text remains visible during font loading. Fonts with `font-display: block` (the default in many setups) hide all text for up to 3 seconds on slow connections, making the page appear broken.

Use tools like `glyphhanger` or Google Fonts' `text` parameter to create font subsets containing only the character ranges your site needs. A full font file with Latin Extended, Cyrillic, and CJK glyphs can be 200KB+ per weight — subsetting reduces this to 15-30KB.

Check the Coverage tab for CSS files — if less than 20% of a large CSS file is used on the current page, it is wasting bandwidth and blocking rendering. Extract critical CSS for above-the-fold content inline in the `<head>` and load the rest asynchronously with `media='print' onload`.

Use PurgeCSS or your framework's built-in tree-shaking (Tailwind, CSS Modules) to eliminate dead CSS. Check for deeply nested selectors and `!important` overrides that indicate CSS bloat. Unused CSS increases parse time and can slow CSSOM construction, delaying First Contentful Paint.

Download font files and serve them from your own domain or CDN. While Google Fonts is convenient, loading from a separate origin adds a DNS lookup, TCP connection, and TLS handshake. Self-hosted fonts eliminate this latency and give you full control over caching, subsetting, and font-display behavior.