Skip to main content

General settings

In this section, you can configure performance, caching, statistics, authentication, debugging, and other settings for optimal extension performance.

The Page Cache Warmer settings are located at System -> Page Cache Warmer -> Settings, and consist of the following sections:

General warming and exclusion configuration​

Enable warming and define exclusions for User-Agents or pages.

  • Enable warmer: once enabled, the extension will run via cron, collect URLs, and warm them up.

  • Exclusions for warming queue: URLs matching the specified regular expressions will be excluded from the warm-up queue and will not be processed by the crawler. To test regular expressions, you can use any online service.

    Example:

    /\?/ - ignore pages with GET params.

    /\?[\w]*&[\w]*&[\w]*/ - ignore pages with more than 2 GET params.

    /\?(?!p=).*/ - ignore all pages that have GET parameters, except paging (like ?p=2).

  • Page types to exclude: permits choosing page types from a list which will be ignored by cache warmer. All available page types presented on the website will be added after the CLI crawler has completed crawling the website.

  • User-Agents to exclude: permits setting patterns of user-agent headers, which will be ignored by cache warmer.

    Example:

    Set /.*Googlebot.*/ to prevent pages from being added to Pages section if Googlebot visits them.

Performance settings​

Adjust the extension's warming process to optimize page caching performance. The Page Cache Warmer crawler runs regularly according to a cron schedule and starts traversing the list of available store URLs. If a URL is already cached, it is skipped. If a URL is not cached, the crawler visits it as an external user to render the page and place it in the cache.

  • Warming strategy: define how pages should be warmed in the cache.

    • Warm Rules (default): the extension will warm pages depending on Warm Rules and the popularity of URLs.
    • Warm Rules + URL variations: additionally to the default strategy, the extension will fire additional background processes trying to warm all variations of URLs from the current warming job's queue. The exec() function should be enabled. Can create an additional load on the server.

  • Warming limit (%): set the cache fill rate limit to control warming. Once reached, the extension will stop warming pages. Leave the field empty to remove the limit.

    Example:

    Set to 80% to stop warming when 80% of URLs are reached.

  • Warming level: set the heating intensity. A higher level will process more URLs in a single cron run, resulting in a greater load on the server.

    • High - intensive warming: the crawler uses the full-time interval between warming jobs and without utilizing the server load threshold. This performance level is recommended for stores installed on high-performance servers with a low load rate. CURL multi requests should also be available.
    • Medium - default mode: the performance level recommended for most Magento stores. The crawler uses 75% of the time interval between warming jobs. If the server load rate is higher than 80%, the crawler will not warm the pages in the cache. CURL multi requests should also be available.
    • Low - soft warming: the lightest performance level. It is recommended for stores installed on servers with a high load rate. With this performance level, the crawler uses only half of the time interval between warming jobs. If the server load rate is higher than 60%, the crawler will not warm pages in the cache. CURL multi requests are not required for this performance level.
    • Custom - expert mode: allows you to configure the crawler's performance manually. This performance level lets you configure the following parameters:
      • Job schedule: cron expression that schedules warmer jobs. Read more about setting up cron expressions.
      • Maximum job run time: maximum running time allowed for a crawler job (in seconds). Default value is 100.
      • Concurrent requests: specify the number of concurrent requests to be used during cache warming. 2-3 requests are suitable for most stores. Before using more, ensure your server can handle them.
      • Delay between requests: set the delay between requests when Concurrent requests is set to 1. The delay is in milliseconds, with a maximum of 10 seconds (10000 ms).
      • Server load limit (%): prevent the warmer job from running if the average system load exceeds the specified limit. Leave the field empty to disable this restriction.

Caching and behavior settings​

Configure caching and request context settings to optimize site performance.

Caching behaviour​

