Preload is slow or not working

In this article, you will learn how to identify a problem with the Preload cache feature, which basic requirements should be met, and the most common problems it may have, as well as the respective solutions.

How to check if the Preload is working slowly or not working at all

You can check if there's a problem with the Preload by following these steps:

Using your hosting's file manager, or an (S)FTP client, go to the cache folder at /wp-content/cache/wp-rocket/yourdomain.com/. There may be some cache files present.
Click the Clear and preload cache link in the WP Rocket admin toolbar menu.
After reloading the cache folder, it should be empty.
After some minutes, refresh the cache folder again, and you should see new files added, and the date when they were created.

If the cache files are not created after some minutes, the Preload is not working as expected, and you should continue reading the information below.

Note: check the hosting compatibility article to see if your hosting provider uses its own page caching option. In those hosting companies, WP Rocket's cache folder will always be empty.

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.

If the basic requirements have been met and the Preload still is not working, you should refer to the next sections of this article.

Page caching is not working

It's important to see if the page caching feature is working properly, as shown here.

If there are problems with page caching, the Preload feature won't run either.

Pages are excluded from the Preload

Pages will not be preloaded if they are excluded from the Preload, either because they are set in the Exclude URLs box, or because they are automatically excluded by WP Rocket, such as paginated pages.

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

Additional layers of cache

When one or more additional layers of cache are not cleared in sync with WP Rocket, the preloading process may encounter problems.

If a URL is cached in an additional layer of cache, the preload request will not reach WordPress, it will be "replied" by that layer of cache. Therefore, a cached file will not be generated on WP Rocket's cache folder.

Preload can still cache files, but for that to happen, the URL will have to not be cached on that other cache layer.

Preload user agent is blocked

Check security plugins and server firewalls to make sure access to your site is not blocked.

When the Preload requests are blocked, the server access logs will show 403 errors for the requests made by these user agents:

WP Rocket/Preload - Desktop user agent.
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 - Mobile user agent (when the Separate cache files for mobile devices feature is on).

Allowlisting your site’s IP address or the Preload user agents should help.

Self-requests are blocked

Check the WordPress Site Health tool for your site by going to Tools→ Site Health. There you will likely see related errors, like Your site could not complete a loopback request.

Some hosts disallow sites hosted on their servers to connect to themselves using cURL and this will cause issues to the Preload.

Please contact your host's support about this and request to remove that limitation if it’s set in the server, and check See the cURL error 28 article.

Sitemaps

This feature uses sitemaps to get the list of URLs to preload, therefore, these conditions should be met:

Sitemaps should not be empty.
Sitemaps should be publicly accessible.
The SimpleXML PHP extension needs to be enabled on your server.

Used CSS generation is in process

When using Preload and Remove Unused CSS are active, the specific batch of URLs whose Used CSS generation is in progress, will be preloaded only after their Used CSS is generated.

To confirm if a given URL or group of URLs are not being preloaded because their Used CSS is being generated, you can:

Check the status column in the wp_wpr_rucss_used_css table to see if it's set to in-progress.
Check if the is_locked column of the wp_wpr_rocket_cache table is set to 1.

This behavior is aimed to avoid sending an unnecessary preload request to the server moments prior to getting the cache purged again. As per how the Remove Unused CSS feature works, the cache will be purged as soon as the Used CSS is ready to be applied to a page. In this case, the pages will wait until the Used CSS is ready before they are preloaded.

PHP memory and PHP execution time limits

The PHP limits should be enough for the Preload to run.

It's usually recommended to have the following minimum values:

PHP memory limit of 256 MB.
PHP execution time limit of 120 seconds.

But these can be higher or lower depending on the size of your site, and your server resources.

See how to increase the PHP memory limit.

Sites with htaccess / htpasswd authorization

Preload cannot reach sites that use htaccess / htpasswd authorization. Configuring the helper plugin below may allow preload to bypass this setup:

Heads up! Manual code edit required before use!

Set WPROCKETHELPERS_HTACCESS_USERNAME as your .htaccess username and WPROCKETHELPERS_HTACCESS_PASSWORD as your .htaccess password.
wp-cron.php needs to be allowlisted. You can add this directive to your .htaccess file to accomplish this.

📥 Download (.zip): WP Rocket | HTACCESS Authorization For Preload
Developers: You can find the code for this plugin on GitHub.

If you're still having issues after checking the above information, please contact the support team.