Preload cache

The Preload Cache feature emulates a visit to your site's pages to generate cache files. Since the feature is enabled by default on plugin installation, there's no need to wait until a real visitor accesses the pages before starting to serve cache files, therefore, your pages are fast from the first visit.

Feature overview

By default, despite the status of the Preload feature, WP Rocket will preload the homepage automatically upon plugin activation and after saving changes. Additionally, if the Separate cache files for mobile devices feature is enabled, the mobile version of the homepage will be preloaded as well.

preload interface

When you first enable Preload, you'll see the following admin notice:

WP Rocket: The preload service is now active. After the initial preload it will continue to cache all your pages whenever they are purged. No further action is needed.

The Preload is an ongoing process, attached to the cache clearing. This means the pages will be preloaded every time their cache was cleared.

At the same time, any URL that already has a cache file - its cache wasn't cleared - will be skipped over, making the process optimal.

In this sense, WP Rocket can trigger full or partial preload after the cache is cleared, as follows:

Full preload

Full cache preloading will run on the following URLs:

And, the preloading will run in the following scenarios:

  • When you save changes to WP Rocket settings that affect the front-end (because the cache is cleared).
  • When you click the Clear and preload cache button in the admin toolbar, or on the WP Rocket dashboard.
  • Whenever the rocket_clean_domain function is called.

Partial preload

Partial cache preloading takes effect when WP Rocket automatically clears the cache for the following URLs:

  • Published or updated URLs, such as posts/pages/custom post types.
    • Including any other content related to it (i.e. home, category, tag, etc.)
  • URLs in the Always Purge URL(s) box.
  • Pages purged when the Cache Lifespan expires.

Basic requirements

The Preload relies on the following basic requirements:

  • Your Homepage or sitemap must be publicly accessible. Preload cannot reach sites that are blocked by security measures or htaccess/ htpasswd authorization.
  • WP-Cron or a real server-side cron job must be able to run, the latter is strongly recommended for the Preload to run properly.
  • The SimpleXML PHP extension needs to be enabled on your server.

How to check if Preload is working

When enabled, the Preload will create the cache files. In order to see if the Preload is working, please follow these steps:

  1. Access your WordPress installation path via (S)FTP or File Manager
  2. Go to the cache folder, at /wp-content/cache/wp-rocket/yourdomain.com/
  3. Click on Clear cache and preload from the admin bar
  4. Refresh the folder, it should be emptied
  5. Refresh once more, and the cache files should begin to appear, inside their own slug-specific folders.

    Example: /wp-content/cache/wp-rocket/yourdomain.com/product/index-https.html.

Preload when page caching is disabled

Even when page caching is disabled, enabling Preload is useful to trigger the other optimizations, including Minify CSS files, Remove Unused CSS, Delay JavaScript execution, etc.

This is the case for some hosting providers such as Kinsta, WP Engine, DreamPress, Flywheel. See the full list of hosting providers where page caching is disabled in this article.

Preload for cookies and User Cache

By default, Preload doesn't work for user cache or cookie-specific cache files.

For cookies, you can use a function to preload the value of a cookie instead of the regular cache.

Preload based on SEO plugin's sitemaps

WP Rocket's Preload has automatic compatibility with most common SEO plugins. The URLs found in their sitemaps will be included in the preload process. This is the list of compatible plugins:

If none of the above plugins are detected, the preloading will work based on WordPress default sitemap.

Customize Preload sitemaps and priority

By default, Preload will:

  • Work on URLs found in the compatible sitemaps.
  • Run on URLs according to their modified value in the wp_wpr_rocket_cache table, with the oldest modified being preloaded first.

    Since the modified value changes as pages are edited and new pages are posted, the order in which URLs are preloaded changes constantly.

    When a post is edited, it won’t be preloaded in priority versus an existing queue of URLs to preload, instead, the edited post will be sent to the back of the queue.

You can use the rocket_sitemap_preload_list and rocket_preload_order filters to customize the above behavior. For more information, please check the following article:

Customize Preload sitemaps and priority.

Preload and Mobile Cache

If you have enabled the Separate cache files for mobile devices option under the Mobile Cache feature, mobile-specific cache files will also be generated by the Preload in addition to desktop-specific cache files.

Preload and WebP Compatibility Add-on

If you have enabled the WebP Compatibility Add-on, WP Rocket will preload the WebP cache file instead of the non-WebP cache file.

How to exclude URLs from being preloaded

You can exclude pages and groups of pages from being preloaded, but still cached, using the Exclude URLs box.

You can also use a filter to exclude URLs from the Preload, or limit the Preload to certain URLs.

All the information can be found here: exclude URLs from being preloaded.

URLs automatically excluded from the Preload

The Preload is disabled for paginated pages. This means, URLs that contain /page/, or whatever the WordPress pagination base is, will not be preloaded.

As a clarification note, the paginated URLs can still be cached if they're visited, but they won't be added to the preloading queue.

If you wish to change this behavior, and preload paginated pages, you can add the following snippet as explained here:

function enable_preload_for_pagination( $regexes ){
		global $wp_rewrite;
		$pagination_regex = "/$wp_rewrite->pagination_base/\d+";
		$exluded_urls = [		
			$pagination_regex,
		];
		$regexes = array_diff( $regexes, $exluded_urls);
		return $regexes;
	}
add_filter( 'rocket_preload_exclude_urls', 'enable_preload_for_pagination');

URLs excluded from the Preload after some time

When a URL is not accessed during the past 30 days, WP Rocket will automatically exclude it from the Preload queue.

This means the URL is still cacheable, but WP Rocket won't include it in the Preload process unless it's visited again.

In order to change this behavior, you can use the rocket_preload_delay_delete_non_accessed filter.

For example, you can change the interval from 1 month to 1 year by adding the following snippet as shown here:

add_filter( 'rocket_preload_delay_delete_non_accessed', function( $interval ){
return '1 year';
} );

How to stop the preload process

If you need to stop the preload, deactivate the Preload option. The current batch of URLs will finish, and then it will stop completely.

Technical info

  • The Preload uses a background process, limited to using up to 90% of the available PHP memory.
  • The full process relies on WP Cron or a server-side cron, and Action Scheduler.
  • The rocket_preload_job_parse_sitemap hook is used to detect the sitemaps to be preloaded.
  • The rocket_preload_process_pending cron event checks the preload status of the URLs. It will trigger the preload for 45 URLs per minute.
    • The rocket_preload_job_preload_url action event will track and handle the Preload status of each URL.
  • The tracking of the status of the URLs is done in the database, in the wp_wpr_rocket_cache table.
  • The rocket_preload_clean_rows_time_event cron event is used to delete old rows, its frequency is once per week.
  • The Preload works with two user agents: WP Rocket/Preload, for the desktop version, and Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1 for mobile.

Troubleshooting

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.