These settings are for stores experiencing issues with caching pages or maintaining cache persistence.

  • Forbid cache flushing: completely disables flushing FPC cache.

    • Yes: the extension will not track changes to product or category pages. To apply the changes, you will need to manually clear the cache in System -> Cache Management.

    • No: the extension will track the changes made and send a request to clear the cache after they are saved.

      note

      Frequent cache clearing may result in a low Cache Fill Rate.

  • Forcibly make pages cacheable: alows you to override the default behavior of Magento with regard to caching pages by changing content block attributes:
    • Disable: keeps Magento's default caching behavior.
    • All pages: the extension will delete cacheable="false" for all blocks in home, category, and product pages, making them cacheable as a result.
    • Configure: allows make pages cachable by type.
    • Make pages cacheable by page type: select the types that should be cached forcibly.
      • Home page (Cms · Index · Index)
      • Category (Catalog · Category · View)
      • Product pages (Catalog · Product · View)

HTTP context adjustment​

Adjust altering of warming requests and pages variations in the cache. Changing these settings requires cleaning and re-crawling the URLs table (warming queue).

  • Use the same cache for new visitor
    • Yes: allows you to avoid the creation of several copies of cached pages for Magento installations with multiple store views.
    • No: using it if your pages are cached incorrectly for different languages/currencies/store views.
    • Consider design rules

      • Yes: the extension will take design settings User-Agent rules into account when caching pages and will add an additional parameter mst_design to the HTTP context. This means you won't need to make any additional configurations to the Varnish settings to cache pages based on the website's design settings.

        note

        Enable this option ONLY if you have different themes which depend on the User-Agent (Content -> Design -> Configuration; for example, a separate theme for mobile pages).

        After changing this setting, it is required to clean the Pages table and flush the entire Magento cache.

      • No: extension will not add any parameters to HTTP context.

  • Use PHPSESSID cookie in requests: Enable only for session file cleanup issues within filesystem.
    • Yes: adds PHPSESSID to requests and reduces session creation. Crucial for filesystem-stored sessions.
    • No: will not change the requests.

FPC hole punch​

The Hole punch allows you to exclude individual blocks from caching. This way, most parts of the page can still be cached except of selected blocks (so-called holes).

This feature is extremely useful when you have complex pages constructed from multiple templates and multiple blocks, and it can seriously optimize your store.

Warning:

The Hole Punch feature works with File cache only; it does not work with Varnish. It works primarily for standard Magento, and CMS pages and blocks. It can not be applied to blocks which are dynamically generated or loaded with AJAX, such as:

  • Embedded product lists, such as Top Sells, or similar;
  • Cart Widgets;
  • AJAX-dependant dynamic blocks;
  • Javascript-generated blocks;
  • Complex blocks, added by third-party extensions.
  • Config: configure blocks with dynamic content on site pages to be excluded from caching.
    • Template: defaine path to the template which contains excluded block.
    • Block class: add your block class
    • Cms block ID / Widget code: if this block is customized, enter its ID which can be seen at Content -> Blocks.
    • Store: store view, for which block excluding should be applied.
    • Action: use to remove item from table.

Statistics settings​

Configure tracking to collect statistical data and insights on page popularity.

  • Enable statistics
    • Yes: allows the collection of statistical data. Will add /cache_warmer/track requests to the websites' front pages.
    • No: will not collect statistical data and count the popularity of the pages.

HTTP authentication​

For HTTP-authenticated storefronts, set credentials to warm the cache.

  • Username: set your username.
  • Password: set the password for the existing username.

Debugging and logging settings​

Configure debugging and logging settings to monitor cache status and track requests.

Frontend debugging​

Manage cache debugging on front pages.

  • Show cache status: allows displaying a debug popup on the store frontend with the page cache status.
  • Show cache status only for: set comma-separated IP addresses for which the infobox should be visible.

Advanced logging​

Manage logging events related to cache and warming process.

  • Log warmer requests: will write all warmer requests to /var/log/cache-warmer.log file.
  • Log cache flush backtrace: allows saving backtraces for cache flushes into the database. The backtraces will be visible on the Cache flushes page provided by the extension.
  • Log cache flush backtrace into file: allows saving all cache flushes to /var/log/cache-warmer-flush.log file.
  • Log cache tags into file: logs cache flush tags in /var/log/cache-warmer-flush.log for post-mortem analysis.