Site Speed Optimization Playbook

Site speed is a confirmed Google ranking factor, a Core Web Vitals requirement, a user experience essential, and a conversion rate multiplier. A 1-second delay in page load time reduces conversions by approximately 7% (Akamai). Pages that load in under 2 seconds have an average bounce rate of 9%, compared to 38% for pages loading in 5 seconds (Google).

This is not a theoretical overview of why speed matters. This is a prioritized playbook of specific optimizations, ordered by typical impact. Start at the top and work down.

Step 1: Diagnose Before You Optimize

Do not start optimizing blindly. Measure first to identify your specific bottlenecks.

Essential Diagnostic Tools

• Google PageSpeed Insights — Provides both lab data (Lighthouse) and field data (Chrome User Experience Report) for any URL. The field data reflects real user experience.
• Chrome DevTools Performance panel — The Network waterfall shows exactly which resources load, when, and how long each takes. This is where you identify the specific bottlenecks.
• WebPageTest.org — Provides detailed waterfall charts, filmstrip views of page loading, and the ability to test from multiple locations and connection speeds.
• Google Search Console Core Web Vitals report — Shows which pages fail CWV thresholds across your entire site, prioritized by page volume.

What to Measure

• Time to First Byte (TTFB) — How long until the server sends the first byte of the HTML response. Target: under 800ms. Problems here indicate server or hosting issues.
• Largest Contentful Paint (LCP) — When the largest visible content element finishes rendering. Target: under 2.5 seconds. This is the most impactful Core Web Vital.
• Interaction to Next Paint (INP) — How quickly the page responds to user interactions. Target: under 200ms. Problems here indicate JavaScript execution issues.
• Cumulative Layout Shift (CLS) — How much the page layout shifts during loading. Target: under 0.1. Problems here indicate missing dimension attributes or dynamically injected content.
• Total Blocking Time (TBT) — How long the main thread is blocked by long tasks. Correlates strongly with INP in field data.

Step 2: Server and Hosting Optimization

Server response time is the foundation. If your server is slow, nothing else you optimize will compensate.

Reduce TTFB

• Upgrade hosting — Shared hosting typically delivers TTFB of 600-2000ms. A quality VPS or managed hosting provider delivers 100-400ms. For high-traffic sites, this single change can be the biggest speed improvement available.
• Enable server-side caching — Cache full page HTML responses so the server does not regenerate pages from scratch on every request. Technologies: Varnish, Nginx FastCGI cache, Redis, or CDN-level caching.
• Optimize database queries — Slow database queries are the most common cause of high TTFB on dynamic sites. Identify and optimize the slowest queries using your database's slow query log.
• Use a CDN — A Content Delivery Network serves your content from servers geographically close to users. Cloudflare, AWS CloudFront, and Fastly reduce TTFB by 50-80% for users far from your origin server.

Enable Compression

Ensure Gzip or Brotli compression is enabled for all text-based resources (HTML, CSS, JavaScript, SVG, JSON). Brotli compression reduces file sizes by an additional 15-25% compared to Gzip. Most modern web servers and CDNs support Brotli.

Step 3: Image Optimization

Images are typically the largest resources on a page and the most common cause of slow LCP scores. Optimizing images often delivers the biggest single improvement in page load time.

Use Modern Formats

Convert images to WebP or AVIF format. WebP delivers 25-35% smaller file sizes than JPEG at equivalent quality. AVIF delivers 40-50% smaller files. Use the <picture> element to serve modern formats with JPEG fallback for older browsers.

Implement Responsive Images

Serve appropriately sized images for each device. A 2000px-wide hero image served to a 375px mobile screen wastes 80%+ of the downloaded data. Use srcset and sizes attributes to let the browser select the optimal image size.

Lazy Load Below-the-Fold Images

Add loading="lazy" to all images that are not visible in the initial viewport. This defers loading until the user scrolls near them, dramatically reducing initial page weight. Critical exception: do NOT lazy load the LCP image (typically the hero image or first major visual). The LCP image should load eagerly.

