The Role of Cache in eCommerce SEO

Online customers crave quick and smooth e-commerce websites. From browsing product catalogues to completing quick checkouts, a seamless experience is essential. One of the key technologies making this possible is caching.

In this blog post, I’ll explain how caching works, why it’s crucial for e-commerce performance, and how it can impact SEO.

What is Caching and Why Does it Matter?

Caching is a technique used to make websites and applications run more efficiently by temporarily storing data in an easily accessible location. Instead of retrieving information from the original source every time, caching saves frequently used data so it’s available when needed.

To understand how caching works, imagine it as a special storage box in your browser. When you visit a website for the first time, images, styles, and scripts are stored directly in this box. The next time you visit, the browser retrieves these resources from the cache, avoiding downloading them again and saving unnecessary effort, time, and data.

Onto some food for thought right away.

Assume a lot of visits come from returning visitors, it means our imaginary caching strategy is working well. However, that could mean that users are often returning to the same page.

Is this what the business wants to achieve?

Bear in mind that if a good caching strategy is important, likewise you should understand beforehand why users are revisiting the same pages so often.

Benefits of Caching

A cached visit only happens when a user returns to the same URL.

A strategic implementation can help you prevent red flags in how users and search engines navigate your eCommerce site.

💡Tip – Not all webpages have cached versions due to:
– Newly created, uncrawled pages.
– Sensitive content not cached by Googlebot’s choice.
– Google unable to render the page with complex CSR

What you Should (and Should Not) Cache

When it comes to eCommerce, there are a few key resources you should cache to flex page speed performance.

• Product Listings: Caching product pages or popular listing pages ensures they load quickly, improving the browsing experience. For instance, a list of sneakers might only update once a day but could be viewed thousands of times per hour.
• User Sessions: Caching active carts ensures customers won’t have to wait for their cart data to load when they come back to the site. User preferences and browsing histories can be cached as well.
• Static Assets: Items like images, CSS files, and JavaScript can be cached to avoid repeated downloads and reduce server load.

On an eCommerce website, the goal is usually to cache as many resources as possible within a specific time range.

You could argue that creating a caching strategy here is easier compared to a publisher sites, as there are fewer assets to exclude from caching such as sensitive information concealed behind login, wishlist or cart pages.

Topping up Cache Resources by Priority

JavaScript is becoming more complex and widely used, making it a top priority candidate to secure on HTTP browser cache.

After speaking with Page Speed Analyst Sander van Surksum, I learned that JavaScript now plays such a crucial role in the user experience of many websites that, without it, many would fail to function properly.

This makes caching JavaScript especially important.

According to the HTTP archive, mobile sites load around 902.1 KB of images and 586.3 KB of JavaScript on average. Without proper caching, users must reload these large files repeatedly, slowing down performance and harming user experience.

While caching images is important, JavaScript deserves indeed special attention as it often initiates the process of images retrieval, especially on many B2C eCommerce websites.

While you should probably play by the book and trigger images from the HTML, using JavaScript is more straightforward, easier to set up and it’s a good fit for a caching strategy already up and running.

I will touch more on this later, first some more context around cache.

Where Does Caching Occur?

There are several types of caching, each with different advantages depending on the use case.

In-Memory Caching

In-memory caching stores data in RAM (Random Access Memory), making it incredibly fast. It’s often used for high-demand data, such as product information, because it reduces the need to query the database. However, this type of cache is temporary—if the system shuts down, the cached data is lost.

Example: A jewellery store’s website uses in-memory caching to store product details like prices and images. This ensures that when a user requests the product page, the server retrieves it from memory rather than querying the database.

Distributed Caching (CDN)

Distributed caching spreads cached data across multiple servers or nodes, allowing for better scalability and reliability. This approach helps handle high traffic loads and ensures that even if one server fails, the cache remains available across other servers.

Example: A global e-commerce website uses distributed caching to store product information on servers in different regions. This way, customers from various locations experience faster load times by accessing the cache from the nearest server.

Client-Side Caching

Client-side caching stores data on the user’s device, such as a web browser, reducing the need to fetch static resources repeatedly. The browser’s HTTP Cache may not be the most powerful approach as you have limited control over the lifetime of cached responses, but it’s effective and it doesn’t require much work.

Example: A web browser caches images from an online store, so when a user revisits the website, the images load instantly from the local cache rather than being downloaded from the server again.

Here’s a breakdown of the cache types alongside potential use cases.

