HTTP Cache and TTL: how it works, strategies and SEO impact

HTTP caching and TTL (Time To Live) are two fundamental concepts in web performance. Caching allows resources (images, CSS, JavaScript) to be stored temporarily close to the user, avoiding the need to re-download them on every visit. TTL defines how long a resource can remain in that cache before being considered stale. When properly configured, these mechanisms dramatically reduce page load times, relieve the origin server, and improve Core Web Vitals — with a direct impact on SEO.

What is HTTP caching?

HTTP caching is a mechanism that allows different components of a web page's delivery chain to keep a local copy of downloaded resources. When a browser loads a page for the first time, it downloads each resource from the server. If those resources are accompanied by HTTP headers indicating they can be cached, the browser (and/or CDN) keeps a copy. On subsequent visits, the resource is served from that local cache rather than re-downloaded from the server — which is dramatically faster.

There are several caching layers in a web resource delivery chain. The browser cache stores resources directly on the user's device — on their hard drive or in memory. The CDN cache (also called the edge cache) stores resources on content delivery network servers that are geographically close to users. The server-side cache (reverse proxy cache, such as Varnish or Nginx) stores resources at the hosting level, before they even reach the network.

Cache-Control headers: how to define caching behaviour

The HTTP Cache-Control header is the primary mechanism by which a server communicates its caching instructions. It is sent with every HTTP response and can contain several combined directives. Here are the most important ones:

• max-age=N: the resource can be cached for N seconds. Example: max-age=31536000 = 1 year. The most commonly used directive for static resources.
• s-maxage=N: like max-age, but applies only to shared caches (CDN, reverse proxies), not to the browser cache. Allows different policies for CDN and browser.
• no-cache: the resource may be cached, but the cache must always verify with the server whether it is still valid before serving it (via ETag or Last-Modified).
• no-store: the resource must never be cached, anywhere. Use only for highly sensitive content (personal data, transactions).
• public: the resource can be cached by any cache, including shared CDN caches.
• private: the resource can only be cached by the user's browser, not by intermediate caches.
• immutable: indicates that the resource will never change during its lifetime (max-age). The browser will not send a validation request even at expiry.

For static images on an e-commerce store, the optimal directive is generally: Cache-Control: public, max-age=31536000, immutable. This combination indicates that the image can be publicly cached for one year and will not change. If the image changes (new product photo), the URL must change to bypass the cache — a technique known as "cache busting" via URL versioning.

TTL (Time To Live): how long should a resource stay in cache?

TTL (Time To Live) is the duration for which a cached resource is considered fresh and can be served directly without checking with the origin server. It is expressed in seconds in the max-age header. Once this time has passed, the resource is considered stale — it may still be served in certain cases, but the cache should ideally revalidate it.

Choosing a TTL is a balance between two conflicting objectives: maximising cache utilisation (long TTL = fewer requests to the server) and ensuring users receive up-to-date content (short TTL = changes propagate quickly). For resources that rarely change, such as product images, a long TTL (1 year) is optimal. For frequently changing resources, such as prices or stock levels, a short or zero TTL is necessary.

• 1 year (31,536,000 seconds): product images, versioned CSS/JS, web fonts — stable resources with URL versioning
• 1 month (2,592,000 seconds): brand or category images updated occasionally
• 1 hour to 1 day: semi-dynamic content, category pages, product listings
• 0 or no-store: cart pages, checkout pages, logged-in user data — never cache

Cache invalidation: how to handle content changes

Long-term caching raises an obvious question: what happens when content changes? If an image is cached for 1 year but you update it after 2 months, visitors will continue to see the old version for 10 months. This is where cache invalidation strategies come in.

The most reliable strategy is URL versioning (also called cache busting). The principle: the resource URL includes a unique identifier that changes every time the resource changes. For example, /images/product-shoe-v2.webp instead of /images/product-shoe.webp. Or via a query parameter: /images/product.jpg?v=1705234567. When the image changes, the URL changes, and the cache treats this new URL as an entirely new resource — with no stale content problem.

