WordPress caching is one of those topics where the terminology gets muddled: server-side caching, PHP opcode caching, object caching, browser caching, CDN caching. They're all different things operating at different layers of your stack. Understanding what each one does, and which ones actually move the needle, means you can make informed decisions rather than just enabling every caching plugin you come across.
By default, WordPress generates every page dynamically on every request: PHP executes, queries the database, assembles the HTML from template parts, applies filters and hooks, and sends the result to the browser. For a site receiving 100 concurrent visitors, that's 100 simultaneous PHP processes and database query sets running in parallel. For 1,000 concurrent visitors, your server is doing 1,000 times the work of a single visitor.
Caching breaks this linear relationship by storing the output of that process so it can be served repeatedly without PHP executing again. A server that struggled at 100 concurrent visitors with no cache can handle 10,000 with an effective caching layer in place, not because the hardware changed, but because it's no longer doing redundant work.
Server-side page caching stores the complete HTML output of each page and serves it directly to new visitors without invoking PHP at all. This is what LiteSpeed Cache (LSCache) does at the web server level. When a cached page is requested, LiteSpeed intercepts it before PHP even loads. TTFB drops from 200-800ms (typical uncached WordPress) to under 30ms.
This is categorically different from a WordPress caching plugin. A plugin like W3 Total Cache or WP Super Cache still boots PHP on every request, it just checks whether a static HTML file exists and serves that instead of running all the WordPress template logic. That's faster than a full dynamic page but still requires a PHP process to start. LiteSpeed's server-level cache bypasses PHP entirely for cached pages.
The practical difference: a WordPress caching plugin might reduce your TTFB from 600ms to 150ms. LiteSpeed's server-side cache reduces it to 20-40ms. For Core Web Vitals and real-user experience, that remaining 100ms matters.
PHP compiles your source files into bytecode (opcodes) every time they're executed. OPcache stores the compiled bytecode in memory so PHP skips the compilation step on subsequent requests. WordPress loads dozens of PHP files per request, and OPcache ensures they're only compiled once per deployment rather than on every page load.
OPcache is enabled by default on PHP 5.5+ and should be active on any modern host. You can verify it's running via the PHP info page or with php -m | grep -i opcache on the command line. The default settings are adequate for most WordPress sites, but high-traffic sites benefit from tuning opcache.memory_consumption upward (128MB is a reasonable starting point) and setting opcache.validate_timestamps=0 on production servers to skip file change checking.
WordPress makes frequent database queries for the same data across a single page request: user roles, site options, navigation menus, widget settings, theme mods. The WordPress object cache stores the results of these queries in memory during a single request so they're not repeated, but by default this cache is discarded after each request ends.
Redis (or Memcached) extends this to a persistent cache that survives across requests. Once a query result is in Redis, subsequent requests get it from memory rather than the database, even across different PHP processes and different visitors. This dramatically reduces database load for dynamic pages, logged-in users, and wp-admin operations.
To enable Redis in WordPress, install the Redis Object Cache plugin and add the connection details to wp-config.php:
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );Then enable the cache from the Redis Object Cache plugin settings page. The plugin dashboard shows hit rate, cache size, and connection status, letting you verify it's working.
Browser caching tells the visitor's browser to store static assets, images, CSS, JavaScript, fonts, locally after the first download. On subsequent page views (or visits to other pages on the same site), those assets load from the browser's local cache instead of being re-downloaded from your server. This reduces load time for returning visitors and reduces bandwidth consumption on your server.
Browser caching is configured via HTTP response headers: Cache-Control and Expires. For static assets that rarely change (fonts, theme CSS), a long cache lifetime of 1 year is appropriate. For files that update more frequently, use shorter durations or cache-busting via versioned filenames. In .htaccess on Apache/LiteSpeed:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
</IfModule>A CDN (Content Delivery Network) distributes copies of your static assets across servers in multiple geographic locations. When a visitor requests your site, static files are served from the CDN edge node geographically closest to them rather than from your origin server. This reduces latency and removes static asset load from your origin server entirely.
Cloudflare's free plan is the most common starting point and provides CDN, DDoS protection, and SSL at no cost. It proxies your entire site, caching static assets at edge nodes automatically. For the majority of sites, Cloudflare's free tier is sufficient. BunnyCDN and KeyCDN are alternatives worth considering for higher-traffic sites or when more granular control is needed.
One important consideration: full-page CDN caching (where the CDN caches your HTML, not just static assets) requires careful cache-purging configuration so that published updates and WooCommerce cart pages are never served stale. For most WordPress sites, CDN caching of static assets only (images, CSS, JS) is the safer starting configuration.
Prioritise by impact. Start with server-side page caching, this is the single largest performance change available to most WordPress sites. Then enable OPcache if it isn't already running (it should be on any modern host). Add Redis object caching if your host supports it, especially for sites with logged-in users or complex dynamic pages. Configure browser caching headers for static assets. Add a CDN last, once the origin is already performing well.
Don't run multiple page caching systems simultaneously. If your host provides LiteSpeed Cache, don't also run W3 Total Cache or WP Super Cache, they'll conflict. One server-level page cache is what you need.
LiteSpeed with LSCache active on all HostBible plans. No plugin required to get server-side page caching working from day one.
View Hosting Plans