Page speed is no longer a "nice-to-have": Google ranks it, users abandon slow sites within 3 seconds, and Core Web Vitals (LCP, INP, CLS) are now hard signals. Here's how to actually move the numbers, not just talk about them.
Contents
- Hit the Core Web Vitals targets
- Compress and convert images
- Enable Brotli (or GZIP)
- Minify and tree-shake your code
- Cache aggressively
- Reduce HTTP requests
- Use a global CDN
- Prioritize critical resources
- Measure with the right tools
- Wrap-up
Hit the Core Web Vitals targets
Three numbers matter for ranking:
- LCP (Largest Contentful Paint), under 2.5s
- INP (Interaction to Next Paint), under 200ms
- CLS (Cumulative Layout Shift), under 0.1
If you're not measuring these, you're flying blind. Everything below moves at least one of them.
Compress and convert images
Images usually account for 50–70% of total page weight. Two wins:
- Modern formats. AVIF cuts file size by ~50% vs JPEG at the same quality. WebP is ~30% smaller. Both are supported in every modern browser.
- Right-size them. Don't ship a 4000px image to a 400px container. Use
srcsetandsizes, or an image CDN that resizes on the fly (Cloudflare Images, imgix, Vercel Image).
Lazy-load anything below the fold (loading="lazy"). It can cut initial LCP by 30–40%.
Enable Brotli (or GZIP)
Brotli compresses text assets ~20% better than GZIP. Most modern hosts (Cloudflare, Vercel, Netlify) enable it by default. If you're on legacy Apache/nginx, turn it on. It's a one-line config change for free bandwidth savings.
Minify and tree-shake your code
- Strip whitespace and comments from HTML, CSS, and JS (esbuild, terser, swc).
- Tree-shake unused exports: modern bundlers (Vite, Rollup, esbuild) do this automatically when imports are static.
- Audit your JS bundle. A blog rarely needs 500KB of React. Question every dependency.
Cache aggressively
Set long Cache-Control headers (max-age=31536000, immutable) on hashed assets: CSS, JS, fonts, images. The browser stores them once and never re-downloads on repeat visits.
For HTML, use shorter TTLs (max-age=300, s-maxage=3600) plus stale-while-revalidate so users see instant pages while the cache refreshes in the background.
Reduce HTTP requests
Each request adds connection overhead, especially on mobile networks. Practical wins:
- Bundle small CSS/JS files (HTTP/2 reduces this concern but doesn't eliminate it).
- Inline critical CSS into the HTML head.
- Self-host fonts instead of pulling from Google Fonts (saves a DNS lookup + connection).
- Subset fonts to only the characters you use.
Use a global CDN
A CDN serves your assets from a server geographically close to each user. Cloudflare and Vercel Edge cache static assets in 200+ locations worldwide, round-trip time drops from 200ms (cross-continent) to 20ms (same city).
Even better: push your HTML to the edge with edge functions or static pre-rendering. That's the difference between a 50ms TTFB and a 800ms one.
Prioritize critical resources
The browser renders top-down. Help it:
<link rel="preload">for fonts and hero images.deferorasyncnon-critical scripts so they don't block parsing.- Move third-party scripts (analytics, chat widgets) to the end of
<body>or load them after user interaction. - Use
fetchpriority="high"on your LCP image.
Measure with the right tools
- PageSpeed Insights: Google's official Core Web Vitals score (uses real-user data from Chrome).
- Lighthouse: built into Chrome DevTools, runs synthetic audits.
- WebPageTest: deepest waterfall analysis, multi-location testing.
- Search Console → Core Web Vitals report: your actual ranking signal, based on field data.
Run all four. Lab data (Lighthouse) and field data (CrUX) often disagree, both matter.
Wrap-up
Site speed is engineering hygiene, not magic. Hit Core Web Vitals targets, ship modern image formats, enable Brotli, minify code, cache hard, use a CDN, and measure with real tools. Most sites can shave 50% off load time in a single afternoon if someone actually does the work.
Site too slow? Get my free website audit. I'll show you exactly what's killing performance.
