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, with the Mobile Cache option, 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:

preload 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:

  • URLs in sitemaps generated by plugins with automatic compatibility
  • URLs found on WordPress default sitemap - In case no third-party sitemap is detected.
  • URLs found on the homepage - In case WordPress default sitemap isn't available.
  • URLs that aren’t included in a sitemap and that received a visit

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

For the Preload feature to work as expected, the following requirements should be met:

  • Cron: WP Cron or a real server-side cron job must be able to run, the latter is strongly recommended.
  • Your website and sitemaps must be publicly accessible.
  • The Preload won't work for logged-in users (when User Cache is enabled), and it won't work on sites blocked from the public by "maintenance mode" plugins, or similar.
  • The Preload can work on sites with htaccess authentication with the instructions found here.
  • The Preload won't work if your hosting provider uses its own page caching option. In those hosting companies, WP Rocket's cache folder will always be empty. Please, check the hosting compatibility article

If the basic requirements have been met and the Preload is still is not working, you should check this article: Preload is slow or not working

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.

How fast is Preload expected to run

The Preload feature can cache up to 45 URLs every 60 seconds. However, WP Rocket is designed to check if it's stressing your server and slowing down page loading. If this is detected, it will automatically lower the number of URLs processed in each batch to lower the risk of high CPU issues.

The Preload speed also depends on these other factors: 

  • Having a server cron in place to consistently run your site's cron jobs.
  • The basic requirements being met.
  • An excessive number of other tasks impacting the queue of scheduled tasks.
  • The Preload parameters are customized to speed up or slow down the process.

If the Preload is much slower, please refer to this article.

Preload when page caching is disabled

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

This is the case if:

  • You have disabled page caching for some reason.
  • You're using a hosting provider that manages their own page caching solution, such as Kinsta, WP Engine, DreamPress, Flywheel, etc. See the full list of hosting providers where page caching is disabled in this article. In these cases Preload will create the server-side cache.

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

With 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');

Other excluded URLs

The following URL patterns will be excluded from Preload because they are not valid pages:

  • void\(.*;
  • (.*)__trashed(.*)
  • /jet-menu/(.*)
  • /jet-popup/(.*)

Additionally, pages with query strings can't be preloaded.

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 next preloading batch.
    • The rocket_preload_job_preload_url action event will track and handle the Preload status of each URL.
  • The number of URLs to be added to the next preload batches is between 5 and 45 URLs. 
  • The exact batch value depends on the average results from the loading times, taken from pages in the last 5 minutes, and which are saved in the rocket_preload_previous_requests_durations transient.
  • 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 WP Rocket/Preload 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.