Logged-In User Cache
Cache pages for logged-in users instead of bypassing cache for every authenticated request.
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 33% of SI's share of the Lighthouse score.
This technique can move up to 100% of TTFB's share of the Lighthouse score.
Overview
By default, all major page cache plugins bypass the cache entirely for logged-in WordPress users. This is a safe default — logged-in pages often contain personalized content like admin bars, user-specific data, and WooCommerce cart states. However, for sites where logged-in users see largely the same content (membership sites, communities, e-learning platforms), a dedicated user cache can serve cached responses to authenticated visitors while correctly personalizing dynamic elements via fragment caching or client-side API calls.
Impact grade, A+ to D: how much of the Lighthouse score this technique can move. Unaffected: TBT, CLS.
The Problem
A membership site with 5,000 active logged-in users receives no benefit from page cache under the default configuration. Every page view from every logged-in user executes full PHP and queries the database, producing a server load profile equivalent to having no cache at all. On days with high concurrent logged-in traffic — live events, course releases, community announcements — the server must handle every single request as a cold, uncached PHP execution.
Performance Impact
LCP
High
the same cache-speed benefits apply to the LCP element for authenticated users
FCP
High
logged-in pages served from cache instead of full PHP execution per visit
SI
Moderate
faster page delivery for authenticated users means viewport fills sooner
TTFB
500ms–2s
server response time drops from PHP execution time to cached file read time
Risk: Medium
personalized content requires fragment or client-side loading to avoid serving wrong data
How it works
01
Cache the static shell, personalize dynamically
The approach that scales best is caching the full HTML page for logged-in users — minus personalized fragments — then fetching dynamic elements (cart count, user avatar, notification count) via a lightweight authenticated AJAX or REST API call after page load. This is how major e-commerce platforms handle millions of logged-in sessions.
02
Per-user cache with cache key including user ID
An alternative is to include the user ID in the cache key, generating one cached page per user per URL. This is feasible for small user bases but scales poorly — 5,000 users × 100 pages = 500,000 cache files to warm, store, and invalidate. Only practical for sites with small, known user groups.
03
Role-based cache groups
For sites where users in the same role see identical content (e.g., all Subscribers see the same homepage, all Instructors see the same dashboard), cache per role rather than per user. The cache key includes the user role, producing a small number of cached variants rather than one per user.
04
WordPress nonce handling
WordPress nonces embedded in forms are user-session-specific and expire after 12–24 hours. A cached page with a stale nonce will cause form submissions to fail. Regenerate nonces via a small AJAX call on page load rather than embedding them in the cached HTML.
Code Example
// Default WP Rocket behavior
// Logged-in users: cache BYPASSED entirely
// Every page load = PHP + DB execution// Enable user cache in WP Rocket: Settings → Advanced Rules → Cache for logged-in WordPress users
// Personalize dynamic fragments after load (vanilla JS)
document.addEventListener('DOMContentLoaded', function() {
fetch('/wp-json/my-plugin/v1/user-data', {
credentials: 'same-origin'
})
.then(r => r.json())
.then(data => {
document.querySelector('.cart-count').textContent = data.cart_count;
document.querySelector('.user-name').textContent = data.display_name;
});
});The REST API call for user data adds a small request but eliminates the cache bypass for the full page load — a favorable trade when pages take 800ms+ to generate uncached.
Limitations
- Nonces embedded in cached HTML expire — form submissions, AJAX requests, and any security-validated action will fail for users who load an old cached page with an expired nonce.
- WooCommerce cart and checkout pages must be excluded from user cache — per-user cart state cannot be shared across sessions.
- Per-user cache files consume significant disk space and require careful invalidation when the user’s permissions or profile data change.
Common Mistakes
Caching the WooCommerce cart, checkout, and account pages
These pages contain session-specific data that cannot be safely cached. Always add them to the cache exclusion list by URL pattern — /cart/, /checkout/, /my-account/ — even when user cache is enabled globally.
Embedding WordPress nonces in cached page HTML
Nonces are time-limited and user-specific. A cached page with an embedded nonce will fail security checks for any user who loads it after the nonce expires. Fetch nonces via a short-lived AJAX call at interaction time rather than embedding them in the page.