wp2shell: more than a month later. Confirm 6.8.6, 6.9.5, 7.0.2. Patched is not clean.

Read the advisory

WordPress caching tips that actually help

Practical WordPress caching: page, browser, object, and opcode layers, plugin setup, CDN notes, and pitfalls that serve stale carts or break logins.

Topics Hardening & checklists

Lars Koudal

Lars Koudal

Updated Published

Caching stores work you already did so the next visitor does not pay full PHP and database cost again. Done right, pages feel faster and the server stays calmer under traffic. Done wrong, people see stale carts, broken admin screens, or “I updated the post and nothing changed.”

WordPress caching tips

Related speed reading: 7 ways to improve blog speed. Security still matters alongside speed: WordPress security guide.

Caching layers (pick more than one)

  • Browser caching: static assets (CSS, JS, images) live on the visitor’s device with expiry headers
  • Page caching: full HTML responses served without bootstrapping WordPress for every anonymous hit
  • Object caching: reuse query results and expensive objects in memory (Redis/Memcached help on busy sites)
  • Opcode caching: PHP stores compiled bytecode (OPcache). Usually a host setting, not a plugin toggle
  • CDN / edge caching: copies of static (and sometimes HTML) closer to visitors

Server-side caches and reverse proxies (Varnish and similar) sit in front of WordPress on some hosts. Ask your host what they already enable before stacking three plugins that all claim “full page cache.”

Set up a caching plugin without drama

  1. Back up files and database first.
  2. Choose one primary page-cache plugin: WP Rocket, W3 Total Cache, WP Super Cache, or your host’s recommended stack. Avoid running two full-page caches at once.
  3. Run the setup wizard if it exists (page cache, browser cache, basic minification).
  4. Confirm compatibility with your security plugin and e-commerce rules.
  5. Test logged-out homepage, a post, cart/checkout (if any), and wp-admin.

Fine-tune after the basics work:

  • Cache lifetimes that match how often you publish
  • GZIP/Brotli compression (often at the host)
  • Minify CSS/JS carefully; test forms and builders after
  • Exclusions for carts, account pages, and highly personalized views

Measure with PageSpeed Insights, GTmetrix, or WebPageTest. Change one thing at a time.

Tips that move the needle

  • Hosting first. Cheap shared plans with no OPcache and slow disks undo clever plugin settings.
  • Images. Compress, serve sensible sizes, consider WebP/AVIF. Lazy-load below the fold.
  • Fewer plugins. Bloated stacks cost more than a missing minify checkbox.
  • Database hygiene. Spam comments, old revisions, and transients add drag. Tools like WP-Optimize help; Database Optimizer is relevant if you use Security Ninja Pro modules.
  • CDN. Cloudflare or similar for static assets and global reach. Tune cache rules so HTML is not stale where it must be fresh.
  • Limit post revisions in wp-config.php if revision bloat is real:
define( 'WP_POST_REVISIONS', 5 );
  • Purge on publish. After big updates, clear page cache (and CDN if needed) so editors trust what they see.

Common pitfalls

MistakeFix
Caching carts or dashboardsExclude dynamic/authenticated URLs
Never purging after deploysAutomate purge on publish; manual purge after major changes
Plugin fightsOne page cache; staging tests before production
Misconfigured CDNReview origin headers and HTML caching rules

Security note

Caching is not a security control. Keep core, themes, and plugins updated. Pair performance work with a security plugin such as WP Security Ninja for tests, monitoring, and hardening. Faster malware is still malware.

Bottom line

Use layered caching, one clear page-cache owner, sensible exclusions, and measurement. Host quality and lean plugins matter as much as the cache TTL slider. Start simple, then add Redis, Varnish, or aggressive minification only when you can verify the gain.

Found this useful? Share it.

Larger screenshot