Stop Flushing The Cache! Best Practices for Adobe Commerce Cache Clearing
Often when a change you’ve made and expect to display on the website is not visible, your first inclination may be to flush the Adobe Commerce, previously known as Magento Commerce cache. However, this action may not always be the most appropriate solution, and more often than not may cause other unintended side effects that can impact your site – hampering the customer experience and limiting your sales. There may be other considerations at play.
The closest cousin of Adobe Commerce's cache management system is indexes. Both are used to increase performance on your Adobe Commerce store, but they serve somewhat different purposes. It is important to know the difference between these two performance tools, what they do, and when one or the other may be responsible for your missing content.
Adobe Commerce Cache Management System
Adobe Commerce’s cache management system saves loaded data, configuration, instructions, images, assets, and more for increased performance loading and rapid access on the storefront. It offers increased stability on your website during heavy user load and greater customer browsing activity. Having a slow-performing website can also negatively impact your conversion, as the end-user (your customers) will be dismayed at a site that takes too long to load. By taking the pressure off of the server, caching results in a much shorter server response time (also known as the TTFB or time-to-first-byte).
If a change made on a static asset (JavaScript, a stylesheet, on your site, HTML fragments, and entire pages, etc.) is not reflecting in the browser, you may need to refresh individual cache types if it is appropriate. Below is an overview of just some of the main cache types in Adobe Commerce 2:
| Cache type | Description |
|---|---|
| Configuration | Adobe Commerce collects configuration from all modules, merges it, and saves the merged result to the cache. This cache also contains store-specific settings stored in the file system and database. Clean or flush this cache type after modifying configuration files. |
| Layout | Compiled page layouts (that is, the layout components from all components). Clean or flush this cache type after modifying layout files. |
| Block HTML Output | HTML page fragments per block. Clean or flush this cache type after modifying the view layer. |
| Collections Data | Results of database queries. If necessary, Adobe Commerce cleans up this cache automatically, but there may be additional third-party data cached that Adobe Commerce is not aware of. Clean or flush this cache type if your custom module uses logic that results in cache entries that Adobe Commerce cannot clean. |
| DDL | Database schema. If necessary, Adobe Commerce cleans up this cache automatically, but there may be additional third-party data cached that Adobe Commerce is not aware of. Clean or flush this cache type after you make custom changes to the database schema that Adobe Commerce does not make itself. |
| Entity Attribute Value (EAV) | Metadata related to EAV attributes (for example, store labels, links to related PHP code, attribute rendering, search settings, and so on). You should not typically need to clean or flush this cache type. |
| Page Cache | Generated HTML pages. If necessary, Adobe Commerce cleans up this cache automatically, but there may be additional third-party data cached that Adobe Commerce is not aware of. Clean or flush this cache type after modifying code level that affects HTML output. It is recommended to keep this cache enabled because caching HTML improves performance significantly. |
| Translations | After merging translations from all modules, the merger cache will be cleaned. |
| Integration Configuration | Compiled integrations. Clean or flush this cache after changing or adding integrations. |
Adobe Commerce collects configuration from all modules, merges it, and saves the merged result to the cache. This cache also contains store-specific settings stored in the file system and database.
Adobe Commerce's Cache Management screen in the admin dashboard will display the status (enabled, disabled, or invalidated) of each primary cache type list above. As a general rule of thumb, only refresh an individual cache type if its status is invalidated.
Found in the upper-right corner of the page are two additional buttons to purge cache:
- Flush Cache Storage: this action will purge the entire cache storage, which might affect other processes applications that are using the same storage.
- Flush Adobe Commerce Cache: this action will delete all items from enabled Adobe Commerce cache types only, which should not affect other processes or applications.
It is very much not recommended to uses these commands outside highly exceptional circumstances and encountering issues that you cannot otherwise isolate.
At the bottom of the page are additional buttons:
- Flush Catalog Images Cache: purges pre-generated (watermarked and resized) product image files.
- Flush JavaScript/CSS Cache: clears any themed merged/minified JS and CSS files from the cache.
Upon both of these actions, Adobe Commerce should then immediately proceed to regenerate those respective caches, which may impact the performance of your site due to the additional resources required.
It’s worth noting that clearing these Adobe Commerce system caches does not also flush your own device’s web browser cache. It is recommended to refresh your browser’s cache (or run in an “incognito” or private mode, which largely disables your local browser cache) when testing and verifying a change. You may need to clear your local web browser cache to ensure you can see the most recent files and updated content.
As a best practice, please consider any cache refresh during non-peak hours when customer access is low (such as late at night or early in the morning). Clearing cache during peak times can result in increased stress on the site and risk taking it down.
Indexing for Optimized Storefront Performance
Indexing is how Adobe Commerce transforms “refreshable” data (such as products, categories, and pricing) to enhance the performance of your storefront. Without indexers, Adobe Commerce would force your storefront to load complex and heavy content on the fly; causing performance to be greatly reduced and negatively impacting your conversion rate. As data changes, the transformed data must be updated or reindexed.
When you make a change to “refreshable” data, that raw data is immediately saved to the Adobe Commerce database. Absent though at this point are the accompanying instructions about what information should be displayed on any given page. Indexing accumulates these instructions and data into special tables, accounting for all conditions known to Adobe Commerce; resulting in more optimized storefront performance.
As an example, if you change the price of an item from $9.99 to $7.99, Adobe Commerce must first reindex the price change to display it on your storefront. Without the indexing step, Adobe Commerce would be required to calculate the price of every product in the catalog on the fly every single time, while taking into account discount and promotional rules, bundled pricing schemes, tier pricing, etc. Without indexing, loading the price for an individual product would take a very long time with a noticeable impact on performance. With indexing, every possible price is calculated and stored for rapid retrieval, reducing the amount of the time the customer has to wait.
Adobe Commerce's reindexing task is a background process, leaving your storefront open and accessible for end-users during this time. Adobe Commerce automatically reindexes whenever merchant data is changed and there are two modes to support this:
Update on Save: Index tables are immediately updated following a data change. This mode assumes a low intensity of update and browsing operations in your store. It can lead to significant delays and data unavailability during high loads.
Update on Schedule: Index tables are updated by a cron job according to a defined schedule. Adobe Commerce recommends using this mode in production to avoid problems (high CPU usage, database errors, etc.) when multiple admin users update data.
Reindexing and caching serve different purposes in Adobe Commerce. Both result in increased performance and data retrieval, but indexes track database information while caches save loaded data and static assets. It is beneficial to recognize which of these may be related to the change you’re attempting to implement in order to diagnose why your desired change is not reflected and how best you can work towards resolving the issue.
