CSS Caching Test
What is it?
Browser caching of stylesheets is one of the highest-leverage wins for return-visitor performance, because CSS is render-blocking by default. With the right caching directives, a cached stylesheet on a return visit means the browser can render the page without waiting for any network round trip. This test checks whether the external CSS files served with your page include the caching headers that allow browsers to store and reuse them, and flags any responses that miss out on browser caching while you still ship updates through versioned filenames.
Why CSS caching matters
Stylesheets are typically smaller than JavaScript bundles but no less important to cache. They block rendering until they are downloaded and parsed, so a cached stylesheet on a return visit means the browser can render the page without waiting for any network round trip. On a content-heavy site, this is one of the most noticeable perceived-speed wins for returning visitors.
The right configuration is the same as for JavaScript: long cache lifetimes paired with versioned filenames so you can update the stylesheet by emitting a new hashed name. With Cache-Control: public, max-age=31536000, immutable on a hashed CSS file, the browser caches it indefinitely and never even checks for updates until you ship a new version, at which point the new URL is fetched fresh.
Common caching gaps
- No
Cache-Controlheader, leading to needless revalidation on every page load. - Short max-age on versioned files where a year would be appropriate.
- Stylesheets behind authentication that cannot use
publiccaching; move shared styles to a public path. - Inline CSS where external would be cacheable; inline only the truly critical above-the-fold styles.
This test reports the caching headers on your page's stylesheets and flags responses that miss out on browser caching. The fix guide below covers configuring cache headers on the major web servers and CDNs, the role of build-time versioning, and the trade-offs between inline critical CSS and externally cacheable full stylesheets.
Pass rate:
-
Top 100 websites: 98%This value indicates the percent of top 100 most visited websites in the US that pass this test (in the past 12 months).
-
All websites: 84%This value indicates the percent of all websites analyzed in SEO Site Checkup (500,000+) in the past 12 months.
| 2021 | 98% |
|---|---|
| 2022 | 98% |
| 2023 | 96% |
| 2024 | 98% |
100
75
50
25
0
How do I fix it?
This test fails when external CSS files are served without caching headers that allow browsers to store and reuse them. Cached stylesheets skip the network on repeat visits, reducing load time for returning users while still allowing updates through versioned filenames. Fixing this issue is a server or CDN configuration change.
Where to make the change
- Server configuration: add
Cache-Control: public, max-age=31536000, immutableto CSS responses, paired with versioned filenames. - CDN configuration: set a default cache rule for
*.cssassets at the edge. - Build pipeline: emit hashed filenames so cache lifetimes can be long without risking stale styles.
- WordPress and plugins: caching plugins handle CSS cache headers automatically.
Common causes and how to resolve them
- No
Cache-Controlheader: add one. Without it, browsers revalidate on every page load. - Short max-age: bump to a year for versioned files; keep it shorter only for unversioned files that may change in place.
- Stylesheets behind authentication: private styles cannot use
publiccaching. Move shared styles to a public path.
Best practices
- Versioned filenames: hashed names plus
immutablecaching is the gold standard. - Inline critical CSS: the styles needed for above-the-fold rendering can be inlined while the rest is cached and loaded asynchronously.
- Audit with DevTools: confirm that on repeat visits, the stylesheet is served from disk cache rather than the network.
