Short answer: Page cache stores fully rendered HTML pages to skip PHP and database queries on repeat visits. Browser cache stores static files like images and CSS on the visitor’s device. Opcode cache stores compiled PHP code to avoid recompiling scripts on every request. Each serves a different purpose and they work best together.
Key takeaways
- Page cache eliminates PHP and database calls for returning visitors.
- Browser cache reduces HTTP requests by storing assets locally.
- Opcode cache speeds up PHP execution by keeping compiled code in memory.
- Layered caching covers all performance bottlenecks.
- WordPress needs all three for optimal speed.
What you will find here
If you’ve been tuning WordPress performance, you’ve probably heard of page cache, browser cache, and opcode cache. But what’s the difference? And do you need all three? The short answer: yes, they serve different layers of your stack, and each one helps in its own way. Let me break down how they work and where each fits.
What Is Page Cache?
Page cache stores the fully rendered HTML output of a page after the first visit. When someone requests that page again, the server delivers the cached HTML instead of running PHP and querying the database. This is the most impactful cache for WordPress because it skips the slowest parts of the request.
Popular WordPress caching plugins like WP Super Cache or W3 Total Cache generate static HTML files or cache objects in memory. A caching plugin is usually the first thing you should set up after installing WordPress. Without it, every page load hits the database, even if the content hasn’t changed. That’s wasteful.
What Is Browser Cache?
Browser cache stores static files—images, CSS, JavaScript, fonts—on the visitor’s device after the first visit. When they come back, the browser loads those files from the local cache instead of requesting them from the server. This drastically reduces the number of HTTP requests and speeds up repeat page loads.
You control browser caching by setting cache-control and expires headers on your server. Most caching plugins handle this for you, or you can add rules to your .htaccess file. A common mistake is setting too short an expiration: aim for at least a week for static assets, longer for versioned files.
What Is Opcode Cache?
Opcode cache, sometimes called PHP accelerator, stores the compiled bytecode of your PHP scripts in shared memory. Normally, PHP reads a script, compiles it into opcode, then executes it. Without opcode cache, this compile step happens on every request. With it, the compiled opcode is reused, eliminating that overhead.
Opcode caching is built into PHP since version 5.5 in the form of OPcache. It’s enabled by default in most hosting environments today, but it’s still worth verifying. OPcache doesn’t cache your WordPress pages; it caches the PHP files themselves (core, themes, plugins). That makes every PHP request faster, regardless of whether a page is cached or not.
Key Differences
| Cache Type | What It Caches | Where It Lives | Primary Benefit |
|---|---|---|---|
| Page Cache | HTML output of pages | Server (disk or memory) | Skips PHP and database |
| Browser Cache | Static assets (images, CSS, JS) | Visitor’s device | Fewer HTTP requests |
| Opcode Cache | Compiled PHP bytecode | Server memory | Faster PHP execution |
When You Need Each One
Page Cache: Essential for All WordPress Sites
Any WordPress site benefits from page caching. It’s the single biggest performance gain you can achieve. Without it, every visitor triggers a full PHP and database cycle. Use a caching plugin or server-level caching like Nginx FastCGI Cache.
Browser Cache: Must-Have for Repeat Visitors
If your site has images, CSS, or JavaScript—and it does—browser caching is a must. It dramatically improves load times for returning users. Most caching plugins include this, but check that your static assets have far-future expires headers.
Opcode Cache: Already There, But Verify
OPcache is built into PHP, so you likely have it. But poorly configured values can limit its effectiveness. Check that opcache.memory_consumption is set to at least 128 MB and that opcache.max_accelerated_files covers your plugin count. You can inspect these via a phpinfo() page.
How They Work Together
Page cache handles the bulk of traffic on repeat visits. Browser cache reduces load for assets on subsequent pages. Opcode cache speeds up the initial PHP execution when a page isn’t cached. Together, they cover the full request cycle: from the visitor’s browser to the server’s PHP engine.
Think of it like layers in a cake. Page cache sits on top, catching most requests. Below it, browser cache helps with assets. At the bottom, opcode cache makes the backend faster. Missing any layer leaves performance on the table.
Common Mistakes to Avoid
One big mistake is enabling page cache without a cache-busting strategy for logged-in users or dynamic content. If you update a post but the cache still serves the old version, visitors see stale content. Most caching plugins handle this with automatic purging on post updates, but double-check your settings.
Another mistake is ignoring opcode cache because it’s “built in.” On shared hosting, OPcache settings might be too aggressive and evict scripts frequently. You can’t always change them, but awareness helps when troubleshooting slow PHP.
For browser cache, avoid setting expiration too long for assets that might change. Use versioned filenames (e.g., style.css?ver=1.2) so you can safely set long expirations. For more on caching pitfalls, see my guide on common WordPress caching mistakes.
Choosing the Right Setup
If you’re using a managed WordPress host, they likely handle page and opcode cache for you. You still need to configure browser caching yourself. If you’re on a VPS or dedicated server, you have full control. Use a combination of Nginx FastCGI Cache for page caching, OPcache for PHP, and browser headers for static assets.
For a comprehensive performance strategy, check my WordPress performance checklist. And if you’re adding a CDN, read my guide on choosing a CDN for WordPress.
Frequently asked questions
Which cache type gives the biggest performance boost for WordPress?
Page cache usually gives the biggest boost because it eliminates PHP and database queries entirely for cached pages. Without it, every visitor hits the backend even if content hasn’t changed. Browser cache and opcode cache are important too, but page cache is the most impactful to implement first.
Do I need to manually enable opcode cache?
In most PHP 5.5+ installations, OPcache is enabled by default. You might not need to do anything manually. However, it’s worth verifying that OPcache is active and that memory limits are high enough for your site’s PHP files. You can check via phpinfo() or your hosting control panel.
Can browser cache cause stale content?
Yes, if you set long expiration headers for assets that change without changing the filename. To avoid stale content, use versioning (e.g., adding a query string or fingerprint to filenames). Most WordPress plugins handle this for CSS and JS files automatically.
Is opcode cache the same as page cache?
No. Opcode cache stores compiled PHP code to speed up script execution. Page cache stores the final HTML output of a page. They operate at different layers and complement each other. You need both for optimal performance.
Should I use a caching plugin or server-level caching?
Both can work, but server-level caching (like Nginx FastCGI Cache or Varnish) is generally more efficient because it sits before PHP. However, caching plugins are easier to configure and manage from within WordPress. For most site owners, a good caching plugin is sufficient. Advanced users may prefer server-level caching.