Caching and Delivery for Casino Websites

At a glance

Time to first byte is the first part of LCP, and web.dev's guideline gives it about 40% of the total.
Version static files and cache them for a long time; the immutable extension (RFC 8246) removes revalidation.
Never use the unload event if you want pages restored from the back/forward cache.
Speculation rules can prerender likely next pages in Chromium browsers; use them sparingly.

Cache the shell, personalize the parts

A logged-in lobby often looks uncacheable because of the balance, recommendations and recently played games. Usually only those parts are personal. Serve the HTML shell and the default game grid from a cache or CDN, then load personal modules into reserved slots after the first paint. That keeps time to first byte low, which is the first of the four LCP parts.

Cache keys for markets and languages

Casino operators often serve different content by market, such as the UK, a US state, Ontario or Australia, because products, licensing notices and safer gambling messages differ. The cache must keep those variants apart. Common approaches:

Ways to separate market variants in a cache
Approach	Effect on caching	Watch for
Separate URL per market (path or host)	Simple; each URL caches on its own	Redirects from a generic URL add a round trip
Vary on a market cookie	Works if the CDN keys on that cookie only	Keying on all cookies destroys the hit rate
Edge decides the market from location	No redirect needed	Must match the licensing rules for each market

Whatever the method, make sure a visitor never receives another market's content from the cache. That is a compliance issue before it is a performance one.

Headers for static files

Give CSS, JavaScript, fonts and images a version in the file name or query string, then cache them for a long time. RFC 8246 defines the immutable extension, which "indicates that the origin server will not update the representation of that resource during the freshness lifetime", so browsers need not revalidate it. This site uses Cache-Control: public, max-age=31536000, immutable for versioned CSS and scripts and for the site font, and no-cache for HTML so updates appear at once.

Compress text responses (HTML, CSS, JavaScript, JSON, SVG). Images and video are already compressed and gain little.

Back/forward cache

web.dev describes the back/forward cache as a browser optimization "that enables instant back and forward navigation". On casino sites, players move back and forth between lobby and game pages often, so eligibility pays off. web.dev's guidance:

"Never use the unload event"; use pagehide instead.
Pages with Cache-Control: no-store may not be eligible. For changing but non-sensitive pages, it suggests no-cache or max-age=0.
Test in Chrome DevTools under Application, Back-forward Cache, Run Test.

Pages with sensitive data, such as the cashier and account pages, may rightly use no-store. Keep that to the pages that need it.

Prefetching and prerendering

Chrome's documentation explains that sites "can use the Speculation Rules API, to programmatically tell Chrome which pages to prerender", or to prefetch them. Eagerness settings range from conservative (on pointer or touch down) to immediate. Firefox does not support speculation rules and Safari has them behind a flag, so treat them as an enhancement. Chrome also warns that prerendering can affect analytics and can run scripts before the visitor sees the page, so delay tracking and side effects until activation. On casino sites, a moderate rule for the most likely next page, such as a game from the lobby, is a reasonable start; never prerender the cashier.

What we did not test. We have not reviewed any operator's CDN or headers. The headers quoted are the ones this site sends.

Questions

Should HTML be cached at the CDN?

The logged-out shell usually can be, for a short time, keyed by market and language. Personal parts should load separately.

Does immutable work in every browser?

Browsers that do not support it ignore it, as RFC 9111 requires for unrecognized cache directives, so long max-age values still apply. Versioned file names make it safe either way.

Is prerendering safe for pages with bonuses or balances?

Only if nothing changes state until the page is shown. Chrome suggests checking document.prerendering and waiting for activation before side effects.

Sources

IETF, RFC 8246: HTTP Immutable Responses, September 2017.
IETF, RFC 9111: HTTP Caching, section 5.2.3, June 2022.
web.dev, Back/forward cache, last updated October 16, 2026.
Chrome for Developers, Prerender pages in Chrome for instant page navigations, last updated January 23, 2026.
web.dev, Optimize Largest Contentful Paint, last updated March 31, 2025.