A deployment warmer needs to request every important variant the cache actually serves. If desktop and mobile responses have separate keys, refreshing one URL with a desktop request can leave the mobile copy unchanged. I start with the cache key, then make the warm-up and verification cover the same inputs.
I verify current content as well as response speed. A stale response can be quick enough to pass a timing check while still showing the previous version.
Start with the cache key
I list the inputs which genuinely change a stored response. Depending on the site, those can include the host, path, language, device classification or supported currency. The warmer has to request the same combinations as the traffic it is meant to help.
I do not generate every imaginable combination. That can create a large amount of work for entries nobody uses. I start with important landing pages and the variants the application actually serves, then give the background job a sensible budget.
Mobile detection is not viewport width
The WordPress documentation for wp_is_mobile() distinguishes device detection from responsive layout. Resizing a desktop browser window does not necessarily make the server choose its mobile path.
For a server-side device split, I use a representative request with the headers the application recognises and check the cache’s diagnostic output. I also check a real browser. A screenshot at a narrow width is useful for layout, but it does not by itself prove which server-side cache entry was read.
Keep the warmer anonymous
A warm-up request should not carry a staff login, a shopper’s basket or a private account cookie. That would test a different response path and could populate the wrong kind of entry if the cache policy were already broken.
I treat transactional pages separately. Basket, checkout and account responses need to remain appropriate to the current customer; they are not entries to prefill into a shared anonymous page cache.
Soft purges make missed variants less obvious
With stale serving enabled, an unrefreshed variant can still answer quickly. A speed check may therefore look excellent while the content is old. I verify a visible change or a version marker as well as the response time and cache status.
I keep a maximum stale window and a working background refresh route. Warming a handful of important pages helps, but it is not a complete freshness policy for the rest of the catalogue.
Prove both sides after a deployment
I warm the intended variants, request them again, and confirm each returns the current content through the expected cache path. I also test a normal shopper request so a special warm-up header is not hiding a behaviour difference.
If the site serves identical HTML to all device types and uses CSS for the layout, I question whether a device split is needed at all. Every extra variant needs storage, invalidation and verification. I keep the ones the application needs, then make sure the deployment accounts for them.