Set Explicit Dimensions

Always include width and height attributes on <img> tags. This allows the browser to reserve space before the image loads, preventing layout shift (CLS).

Step 4: CSS and JavaScript Optimization

Eliminate Render-Blocking CSS

CSS blocks rendering — the browser cannot display any content until it has downloaded and parsed all CSS linked in the <head>. Reduce this blocking time:

• Inline critical CSS — Extract the CSS needed for above-the-fold content and inline it directly in the HTML <head>. Load the remaining CSS asynchronously.
• Remove unused CSS — Most sites load 60-90% more CSS than any single page uses (due to framework bundles and accumulated styles). Tools like PurgeCSS or Chrome DevTools Coverage tab identify unused CSS.
• Minify CSS — Remove whitespace, comments, and redundant rules. Build tools like cssnano, PostCSS, or esbuild handle this automatically.

Optimize JavaScript Loading

JavaScript blocks the main thread and delays interactivity. Optimize aggressively:

• Defer non-critical JS — Add defer or async attributes to script tags that are not needed for initial render. defer maintains execution order; async does not.
• Code split — Break large JavaScript bundles into smaller chunks loaded on demand. Modern bundlers (Webpack, Vite, esbuild) support automatic code splitting.
• Remove unused JavaScript — Audit your JavaScript bundles with Chrome DevTools Coverage tab. Remove or defer modules that are not used on the current page.
• Minimize third-party scripts — Analytics, chat widgets, A/B testing tools, and ad scripts often consume more resources than your own code. Audit each third-party script's impact and remove or defer those with poor value-to-performance ratios.

Step 5: Font Optimization

Web fonts are a common performance bottleneck that is often overlooked:

• Preconnect to font servers — Add <link rel="preconnect" href="https://fonts.googleapis.com"> to establish the connection early
• Use font-display: swap — Ensures text is visible immediately using a system font, then swaps in the web font when loaded. Prevents invisible text (FOIT).
• Subset fonts — If you only need Latin characters, do not load the full Unicode range. Google Fonts supports subsetting via the text parameter.
• Self-host fonts — For maximum control, download and self-host your fonts. This eliminates the DNS lookup and connection to third-party font servers.
• Limit font variations — Each weight and style is a separate file. Using 4 weights (300, 400, 600, 700) in 2 styles (normal, italic) means 8 font files. Only load the weights and styles you actually use.

Step 6: Advanced Techniques

Resource Hints

• Preload — Use <link rel="preload"> for critical resources discovered late in the loading process (fonts referenced in CSS, hero images, critical JavaScript modules)
• Prefetch — Use <link rel="prefetch"> to load resources for the next likely navigation (e.g., the next page in a multi-step flow)
• DNS-prefetch — Use <link rel="dns-prefetch"> for third-party domains to resolve DNS before resources are requested

HTTP/2 and HTTP/3

Ensure your server supports HTTP/2 (at minimum) or HTTP/3. HTTP/2 enables multiplexing (loading multiple resources over a single connection) and header compression. HTTP/3 adds connection migration and faster handshakes. Most modern hosting providers and CDNs support both.

Service Worker Caching

For repeat visitors, a service worker can cache critical resources locally, enabling near-instant page loads on subsequent visits. This is particularly valuable for PWAs and content-heavy sites with returning audiences.

Step 7: Measuring Impact

After implementing optimizations, measure the impact using the same tools you used for diagnosis:

• Compare before/after Lighthouse scores — Run PageSpeed Insights on the same pages and compare scores
• Monitor field data — CrUX data in PageSpeed Insights and Search Console reflects real user experience. Lab improvements should translate to field improvements within 28 days (the CrUX reporting window).
• Track business metrics — Monitor conversion rates, bounce rates, and pages per session alongside speed improvements. The correlation between speed gains and business metric improvements validates the ROI of optimization work.

Site speed optimization is not a one-time project — it is an ongoing discipline. Every new feature, every added script, every unoptimized image introduces potential regression. Build speed monitoring into your deployment pipeline and your monthly review process.

Related Guides