Cache Type	Description	Use Case
In-memory caching	Stores frequently accessed data, such as product information, in the server’s RAM for quick retrieval.	The server checks the cache for product details (e.g., price, description, image) before querying the database, speeding up response times.
Distributed caching	Data is distributed across multiple servers, improving scalability and availability by synchronizing cache across nodes.	Used to handle growing traffic by ensuring multiple servers have access to the same cached product data.
Client-side caching	Caches static resources (e.g., CSS, JavaScript, images) in the user’s browser to reduce load times for returning users.	Speeds up page loading for repeat visitors by allowing their browser to retrieve resources locally instead of downloading again.

Understanding HTTP Caching

The HTTP cache plays a crucial role in determining how long resources are cached and when they should be refreshed.

In this context, the caching behaviour is influenced by a mix of HTTP request and response headers.

For most eCommerce sites, the browser automatically handles HTTP caching without much effort when making requests. However, things get more complex with HTTP response headers, where several headers can influence the caching behaviour.

Cache-Control

The Cache-Control header instructs the browser on how long to cache a resource and when to check for updates.

Here are some common directives.

Cache Directive	Description
public	Allows the resource to be cached by both browsers and shared caches (like proxy servers), making it accessible to multiple users.
private	Restricts caching to the end user’s browser only, ensuring the resource isn’t shared across users or systems.
no-cache	Instructs the browser to check with the server before using the cached resource, ensuring that the user always sees up-to-date content. Ideal for pages where freshness is important, such as a news homepage.
no-store	Prevents the browser from caching the resource at all. This is essential for sensitive pages, such as login or transaction pages, as it ensures that no personal or sensitive data is stored in the cache.
max-age	Defines how long a resource can be cached before it expires. For example, if your product images rarely change, setting a longer max-age ensures the browser can cache them for an extended period without revalidating with the server.

💡Tip – Avoid small max-age for your product images.

Imagine you cache:

• Images for 120 seconds
• JavaScript and CSS for 2519358 seconds
• Web fonts for 14400 seconds

This approach might work well in pre-production or staging environments. However, when the site goes live, it can overwhelm the caching system due to the vast differences in caching times for each type of asset. This leads to an excess of instructions for the cache system, causing it to struggle with resource management.

I recommend you take a look at Jake Archibald’s cache guide, which delves deep into the side effects of using small max-age values.

Aside from the techies, it can be highly counterintuitive to cache your product images for just 120 seconds, even for temporary product lines or seasonal collections.

Consider this example of an eCommerce PLP category page.

Images are left in the browser’s cache for only 2 minutes before server revalidation. As a returning visitor, you’re unaware that you have just 2 minutes to browse the entire catalogue before the page load plunges into a dismayal loading time.

What if you were clicking back and forth through filters or exploring a PDP and then back-forward to the main PLP?

Considering that some eCommerce PLP have 15 rows of items taking over 1 minute to fully load, with images cached for just about 120 seconds any page load request you send after 2 minutes will cost you at least more than 1 minute.

And that’s just to resume your on-page navigation!

ETag

ETags are tokens that the server uses to check if a cached file has changed. When the browser’s cached copy of a resource expires, it sends the ETag to the server.

If the server’s ETag matches the one sent by the browser, the file hasn’t changed and can be reused, saving bandwidth and improving load times.

Last-Modified

Similar to ETag, the Last-Modified header uses a time-based strategy to verify whether a resource has changed.

When a cached resource expires, the browser checks the timestamp of the last modification. If the file hasn’t changed since the last request, it won’t need to be re-downloaded.

What’s the difference with ETag then? None.

ETag is meant to be more accurate because it’s presented as a token whereas Last-Modified is a simple HTTP header. I recommend basing your caching system on ETag.

Caching Strategies for eCommerce SEO

Caching plays a crucial role in boosting SEO performance. Search engines prioritize fast-loading websites, and caching can significantly reduce page load times by decreasing Time to First Byte (TTFB) and improving Core Web Vitals, both of which directly impact your site’s ranking.

💡 Tip – Discover how to automate Core Web Vitals analysis with Python in this blog post.

I find the following conceptual map from web.dev is instrumental to educate your caching strategy

A good strategy branches out into several tactics that are closely connected to the core of the main strategy.

Here’s a case study that showcases various options you could strategically apply to your eCommerce business.

Caching and Image Retrieval – Case Study

Patrizia Pepe is an Italian fashion eCommerce brand offering a wide range of clothing, accessories, and footwear for modern, fashion-forward individuals.

Upon first page load from a new visitor, this PLP page takes around 30 seconds to fully populate the DOM.

Upon the second page load request, returning visitors would have the page fully returned in half the time (15.87 s)