Another strategy is the CDN purge API: modern CDNs expose an API that allows you to immediately invalidate specific URLs or groups of URLs in their cache. When a merchant updates an image in their back office, an API call to the CDN invalidates the cache for that image. Subsequent visits retrieve the new version directly from the origin server, which is then re-cached.

CDN cache vs browser cache: complementarity and differences

The CDN cache and the browser cache are complementary and serve different purposes. The CDN cache benefits all visitors, new and returning: an image cached on a London CDN node is served quickly to any visitor in the UK, whether or not they have previously visited your store. The browser cache benefits only returning visitors, on their own device: if a user has already downloaded the image during a previous visit, their browser serves it from local disk without any network request.

In practice, both caching layers complement each other: the CDN cache reduces latency for the first page load (new visitor or expired browser cache), while the browser cache completely eliminates the network for repeat visits on the same device. A resource with max-age=31536000 will only require a network request once per year per device — a very significant performance gain for loyal visitors.

ETag and Last-Modified: conditional cache validation

Even with an expired TTL, the browser is not forced to re-download a resource from scratch. It can send a conditional request to check whether the resource has changed: if it has not, the server responds with an HTTP 304 (Not Modified) status with no response body — saving bandwidth while confirming the freshness of the cached resource.

The ETag (Entity Tag) is a unique identifier generated by the server for a specific version of a resource — typically a hash of the file's content. When the browser makes a conditional request, it sends the ETag of its cached version in the If-None-Match header. If the server has the same ETag (the resource has not changed), it responds with 304; otherwise, it sends the new version with a new ETag.

The Last-Modified header works in a similar way: the server indicates the date the resource was last modified, and the browser sends it in If-Modified-Since on conditional requests. These validation mechanisms keep the cache up to date without wasting bandwidth when content has not changed.

How Lexiik manages caching and invalidation automatically

Lexiik implements an optimal caching strategy for PrestaShop store images, automatically resolving the invalidation problem that normally makes long-term caching risky. Every image uploaded to Cloudflare R2 receives Cache-Control: public, max-age=31536000, immutable headers — one year of caching across all Cloudflare edge nodes and in visitors' browsers.

The invalidation challenge is handled automatically by Lexiik through two mechanisms. First, URL versioning: images served by Lexiik CDN use identifiers in their URLs that change automatically when the image is updated in the PrestaShop back office. Second, automatic Cloudflare purge API calls: when an image changes, Lexiik sends a purge request to Cloudflare to immediately invalidate the CDN cache for that specific image, without affecting other images. Visitors receive the new image on their next visit, without ever seeing a stale version.

Why long-term caching improves SEO

A one-year TTL on product images improves SEO through several direct and indirect mechanisms. Directly, images loaded from cache (CDN or browser) appear in tens or hundreds of milliseconds, compared to several seconds for a full network download. This improves LCP — the Core Web Vital metric most closely linked to images — and can move a page from a "Poor" to a "Good" score according to Google's thresholds.

Indirectly, effective caching reduces the number of HTTP requests sent to your origin server. Less server load = better TTFB (Time To First Byte) for the dynamic HTML content that your PrestaShop generates. A TTFB below 200 ms is recommended by Google; a server overwhelmed with image requests can have a degraded TTFB that affects all performance metrics.

Finally, for returning visitors — who are often the most likely to convert — a well-configured browser cache creates a near-instant browsing experience. Product pages appear to load instantly, with images already in memory. This smooths the purchase funnel and reduces abandonment, with a positive impact on behavioural metrics that Google may take into account.

• Improved LCP: images loaded from local cache or CDN in milliseconds
• Improved TTFB: fewer requests to the origin server = less server load = HTML delivered faster
• Better PageSpeed score: Google Lighthouse penalises the absence of a long-term cache policy
• Bandwidth savings: less data transferred = lower costs and better performance on mobile
• Improved returning visitor experience: near-instant navigation for repeat customers