Page speed is a direct Google ranking factor. Sites that load in under 2.5 seconds see 24% lower bounce rates compared to those loading in 4+ seconds. Google confirmed page experience signals influence rankings, and speed is the most measurable component of that equation.
How Google Measures Page Speed
Google evaluates speed through three Core Web Vitals collected from real Chrome users (CrUX data):
- LCP (Largest Contentful Paint): Good under 2.5s, poor above 4.0s
- INP (Interaction to Next Paint): Good under 200ms, poor above 500ms
- CLS (Cumulative Layout Shift): Good under 0.1, poor above 0.25
These thresholds apply at the 75th percentile of page loads, meaning 75% of your visitors must meet the threshold for a "good" assessment.
Diagnosing Speed Issues
Run a Lighthouse audit in Chrome DevTools (Ctrl+Shift+I, then the Lighthouse tab) to get a lab-based performance score. Complement this with field data from Google Search Console's Core Web Vitals report.
Key Diagnostic Tools
- PageSpeed Insights -- combines lab (Lighthouse) and field (CrUX) data for any URL
- Chrome DevTools Performance tab -- flame charts showing exactly where time is spent
- WebPageTest.org -- waterfall analysis from multiple global locations
- Search Console Core Web Vitals report -- aggregated field data across your entire site
Critical Rendering Path Optimization
The critical rendering path determines how quickly the browser can render the first meaningful pixels. Optimize it in this order:
- Minimize render-blocking resources. Move non-critical CSS and JS below the fold or load them asynchronously using
asyncordeferattributes. - Inline critical CSS. Extract above-the-fold styles and embed them directly in the HTML
<head>. Tools likecritical(npm) automate this. - Compress and minify everything. Enable Gzip or Brotli compression at the server level. Brotli typically achieves 15-20% better compression than Gzip.
<!-- Defer non-critical JavaScript -->
<script src="/analytics.js" defer></script>
<!-- Preload critical resources -->
<link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>
Server and Caching Configuration
HTTP Caching Headers
Set aggressive cache lifetimes for static assets. Use content-hashed filenames so you can cache indefinitely without stale content:
# Static assets with hashed filenames
Cache-Control: public, max-age=31536000, immutable
# HTML pages
Cache-Control: public, max-age=3600, must-revalidate
CDN Setup
A CDN reduces Time to First Byte (TTFB) by serving content from edge locations close to your users. Cloudflare, Fastly, and AWS CloudFront are the most common choices. Target TTFB under 200ms for the 75th percentile of requests.
Quick Wins Checklist
- Enable Brotli compression on your web server or CDN
- Set
Cache-Controlheaders for all static assets (images, CSS, JS, fonts) - Add
loading="lazy"to all images below the fold - Serve images in WebP or AVIF format instead of PNG/JPEG
- Remove unused CSS and JavaScript (use Chrome DevTools Coverage tab to identify dead code)
- Preconnect to required third-party origins with
<link rel="preconnect"> - Reduce the number of third-party scripts -- each one adds DNS lookup, TCP, and TLS overhead
Monitoring Speed Over Time
Automated Lighthouse CI in your deployment pipeline catches regressions before they reach production. Set performance budgets that fail the build if LCP exceeds 2.5s or total JavaScript exceeds 300KB compressed.
Track your CrUX data monthly in Search Console. A sudden drop in the "good URLs" percentage often correlates with a recent deploy that added heavy resources or broke caching.