Separate Mobile Cache
Serve a dedicated cached response for mobile visitors when the mobile experience differs from desktop.
Metrics
This technique can move up to 67% of LCP's share of the Lighthouse score.
This technique does not move TBT.
This technique does not move CLS.
This technique can move up to 67% of FCP's share of the Lighthouse score.
This technique can move up to 67% of SI's share of the Lighthouse score.
This technique does not move TTFB.
Overview
A separate mobile cache maintains distinct cached page versions for mobile and desktop user agents. When the server or theme delivers different HTML to mobile users — different layouts, hidden elements, mobile-specific assets, or server-side responsive image sizes — a shared cache file would serve desktop HTML to mobile visitors or vice versa. A dedicated mobile cache ensures mobile users always receive a correctly optimized, fully cached response rather than a cache miss or incorrect content.
Impact grade, A+ to D: how much of the Lighthouse score this technique can move. Unaffected: TBT, CLS, TTFB.
The Problem
Many WordPress themes and plugins conditionally change HTML output based on the detected device type. If a single cache file is shared between mobile and desktop visitors, the first visitor to populate the cache determines what everyone sees. A desktop user populates the cache with a full-width hero and desktop navigation — then every mobile user receives that same desktop HTML from cache, breaking layout and delivering oversized images. The alternative — bypassing cache entirely for mobile — eliminates the performance benefit for mobile users, who are often on slower connections where caching matters most.
Performance Impact
LCP
High
correctly sized mobile images serve faster; mobile cache hit means full LCP benefit is preserved
FCP
High
mobile visitors served from cache instead of triggering PHP regeneration due to cache mismatch
SI
Moderate
mobile-optimized content renders sooner when delivered from a dedicated cache tier
Risk: Low
increases cache storage by ~2× and requires correct user-agent detection at the cache layer
How it works
01
Detect mobile at the cache layer using User-Agent
The cache plugin inspects the
User-Agentrequest header and routes mobile visitors to a separate cache directory. Cache keys typically include a/mobile/path prefix or a device type flag. This detection happens before PHP runs — ensuring mobile visitors always receive the correct cached file.02
Generate separate cache files on first mobile visit
On the first mobile visit to each URL, the full PHP stack executes, the theme renders the mobile-appropriate HTML, and the result is stored in the mobile cache. All subsequent mobile visits read from this cached file. Desktop visits read from the separate desktop cache.
03
Configure breakpoints for tablet if needed
Some setups distinguish three device tiers: mobile, tablet, and desktop. A tablet cache is worth maintaining only if the theme actually delivers different HTML to tablet user agents — check your theme’s device detection before adding a third cache tier, as it doubles the preloading and storage cost.
04
Keep cache invalidation synchronized
When a post is updated and the cache is cleared, all device-tier cache files for that URL must be invalidated simultaneously. A desktop cache clear that leaves the mobile cache stale will serve outdated content to mobile visitors until their cache TTL expires.
Code Example
# Single cache for all visitors:
# Desktop user populates /cache/page.html
# Mobile user receives desktop HTML from /cache/page.html → layout broken// WP Rocket: Settings → Cache → Mobile Cache → ✓ Enable caching for mobile devices
// LiteSpeed Cache: Cache → Cache Control Settings → Separate Mobile Cache → On
// Custom implementation with Nginx:
map $http_user_agent $cache_dir {
~*(Mobile|Android|iPhone) "mobile";
default "desktop";
}
fastcgi_cache_key "$cache_dir$request_uri";User-Agent-based mobile detection is imperfect — some tablets report mobile user agents, some mobile browsers report desktop agents. For sites where this distinction matters critically, consider CSS-only responsive design (no server-side UA detection) and skip the separate mobile cache entirely.
Limitations
- User-Agent parsing is notoriously unreliable — new devices, browser updates, and desktop-mode browsers on tablets can confuse UA-based detection.
- A separate mobile cache doubles cache warming time and storage requirements. For sites where mobile and desktop HTML are identical (pure CSS responsive design), this technique provides no benefit.
- If a CDN sits in front of your server, it must also respect the
Vary: User-Agentheader or its own device detection — otherwise the CDN will serve desktop cache to mobile users regardless of the origin cache setup.
Common Mistakes
Enabling separate mobile cache when the theme uses CSS-only responsive design
If your theme delivers identical HTML to all user agents and relies entirely on CSS media queries for layout, a separate mobile cache adds complexity and storage cost with no benefit. Enable it only when the server actually serves different HTML to mobile visitors.
Not warming the mobile cache after clearing
Cache preloading tools that crawl your sitemap must explicitly request pages with mobile user agents to populate the mobile cache. A desktop-only crawl leaves the mobile cache empty — mobile visitors hit PHP on every request until the mobile cache is warmed.