Slow static assets: why your CSS, JS, and images need a CDN
CSS, JavaScript, fonts, and images often load slower than the HTML itself — and they dominate Largest Contentful Paint. The cheapest fix is serving them from a CDN with long cache headers.
CSS, JavaScript, fonts, and images often load slower than the HTML itself — and they dominate Largest Contentful Paint. The cheapest fix is serving them from a CDN with long cache headers. Static assets are any file served as-is (not generated per request): CSS bundles, JS chunks, images, font files, video posters. They are perfectly cacheable. Performance issues come from missing CDN, no compression, no caching headers, or huge unoptimised bundles.
Last updated·
What it is
Static assets are any file served as-is (not generated per request): CSS bundles, JS chunks, images, font files, video posters. They are perfectly cacheable. Performance issues come from missing CDN, no compression, no caching headers, or huge unoptimised bundles.
Why it matters
LCP and CLS — two of three Core Web Vitals — are directly driven by how fast above-the-fold assets render. Improvements here often move LCP from "Needs Improvement" to "Good" without code changes.
How to fix it
- Serve all static assets from a CDN. Cloudflare, CloudFront, Fastly. Even a free Cloudflare tier in front of your hosting cuts asset latency 50%+ for distant visitors.
- Set Cache-Control: public, max-age=31536000, immutable. For hashed bundle filenames, cache forever. The hash in the filename forces a new fetch on change.
- Enable Brotli or gzip compression. Brotli compresses text-based assets 15–20% better than gzip. Both should be on at the CDN edge.
- Audit bundle size. A 1MB+ JS bundle on initial load is a red flag. Code-split routes, lazy-load below-fold components, tree-shake unused imports.
Authoritative sources
- Google Search Central documentation — Google
- Schema.org vocabulary — schema.org
- SEO Starter Guide — Google Search Central
- MDN — HTML meta and link elements — Mozilla MDN