Editor’s note: This post was originally published in March 2023 by Rahul Sharma. It was refreshed in June 2026 to reflect how cache warming fits within Webscale’s Application Delivery platform and to add context for Adobe Commerce, Magento, and Shopware merchants. Rahul’s original technical guidance is preserved below.
What is cache warming?
Cache warming is the practice of pre-loading a website’s cache with frequently requested pages and assets so the first shopper of the day lands on a fast store, not a cold one. On Adobe Commerce, Magento, and Shopware sites, Webscale’s Application Delivery platform warms caches automatically after deploys, configuration changes, and traffic spikes, so the cache is ready before real shoppers arrive.
Cache warming is a concept which is used to optimize the performance of a website or web application by preloading the cache with frequently accessed content. By doing this, the content is readily available in the cache, reducing the time it takes to serve it to the user. This results in a faster and more efficient user experience.
Why is cache warming important?
When an end user visits a website, the content is retrieved from the cache, the origin, or probably from both. If the content is not in the cache, the system must fetch it from the origin, which may take longer. The longer it takes to fetch the content, the slower the website, and the greater the impact on the user experience. Cache warming eliminates this problem by preloading the cache with frequently accessed content, ensuring that it is always available for users.
What are the benefits of cache warming?
- Faster load times: By preloading the cache, cache warming reduces the latency associated with the initial cache miss and content is served to the user faster, resulting in a crisper, more seamless user experience.
- Reduced load on the origin: By caching content, the load on the origin is reduced, freeing up resources and improving the overall performance of the website or application.
- Improved scalability: Caching content helps to distribute the load evenly, improving the scalability of the website or application.
- Increased user engagement: A faster, more efficient website or application will keep users engaged and reduce the likelihood of frustration or abandonment.
- Optimal use of cache storage: By warming the cache with the most frequently accessed data, cache warming optimizes the use of limited cache storage space and ensures that valuable resources are not wasted on data that is unlikely to be reused.
How Webscale handles this for you: Most Adobe Commerce, Magento, and Shopware merchants don’t want to maintain cache warming scripts in-house. Webscale Application Delivery warms caches automatically after every deploy, content change, and predicted traffic surge. The result is faster first-visit page loads with no engineering overhead. See how Application Delivery fits into your stack.
What are the disadvantages of cache warming?
- Increased resource usage: Warming the cache requires additional resources on the system, such as memory and processing power, which can be a concern for resource-constrained systems.
- Outdated/Old data: If the cache is not regularly updated, the data stored in the cache can become outdated, leading to incorrect results or stale data being served to users.
- Increased maintenance: Cache warming requires longer ongoing maintenance to ensure that the cache is kept up-to-date and that resources are being used efficiently.
- Limited effectiveness: Cache warming may not always be effective in improving performance, especially if the data being cached is not frequently accessed, or if the cache is not sized appropriately for the amount of data being stored.
How to implement cache warming?
There are many ways to implement cache warming.
- Manual: By visiting each page of a website or web-application. This is time consuming, requires too much effort from the developer or application owner, and can lead to errors.
- Automatic: Developers can use “warmer.phar” for automation of cache warming. This tool is provided by Symfony. You can download “warmer.phar” using the below command
To use an automated cache warmer, first we need to build “warmer.phar” and there are several ways to do this.
git clone https://github.com/erickmarsh/CacheWarmer.git
Note: In this repo compost.json is outdated and uses an old version of modules. You can update the modules version as needed in composer.json to make it compatible with your PHP version.
Once you clone the repo you need to update composer.json to ensure the latest version of modules as needed.
Once composer.json is updated below is the process to build “warmer.phar”.
composer install php build.php
This will build the warmer.phar”. You can run the command “php warmer.phar list” to list the option.
You can run warmer against the sitemap and Google Analytics. Featured below is the command for running it using sitemap.xml
php warmer.phar warm:sitemap https://www.example.com/sitemap.xml --threads 10 --wait 3
There are many arguments that can be used in the command above – few are explained below:
- threads: Number of concurrent requests to make
- wait: Specifies the time, in seconds, to wait between each request
- cache-dir: Specifies the directory where the cached responses will be stored.
- timeout: Sets the timeout for each request, in seconds.
- max-depth: Sets the maximum depth of URLs to cache warm, starting from the sitemap URL.
Note: Developers can build their own custom “warmer.phar” based on their requirement if they do not want to clone a given repository.
Conclusion
Cache warming is one of those things that’s invisible when it works and painful when it doesn’t. A cold cache means the first shoppers of the day, the ones who clicked through from your highest-converting campaigns, are the ones who pay for it in slow page loads. Whether you build your own warming workflow or use a platform that handles it automatically, the principle is the same: the cache should be ready before your customers are. If you’re running Adobe Commerce, Magento, or Shopware and want to stop thinking about cache warming entirely, that’s what Webscale’s platform is for.