While the first loading request takes about 30 seconds, a caching strategy allows returning visitors to halve the loading time to around 15 seconds.

Below, we isolate the individual factors that conflate into an efficient caching and resource retrieval strategy.

Image Size

Images are 15-50 kB in size with different compressions by image types (WebP and JPEG).

Now, the image size is a common issue that often causes marketing managers to jump on the bandwagon and push for immediate optimisations, perhaps at the expense of other priorities.

I’m not sure why, perhaps because third-party tools frequently flag it during audits and it’s a relatively easy fix except it’s just one piece of the puzzle.

From a technical perspective, I’ve seen eCommerce websites with decent TTFB (Time to First Byte) using images that don’t exceed 50 kB in size (refer to the screenshot above).

💡Tip – Discover 9 image optimisation hacks for your eCommerce store

CDN Images and HTTP headers

Product images are located on the CDN, compressed in WebP format. The browser requests these images via JavaScript files with the defer attribute preventing the main thread from blocking.
There are dedicated cache-control directives in place, telling the browser that:

• Resources shouldn’t be stored in shared caches but only in the browser’s (private)
• The cache can’t alter or transform resources during caching (no-transform)
• Cached resources will never change (immutable)
• Cached resources will be available to the browser for up to one year (max-age=31536000) without server revalidation.

Stock images and HTTP headers

SVG images(e.g., logo, buttons) hosted on the Salesforce back-end, not optimized for compression format (jpeg). The browser requests these images directly from the HTML document.

Again, there are dedicated cache-control directives in place, telling the browser that:

• Resources can be stored in shared caches that are not the browser’s (public)
• Cached resources will be available to the browser for up to one month(e.g. max-age=2592000) without server revalidation.

What’s the common thread in the caching strategy adopted by these image formats?

All image types are stored on the hard disk, a cheap option and a good fit given eCommerce stores normally retain a large amount of data, including static resources (e.g. images, JavaScript and CSS).

Cache Type	Description
Disk Cache	– Slower compared to memory cache, with higher I/O latency. – Persistent, meaning data survives system restarts. – Can store large amounts of data because disk space is generally bigger. – Best for static resources like images, CSS, or JavaScript files that don’t change often.
Memory Cache	– Faster than disk because stored in RAM. – Volatile, meaning data is lost when the system restarts. – Provides very fast access and lower latency. – Limited by the amount of available RAM, making it best for frequently accessed or temporary data. – Best for dynamic content, like query results or session data that need fast retrieval.

Server Request Management

Here’s the core of the caching strategy, or where the resource retrieval process fits in.

If the caching system in place works, it’s due to connectors (JavaScript files) optimised to retrieve resources from the server (e.g., images) without hindering the rendering and loading process.

As you can see, the product images on the PLP are initiated by a couple of non-render-blocking JavaScript files (main.js and search.js).

As a result, Googlebot is in the position to render the page, including CDN-based images and those initiated from their back-end.

In a few words

An effective caching strategy can be instrumental in driving your eCommerce site speed optimization. It’s easier (and cheaper) said than done of course but feeding it into a broader resource optimization plan can significantly improve page load times.

Since you’ve made it this far, here are the main takeaways for you.

1. Align priorities with business needs: Focus on SEO and performance tactics based on a cost-benefit analysis. Simply put, whether you invest in hard disk cache or in-memory cache comes down to cost. Make sure your choices align with what the business wants to achieve.
2. Hard disk caching for eCommerce: For dynamic sites with frequent updates or seasonal changes, hard disk caching is a more budget-friendly option. It’s especially useful for images, where setting a more lenient max-age (at least one hour) strikes a balance between performance and frequent content updates.
3. Server-side caching is essential: While very effective, server-side caching can be tricky due to frequent cache invalidation requests.
   If your eCommerce is already up and running, it’s probably not worth the switch as static files may be already handled by HTTP browser caching in a better fashion.
4. Browser caching for static files: Browser caching helps reduce server requests and is especially effective for static files like images, JavaScript, web fonts, and CSS. While easier to implement, it doesn’t help with dynamic pages, which still consume a lot of CPU and memory on the server.
   For eCommerce sites, browser caching is likely the best way to speed things up without added complexity.
5. Prioritize JS caching: Caching JavaScript should be always a top priority as it plays a key role in managing other assets including triggering efficient image retrieval.

References

• https://medium.com/@mmoshikoo/cache-strategies-996e91c80303
• https://jakearchibald.com/2016/caching-best-practices/
• https://web.dev/articles/http-cache