How page caching normally works
WordPress builds pages dynamically. It runs PHP, loads data from the database and processes the active plugins before returning the final HTML.
Doing this for every visitor would be slow, so websites use page caching. Once WordPress generates a page, the finished HTML is saved. The next visitor receives this prepared copy instead of waiting for WordPress to build everything again.
When the cache expires or the page changes, a preload process should generate a fresh copy before another visitor arrives.
How low traffic broke the cache lifecycle
WP Rocket used WP-Cron to preload the cache. The issue is that WP-Cron is not a real scheduled process. It only checks for pending tasks when someone visits the website.
At roughly four visits per hour, there wasn’t enough traffic to process the preload queue. The cache contained only one page for a website with only a few published URLs, while almost 300 URLs were waiting to be processed.
Most visitors therefore had to wait while WordPress generated the requested page from scratch. That added between 2.7 and 3.8 seconds before the browser could start displaying anything.
How we detected the issue
We detected the problem through Real User Monitoring in Pagespeed Digital, our custom-built website performance monitoring tool. RUM showed what actual visitors were experiencing across different pages, devices and countries. The website had an LCP of 4 seconds and a TTFB of 4.1 seconds at p75.
Manual Lighthouse tests looked healthy because opening the page warmed the cache before the test started. RUM measured the actual first visits, including the slow server response.
The fix
We moved WP-Cron to a real server cron running every five minutes. The preload process now works independently of website traffic and keeps the WordPress cache ready even when nobody visits the website.
We also added Cloudflare caching for public HTML. Admin pages, logged-in users and dynamic WordPress routes continue to bypass the cache.
By the following morning, the preload queue was fully processed and the origin contained around 450 cached pages.
An edge miss dropped from 2.8-3.8 seconds to roughly 200-350 ms.
The results
The RUM data collected by Pagespeed Digital shows, that the average 7days LCP decreased from 5.2 down to 2.6.
Why RUM (Real user monitoring) matters
RUM gave us feedback from actual visitors before the full improvement became visible in Google’s Chrome User Experience Report.
CrUX also uses data from real Chrome users, but reports it through a rolling 28-day window. It updates daily, but every result still includes visits from the previous 28 days. A fix can therefore be working while older, slower sessions continue to affect the published result.
Our RUM monitoring shows new sessions as they happen. We can verify that the fix is moving the metrics in the right direction without waiting for the complete CrUX window to refresh.
One performance score is not enough
This issue would have been easy to miss with Lighthouse alone. We needed multiple data sources:
- Synthetic monitoring to test pages consistently.
- RUM to measure actual visitors by page, device and country.
- CrUX to track the real-user data Google uses for Core Web Vitals.
- Cloudflare and server data to identify which part of the delivery stack was slow.
One tool can tell you that a website loaded quickly during one test. A proper monitoring stack tells you whether it is fast for real visitors, why it isn’t and whether the fix keeps working.
