AccelerateWP is the speed path we intend for WordPress on this stack: LiteSpeed page cache, image features, and sensible defaults. A pile of cache, minify, and “speed” plugins next to it gives you two owners and a miss more often than a win. Pick AccelerateWP with LSCache, or pick a plugin stack you will actually own on a VPS. Do not run both, and do not add a page-builder combine switch on top. They do not stack cleanly. One owner for HTML cache, then Redis only if you need object cache.
curl -sI https://example.com | grep -iE ‘HTTP/|server|x-litespeed-cache|x-lsadc|set-cookie’The Server header and the LiteSpeed cache header show whether the stack is working. A screenshot of a plugin admin with a green tick is not a hit. If X-LiteSpeed-Cache always says miss, a plugin or a cookie is usually the reason—not a broken AccelerateWP install. A page-builder cookie on every visitor can turn page cache into a rumor for guests. Test the logged-out homepage first. You can leave the builder on for editors without caching every visitor the same way.
What AccelerateWP is
AccelerateWP is a first-party set of optimizations on top of LiteSpeed for accounts on this platform. Page cache is still LSCache. Images can be converted once without a second WebP plugin fighting the same files. You should not also install W3 Total Cache, WP Super Cache, and two image converters beside it. If AccelerateWP is on, turn off duplicate cache and image plugins. Measure the result, then decide what else you still need.
- Page cache belongs to LSCache through AccelerateWP on this stack.
- Image conversion should stay with one tool, not several.
- Object cache is a separate layer; use Redis when sessions or heavy dynamic data need it.
Why the plugin pile fails
Each extra plugin often wants to minify, combine, lazy-load, and purge. They purge each other. Checkout can get cached by mistake. wp-admin can receive a stale CSS brick after a “helpful” combine pass. Someone then tries to fix TTFB with more PHP workers while three minifiers still fight. The last minifier can cache-bust every page view. TTFB may look fine while LCP falls apart. Disable the pile, keep one owner, and measure again.
Object cache is Redis when you need it—that is a different layer from HTML. Page cache is HTML at LiteSpeed. Browser cache is Cache-Control on static files. Those layers stack. They do not replace each other. A plugin that claims to do all three is three chances to fight the origin.
If you already cached the cart
Turn off the extra page caches first. Restore the normal WooCommerce exclusions so cart and checkout stay dynamic. Purge, then use curl on the logged-out homepage when you want a hit, and on /checkout when you want a miss. Wordfence plus a second WAF plus Imunify is the security version of the same pile; keep one clear door for security and treat that as a separate topic.
Use AccelerateWP and LSCache for pages and images. Add Redis for objects if WooCommerce sessions need it. Disable the rest. When you publish, purge one URL when you can, not the whole site every time.
Tagged
Was this article helpful?
Be the first to rate this article.
