WP Rocket cache preloading creates cache files before real visitors request eligible pages. Instead of waiting for the first visitor to generate a page cache, WP Rocket emulates visits in the background so successfully processed, cacheable pages can be served from cache on that first real visit. This can make cache behavior more predictable after publishing content or clearing the cache, but it does not mean that every URL will always be preloaded.
The practical challenge is balancing a ready cache with the work required to build it. Preloading depends on eligible URLs, sitemap access, cron execution, loopback requests, public availability, other caching layers and the resources available on the server. Understanding those dependencies makes it easier to configure WP Rocket and troubleshoot a queue that is slow, incomplete or not moving.
What WP Rocket Cache Preloading Does
WP Rocket Preload generates cache files by simulating requests to eligible pages. In a normal cold-cache situation, the first visitor requesting a cacheable page may trigger the work needed to create its cache file. With preloading, that work can happen before the visitor arrives. The intended result is that a successfully processed page can be delivered from cache on its first real visit.
This benefit applies only to pages that are eligible and successfully reached by the preload process. A page missing from WP Rocket’s cache files is not automatically proof that the feature has failed. The URL may be excluded, may contain a query string, may be inaccessible, or may be handled differently by another caching layer such as host-level, CDN or proxy caching.
The relationship between a visitor request and a cache file
It is useful to view preload as a series of background requests. WP Rocket processes eligible URLs and attempts to create the corresponding cache files in advance. If the request succeeds and the page can be cached, the first ordinary visitor does not necessarily have to create that cache file.
Preloading is therefore a preparation process, not a guarantee of a particular loading time or complete coverage of every page. The result depends on the URLs in the queue, their accessibility, the processing environment and the caching configuration surrounding WordPress.
When Preloading Runs and Which URLs Enter the Queue
Preloading is connected to cache clearing. A full preload can follow relevant settings changes or a manual clear-and-preload action. A partial preload can follow published or updated content and other targeted cache purges. The amount of work can therefore differ depending on what happened immediately before the queue was created.
WP Rocket can use sitemap URLs, the WordPress default sitemap, links from the homepage and visited cacheable URLs as sources for the preload queue. This does not mean that every discovered URL will be processed. Excluded URLs and URLs with query strings are examples of URLs that are not preloaded. Public accessibility and eligibility also matter.
Full preload versus partial preload
A full preload concerns a broader set of eligible URLs after a relevant cache-clearing event. It may require more processing than a partial preload, which targets content affected by publication, an update or another focused cache purge. Neither process should be treated as immediate or guaranteed to finish within a fixed time.
When WordPress cache should be preloaded depends on the event and the site’s needs. After publishing or updating important content, the related partial process can help prepare affected pages. After a full cache purge, a full process may be relevant, provided cron, public access, sitemaps and server resources allow the queue to progress.
Preload Prerequisites Checklist
Before adjusting preload speed, check whether the underlying process can work at all. Start by confirming that page caching functions and that the site URLs and sitemaps are publicly accessible. A private or protected site can prevent WP Rocket from reaching the pages it needs to process.
Next, verify the scheduling mechanism. WP Rocket’s preload process relies on WP-Cron or a server-side cron job, and the relevant troubleshooting guidance strongly recommends a server-side cron job for that scenario. If scheduled tasks are not executing, the queue may remain unchanged even when the preload settings appear correct.
Also consider the layers between WP Rocket and the visitor. Host-level caching, CDN caching or proxy caching can affect how requests are handled and what appears to exist in WP Rocket’s own cache files. These layers should be identified before concluding that WP Rocket has failed.
Cron, public access and loopback checks
Use a repeatable preflight check rather than changing several settings at once:
- Verify that WP-Cron or the server-side cron process is executing and can process the queue.
- Confirm that the relevant site URLs and sitemaps are reachable without authentication.
- Use WordPress Site Health to check for failed loopback requests.
- Review whether a firewall, security plugin or authentication rule blocks preload requests.
- Identify additional caching layers that may change what you observe.
A failed loopback request is especially important because WP Rocket states that Preload will not work when loopback requests fail. Site Health can expose this problem, although resolving it may require the hosting provider. Do not broadly disable security protections. Review logs and use narrowly scoped allowlisting, or consult the hosting or security-plugin provider. Make a backup before wider server-side changes, and seek technical support if you are not comfortable administering cron, firewall or authentication settings.
Why WP Rocket Preload Is Slow or Incomplete
A slow or incomplete preload can have several causes. A malfunctioning WP-Cron process, server-side cron problem or failed loopback request can stop the queue from progressing. Individual URLs may also be inaccessible, redirected, excluded or unsuitable for preload because they contain query strings. In those cases, the queue may be working while particular pages remain absent.
Security plugins, server firewalls and authentication can block requests that WP Rocket needs to make. Additional cache layers can produce a different request path or response, making WP Rocket’s own cache files appear incomplete. Slow page generation, a large URL queue and limited available server resources can also affect workload and duration.
Start with evidence rather than changing PHP or server settings immediately. Inspect the queue status, compare affected URLs with sitemap availability, check redirects and exclusions, review Site Health for loopback failures and examine relevant logs. These checks help distinguish a URL eligibility issue from a cron, access, security or resource problem.
How to interpret a missing or stalled queue
First determine whether the queue status changes. A queue that progresses slowly is different from one that cannot start. If only certain pages are missing, compare those URLs with configured exclusions, query strings, redirects and sitemap access. If no progress occurs, prioritize cron and loopback checks.
Do not assume that a missing WP Rocket cache file proves that no caching exists. A host-level, CDN or proxy layer may be handling the request separately. Conversely, do not treat a slow queue as proof that PHP limits or server capacity must be changed. Such changes require an understanding of the site’s workload and, when necessary, appropriate hosting or technical support. Avoid changing database tables or disabling security controls as first steps.
Reducing Server Load During Preload
Preloading creates background requests, so warming a large queue can increase server processing and PHP workload while it runs. The effect depends on the number of URLs, page generation time, server response performance and available resources. There is no universal CPU threshold or configuration that suits every WordPress site.
WP Rocket documents three controls for managing preload speed: batch size, the interval between batches and the delay between requests. They can be adjusted when the server struggles with preload or CPU usage becomes a concern. The goal is not automatically to make preload slower, but to find a workload that the individual environment can handle.
Choosing what to adjust first
Consider the controls as separate variables:
- Batch size: affects how many preload requests are handled in a batch.
- Interval between batches: creates more space between groups of requests.
- Delay between requests: separates individual requests within the process.
Reducing preload speed may lower concurrent pressure while increasing the time required to warm the cache. Therefore, monitor CPU usage, PHP errors, server response times, site availability and queue progress after each change. Do not copy a fixed batch size or request delay from another site and treat it as universal. The documented controls manage workload; they do not guarantee faster overall performance or complete preload coverage.
A Safe Troubleshooting Workflow and Practical Expectations
Use an ordered process. Begin by checking whether page caching works and whether the preload queue changes status. Then verify cron execution, public sitemap access and loopback requests. If the queue progresses but individual URLs are absent, inspect redirects, exclusions, query-string URLs and sitemap behavior. Review firewall and security-plugin logs without broadly disabling protections. Finally, identify additional caching layers before judging WP Rocket’s own cache files.
If the server struggles, adjust batch size, the interval between batches or the delay between requests cautiously. Test changes during a lower-risk period and monitor CPU usage, PHP errors, response times, site availability and queue progress. Problems involving cron, loopbacks, firewalls, authentication or server resources may require the hosting provider or another appropriate technical specialist. Back up the site before wider infrastructure changes.
What not to assume about preloaded pages
Do not assume that every URL enters the queue, that every queued URL is publicly reachable, or that every cache file will be created. Exclusions and query-string URLs can explain missing pages. Another cache layer can also change what a request appears to use. Similarly, do not expect a fixed completion time. Queue size, URL accessibility, cron execution, server response performance and available resources all influence duration.
Effective WP Rocket cache preloading depends on eligible public URLs, accessible sitemaps, functioning cron and loopback requests, compatible caching layers and sufficient server resources. Troubleshoot in that order: inspect the queue and access conditions, review Site Health and logs, then adjust documented workload controls carefully. These controls can help manage server pressure, but they do not create a universal configuration or guarantee that every page will be preloaded.
Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.