Browser cache: is your HTML page forcing a reload every time?

Without proper cache headers, the browser re-downloads the entire page on every visit. Test #02 checks your cache policy in seconds.

Your visitor loads a page. They click a link, then come back. Without cache headers, the browser downloads the entire HTML again — same content, same weight, same wait time. Every single time.

Browser caching for HTML pages is one of the most overlooked performance settings. Everyone caches images and CSS, but the HTML document itself? Most WordPress sites don't have a proper cache policy for it.

Test #02 in Orilyt inspects the cache headers of the HTML response. Not the assets, not the images — the main document. It checks Cache-Control, Expires, ETags, and Last-Modified in one pass. The result tells you whether returning visitors get a fast experience or a redundant download.

How browser caching works for HTML

When a server sends an HTML page, it can include headers that tell the browser how to cache it. The key players:

1. Cache-Control: max-age=N — tells the browser to keep this page for N seconds without asking the server again. A max-age of 600 means 10 minutes of local cache
2. Cache-Control: s-maxage=N — same as max-age, but for shared caches (CDNs, proxies). Takes priority over max-age when present
3. Expires — an older header that sets an absolute date/time for expiration. Works as a fallback when Cache-Control is absent
4. ETag and Last-Modified — validators that enable conditional requests. Instead of re-downloading, the browser asks "has this changed since X?" — if not, the server returns a 304 Not Modified (zero body)

Cache-Control: no-store means the browser must never cache the page. Cache-Control: no-cache means the browser can cache it but must revalidate every time. Both result in a request to the server on every visit.

For HTML pages that change infrequently (most WordPress content), a max-age of 300–3600 seconds combined with ETags is the sweet spot. The page loads instantly from cache, and the next revalidation is lightweight.

How Orilyt scores your cache policy

Test #02 reads the response headers and evaluates the caching policy:

1. Score 90 — Cacheable with a TTL over 300 seconds. The browser can serve the page from its local cache for at least 5 minutes. Best result
2. Score 70 — Cacheable but the TTL is short or missing. The page has cache headers but the freshness window is too brief to be useful
3. Score 30 — Not cacheable or no cache headers detected. The browser downloads the full page on every visit. This is the default for most unconfigured sites

The test also detects validator presence (ETag, Last-Modified), whether the page is marked private, and whether Set-Cookie headers interfere with caching.

Why HTML caching is often missing

HTML cache is less common than asset caching because of a fundamental tension: pages can change. But there are smarter solutions than no caching at all:

1. WordPress defaults — WordPress doesn't set Cache-Control headers by default. The server (Apache, Nginx) has to be configured separately, and most hosting panels don't do it
2. Dynamic pages with Set-Cookie — if the response includes Set-Cookie, many CDNs and proxies skip caching. Login pages, WooCommerce carts, and personalized content all trigger this
3. no-store everywhere — some security plugins or poorly configured caching plugins set no-store on every page, including static content that should be cached
4. Missing ETag/Last-Modified — without validators, the browser can't do conditional requests. It either uses the cached version blindly or downloads the full page. Most miss this

The key insight: for 90% of WordPress pages (blog posts, service pages, landing pages), a moderate max-age (300–600s) with ETag revalidation is safe and effective. The browser gets a fast cache hit, and changes propagate within minutes.

Cache policy as a selling point

For freelancers and agencies, a missing cache policy is a strong audit finding. It affects every returning visitor — and returning visitors are your most valuable traffic.

In the Orilyt report, test #02 generates a structured FIA recommendation:

1. Fact: "No Cache-Control or Expires header on the HTML document. No caching policy detected"
2. Impact: "Every visit triggers a full page download, even for returning visitors. This wastes bandwidth and adds load time"
3. Action: "Add Cache-Control: public, max-age=600 to HTML responses. Add ETag validation for smart revalidation"

A score of 30/100 on cache policy signals a site that hasn't been optimized beyond the basics. It's the kind of detail that separates a professional audit from a generic "your site is slow" report.

Make returning visits instant

Browser caching for HTML is not about aggressive caching or staleness risks. It's about telling the browser: "you can keep this for a few minutes, and here's how to check if it changed."

Test #02 checks this in one pass. No manual header inspection, no terminal commands — just a score (90, 70, or 30) with a clear explanation and actionable fix.

If you're auditing client sites, cache policy is one of those findings that's invisible to the naked eye but measurable in data. It's the kind of improvement that makes a real difference — and costs almost nothing to implement.