Website Cache Optimisation

The root cause of website “slowness” is usually not a particular image, but ratherRequest Link + Server Generation + Static Resource Distributioncaused by superimposition:

• Users are too far away from your servers, network RTT is high (more noticeable across continents)
• WordPress runs PHP, checks the database, and renders the template for every request → TTFB (time to first byte) up
• Pages also load JS/CSS/fonts/third-party scripts, slowing down rendering and interaction.

Caching PluginThe core of the solution is to save the results of “double-counted” pages so that the server doesn't have to recalculate them every time, and to significantly reduce TTFB by allowing more users to hit the cache under the right strategy.WordPress Official DocumentationIt was also pointed out that plugins like W3 Total Cache and WP Super Cache can cache pages as static files and then serve them directly to the user, reducing the processing burden on the server.

Before reading this page, remember 3 ironclad rules

1. Page caching plug-ins at the same time only one

The most common result of enabling multiple caching plugins at the same time is not faster:

• Overriding each other's cache rules, clearing each other's caches, cache hit rate drops
• Dynamic content such as login state/language/cart/price is cached, resulting in “wrong content” incidents
  A lot of plugin documentation/instructions will suggest that when using a certain caching pluginDisable other caching pluginsto avoid conflict.

2. E-commerce/membership/multilingual sites: caching is not an “on/off switch”, it is a “rules system”.”

WooCommerce Official Performance DocumentationExplicit reminder: in the cache plugin to make sure Shopping Cart / Checkout / Account It is also recommended that JavaScript file compression be avoided (as it tends to cause compatibility issues).

3. “Cache plug-in ≠ CDN”, but the cache plug-in is the foundation of CDN

Cache plugin to solve the “source station undercount”;CDN Solve the problem of “content closer to users”. The relationship between the two is superimposed: firstly, the source TTFB is pressed down, and then the static resources are handed over to CDN for diffusion, which is the most stable route for the global users.

Quick picks: 4 of the most common scenarios for websites

If you don't want to read the whole article, you can't go wrong with the following 4 choices:

1. Want to save money, be stable, and be geared towards global access → WP Rocket(Paid)
2. Hosting is explicitly LiteSpeed/OpenLiteSpeed → LiteSpeed Cache(free but strongly dependent on server capacity): The caching function requires LiteSpeed's Server Componentswork only then
3. Content sites/blogs/document sites that want to be free and stable → WP Super Cache(static HTML cache): Generate static HTML files to provide to most unlogged-in users
4. You have technical teams to fine-tune control (CDN/object caching/multi-modules) → W3 Total Cache(strong but complex): Maintains a comprehensive performance framework with CDN integration

What exactly does the cache cache?

“Why some sites are still slow with caching”, we broke WordPress performance down into 5 layers:

1. browser cache: Make secondary access faster for users (static resource cache headers, version numbers)
2. page cache: Cache page output as HTML (main character of this page)
3. object cache: Cache database query result objects (dynamic stations are more valuable)
4. PHP OPcache: Cache PHP bytecode (usually configured by the server, not the focus of the plugin)
5. CDN/edge cache: Putting resources into nodes closer to users

The focus of this article: page caching plugin;
But you are constantly reminded that websites often need a combination of 2 + 5 to be “really fast”.

Plug-in 1:WP Rocket(Fee-based) - “Mind-saving” integrated programmes

WP Rocket is popular in the “WordPress” scene not because it's magical, but because it makes the three most common types of performance work into “manageable packages”:

• Page caching (reduces source site TTFB)
• Cache preloading/preheating (to enhance the first visit experience with globally distributed access)
• Key front-end optimisations (especially JS latency, CSS handling, etc.)

itsofficial documentIt also explicitly mentions that turning on preloading can trigger/drive certain optimisations (e.g. CSS/JS related optimisations) even if you turn off page caching.

1.1 Who WP Rocket is for

WP Rocket is especially suitable for these stations:

• Corporate website, branding site, content marketing site, landing pages (traffic from multiple countries and regions)
• I want to “go live quickly, stability first”, do not want to spell a lot of free plugin combination
• No dedicated Ops/Performance engineers, but have experience and SEO requirements
• WooCommerce It can also be used, but with more caution (more on this later in this section)Rules and Risks）

1.2 Its key value in web access scenarios (not just a “cache switch”)

A. Cache preloading: resolving “unstable first visits due to distributed access to websites”

You'll experience a very typical slowdown when site users are scattered:
A user in a region opens a page for the first time and it happens to be out of cache or never warmed up → that user incurs the full PHP/DB rendering cost.
Preloading mechanismThe significance of that is:Paying “first generation” costs up frontThe first visit of the programme will be a “guinea pig”, reducing the likelihood of a "first visit as a guinea pig".

• No preloading: whoever accesses first suffers
• With preloading: by the system in the background unified generation of cache, the first visit experience is more stable

B. Deferred JavaScript execution: the easiest feature to “feel immediate” in a website visit, but also the most risky.

WP Rocket officially puts “Delayed JS Execution” describes it as its strongest JS optimisation: it will defer script execution until after the user has had an interaction (moved the mouse, touched the screen, scrolled, pressed a key, etc.) to prioritise rendering the page.

This is important for website access because script loading and execution blocking is more likely to be amplified on cross-continental networks:

• Slower resource downloads → main thread more likely to be bogged down by scripts
• Third-party scripts (stats, ads, chat plugins) are more likely to worsen INP/interaction delays

But it can also cause problems:

• Delayed JS is likely to affect: menus, rotations, popups, form validation, payments, tracking burials
• So it's suitable for a “step-by-step + blacklist exclusion” strategy.

C. Compatibility with other plug-ins/themes: “zero conflict” is not the same as "peace of mind".”

WP Rocket has officially listed the “Incompatible plugins/themes” list, for reasons that include mechanisms such as output buffering that would affect WP Rocket caching/optimisation.

• If your site is very plugin-heavy and theme-heavy, think of “performance optimisation” as a mini go-live project: regression testing for every change (forms, logins, payments, multi-language switching, etc).

1.3 Special Reminder for WooCommerce/Dynamic Site

The core reminder from the official WooCommerce documentation when configuring the caching plugin is:

• Shopping Cart / Checkout / Account Don't cache
• furthermore, it is recommended thatAvoiding JS file compression

Why? For:

• Strong dependency on cart, checkout, account page cookie / session / nonce
• Once the cache treats these pages as “static pages”, the buttons will not work and the price/inventory/account information will be messed up.
• Here's the scary part: you could be testing fine in one region and have problems in another due to CDN/cache hit discrepancies!

1.4 Cache Plugin Strategy Level Recommendations

Tier 1: Basic Security Benefits (almost all stations should do this)

• Enable page caching
• opensCache Preloading(Enhancement of first visit stability)
• Sensible browser caching policy (WP Rocket/Server/CDN Either layer can be implemented)

Tier 2: Medium reward, medium risk (suitable for most content sites)

• Delayed loading of images/iframe (image optimisation page goes further)
• Controlling CSS volume (e.g. removing unused CSS)

Tier 3: High yield but high risk (must have regression test checklist)

• Delayed JavaScript execution (prioritises rendering, but may affect interaction)
• JS/CSS compression/merging: be extra careful with e-commerce/members/multilinguals (WooCommerce also warns about the risk of JS compression）

1.5 Prices and Authorisations

• WP Rocket is a paid licence, with different licences depending on the number of sites.

Plugin 2:LiteSpeed Cache (LSCWP)--The premise of “free tops” is that the server is really LiteSpeed.

A lot of people have the wrong idea about LiteSpeed Cache: they think it's just a WordPress plugin that you can install and get all the power on any host just like WP Rocket. It's not.

LiteSpeed Official DocumentationClear explanation: LSCWP's caching feature requires LiteSpeed Server because it communicates with the LiteSpeed Web Server's built-in page cache (LSCache); the plugin is responsible for telling the server which pages are cacheable, for how long, and for triggering cleanup with tags.

The core strength of LiteSpeed Cache comes from “Server-level page caching (LSCache)”. Without the LiteSpeed/OpenLiteSpeed servers, there is no such core advantage.

2.1 LiteSpeed Cachefor whom

Fit:

• Your hosting panel is clearly labelled LiteSpeed / OpenLiteSpeed(e.g. many cPanel hosts will write)
• You want “a free solution that can also run strong TTFB and concurrency.”
• You're willing to accept: it's very powerful, but also more conceptual (TTL, Tag, Purge, ESI, Crawler...)

Not really:

• You're not sure what Web Server the host is, or confirming that it's Nginx/Apache (unless you only want to use some of its front-end optimisation features, but then the price/performance and complexity isn't necessarily cost-effective)
• You are a complex e-commerce/membership/multi-language site, but do not have a testing process (LSCWP is strong, but it is also easier to “cache the wrong content”)

2.2 Its caching mechanism: why it's more like “part of the server's capacity”

You could write the mechanics of LiteSpeed Cache as an “engineering explanation”:

• WP Rocket / WP Super Cache This is more on the WordPress/PHP side of caching and optimisation;
• LSCWP It's a combination of the WordPress Control Panel + LiteSpeed Server's built-in LSCache: the plugin is responsible for issuing rules and cleanup signals, and the real high-speed page caching happens in theserver layer。

This has a direct impact on the website experience: server-level spit caching is usually lighter, faster, and more concurrent (especially with bursts of traffic and high-frequency visits from search engine crawlers).

2.3 The “right way” to open LSCWP for website user scenarios”

We have divided the “right way to open” into 4 levels:

Layer 1: Page Cache Policy (determines if TTFB can really drop)

• Clarify which pages can be cached (most public content pages)
• Clarify which pages should never be cached (login, account, shopping cart, checkout, language/currency switching pages that rely on strong cookie)
• Set a reasonable TTL for the cache (the more frequently the content is updated, the shorter the TTL, and the longer the TTL).
• Create a cleanup strategy: clean up relevant Tag after content update (rather than a brute force site-wide cleanup)

This layer, if done correctly, is most directly visible to the website as the TTFB down, first screen more stable。

Layer 2: Warm-up/Crawler (determines “slow first visit to a cold page”)

A common “experience inconsistency” in website access comes from “hot/cold differences” in caching:

• Popular pages are always visited and the cache is always hot
• Cold pages haven't been clicked in a long time, and first time clickers are slow

Warming up is not the icing on the cake, it's the key to a consistent website visitor experience

Layer 3: Security programmes for dynamic content (e-commerce/membership/multilingualism)

The power of LSCWP is that it gives you a lot of “advanced tools”, for example:

• Differentiated caching strategies for logged-in users, comment users, etc.
• The core idea of Edge Side Inclusion (ESI) is to split the page into "cacheable public body" and "non-cacheable dynamic fragments", which are processed separately and then spliced at the edge nodes.

Tier 4: Online Services and Optional Enhancements

Many webmasters will find QUIC.cloud's online services (e.g. on-page optimisation type services) useful in the LSCWP.QUIC.cloud DocumentationIt is explicitly written that it provides on-page optimisation services to LSCWP, including Critical CSS (CCSS), Unique CSS (UCSS), Viewport Images (VPI) and others.

• This type of service is optional: you can just use server caching and not enable online optimisation
• Once online services are enabled, your site resources/page processing links will change (this is important information for businesses/privacy sensitive customers)

2.4 LSCWP Common Pit

1. Server is not LiteSpeed, but uses LSCWP as a full-featured caching plugin
   Result: Caching is not as effective as expected and also increases configuration complexity. Solution: Confirm the host stack first; if not LiteSpeedFor example, consider WP Rocket or WP Super Cache.
2. Enabling too many front-end optimisations leads to functional anomalies
   On-page optimisations (CSS/JS) are often more likely to cause compatibility issues than “caching itself”. Suggestion: run the page cache first, then turn on the optimisations one by one, and create a list of regression tests (forms, menus, payments, tracking, language switching, etc.).
3. Lack of exclusion/slicing strategies for dynamic pages
   Typical incidents: shopping cart, checkout, account page being cached; or incorrect multi-language/multi-currency switching. E-commerce sites must consider this as a pre-launch check (and WooCommerce officials also emphasise)Don't cache key pages）。

Plugin 3:WP Super Cache(Free) - A classic “low risk, high yield” solution for content sites.

WP Super Cache Why has it been popular for so long? Because it solves problems in a very direct, very “server-friendly” way:
Generate static HTML files from dynamic WordPress pagesThe HTML files are then served directly from the web server, bypassing the expensive PHP processing.

The plugin page also mentions that: static HTML will be served to the vast majority of non-logged-in users, and gives a very intuitive statement - “99% visitors will be served static HTML files”, and a single cached file can be served thousands of times.

3.1 Who is WP Super Cache for?

Highly recommended:

• Blogs, media content sites, document sites, corporate showcase sites, landing pages
• Visitors are mainly non-logged-in users
• You want: free, stable, low maintenance costs

Use caution/need stronger strategies:

• Strongly dynamic site: lots of personalised content, pages that change according to the user's state
• Large e-commerce: it can work, but make sure key pages are not cached and work with your testing process

3.2 Its three caching methods:

The WP Super Cache plugin description lists 3 caching methods by speed and explains the differences:

• mod_rewrite (expert): the fastest, completely bypassing PHP, but need to change .htaccess, improper configuration may lead to site unavailability risk is higher!
• Simple (recommended approach): “Super cached” static files provided by PHP, close to the speed of mod_rewrite, but easier to configure.
• WP-Cache Cache: more flexible for known users, URLs with parameters, subscription feeds, etc., but slower

Recommended Choice:

• Beginners/seeking stability: use the recommended method (simple)
• You are familiar with the server rules and are willing to take the risk of rewriting them: consider the expert model again!
• You Need More Flexible “Known User/With Parameters” Handling: Understanding the Position of WP-Cache

3.3 Advantages and Shortcomings of WP Super Cache

Advantage:

1. Ideal for use with the CDN.
   Because it is essentially “generating static HTML”, this naturally fits the CDN/edge cache idea.
2. Improvements in source station CPU/database pressure are very straightforward
   Search engines and social media crawlers may also come from all over the world when website traffic is scattered. Staticisation is effective in combating “re-rendering”.

Short Board:

1. It's not an “all-in-one performance optimisation suite”.”
   It's mainly strong on page caching, and deep CSS/JS optimisations aren't as packaged as in WP Rocket. You may need to take on more in the “Image Optimisation Page” and “Frontend Optimisation Page” (or use other plugin/theme level optimisations).
2. Be more cautious about “dynamic personalisation”
   For example, showing different content by region, showing different prices/languages/recommendations by user status, etc. At this point you must either create an exclusion policy or introduce a more suitable slice-and-dice caching scheme.

3.4 WooCommerce Compatibility: Why It's “Safer”

Official WooCommerce HelpMentioned: WooCommerce is natively compatible with WP Super Cache and WooCommerce sends a message to WP Super Cache so that it doesn't cache Cart, Checkout, My Account pages by default.

• Even if you're new to WP Super Cache + WooCommerce, it's much less likely that you'll step on the “key pages cached” mine!
• However, it is still recommended to do regression testing before going live (payments, coupons, shipping, tax rates, multi-currency, etc.)

Plugin 4:W3 Total Cache (W3TC)--The most versatile “performance framework” for engineering teams.

W3 Total Cache Rather than a “single cache plugin”, WordPress.org is positioned as something more like a “website performance optimisation framework”: it emphasises improving SEO, Core Web Vitals and overall experience through CDN integration and best practices. Vitals and overall experience through CDN integration and best practices.

The plugin description lists a wide range of capabilities: page/post caching, CSS/JS caching, Feed caching, search results caching, database object caching, object caching, fragment caching (fragment cache), and support for a variety of caching methods such as Redis/Memcached/APC, but also includes mobile grouping caching by UA/Referrer, AMP support, reverse proxy (Nginx/Varnish) integration and so on.

4.1 Who is W3 Total Cache for?

Perfect for:

• You have development/operations skills and are willing to do “enablement + pressure testing + regression testing”.”
• Your site is complex: multi-language, multi-theme switching, mobile differentiation, complex content structure
• You don't just want page caching, you want to incorporate object caching/fragment caching into the system (especially for dynamic sites)

It doesn't fit:

• You want to “install and go”, you don't want to understand cache hierarchies.
• You don't have a testing process, but you want to turn on high-risk items such as compression and delayed scripts in one fell swoop

4.2 Why is it “strong but complex”: websites value “controllability”.”

The value of W3TC is not that “it must be faster than everyone else”, but that it gives you enough control knobs to engineer a performance strategy:

• Page Cache: can be in memory, on disk or CDN
• Database object cache, object cache: available Redis/Memcached, etc.
• Fragment Caching: Good for “Semi-Dynamic Pages”
• Mobile support: caching pages by referrer or user agent group respectively
• CDN Management: Transparent CDN management of media libraries, theme files, etc.

These capabilities are especially valuable for websites, where global access is frequently encountered:

• Variants of the same page on different devices, in different regions, in different languages
• Some content can be cached, some content must be real-time (e.g. price, inventory, user status)

4.3 W3TC's “Recommended Enablement Order”

Recommended Order:

1. Start by enabling page caching only
   Verify: TTFB is down, content is consistent, login state/multilingual/e-commerce key processes are working.
2. Re-enable Browser Cache
   Goal: Make return visits and static resources load faster and reduce repeated downloads across continents.
3. Reevaluate Object Cache / Database Object Cache
   Applicable: Dynamic site (WooCommerce, Membership System, Complex Query).
   N/A: Content-only stations may have limited returns or even increase resource consumption.
4. Final touch Compression / Latency Scripting / Front End Optimisation
   Because this is the layer most likely to trigger functional anomalies, a regression test list must be created (payments, forms, tracking, pop-ups, menus, language switching, etc.).

WooCommerce Reminder for “Cache Plugin Configuration”: Critical pages are not cached and it is recommended to avoid JS file compression.

Comparison matrix of the four plug-ins

Note: It's not “who's better”, it's “who's a better match for your scenario”.

dimension (math.)	WP Rocket	LiteSpeed Cache	WP Super Cache	W3 Total Cache
core positioning	Mind-saving integration (caching + optimisation)	Server-level caching (relies on LSCache)	Static HTML Caching	Performance framework (multiple cache layers + CDN)
host-dependent	Low (universal)	High (requires LiteSpeed/OpenLiteSpeed to function as core cache)	Low (universal)	Medium (universal, but more dependent on environment/configurability)
Learning costs	low-middle	Medium	低	High
Content Station Recommendation	Very high	Very high (provided it is met)	Very high	Medium-High (depending on the team)
E-commerce/membership site	Available but carefully excluded (WooCommerce key pages not cached)	Available but more need for rules/slicing strategies	is available, and WooCommerce mentions native compatibility and no caching of key pages by default	Available and suitable for engineered control
budget	cover the costs	freeware	freeware	Free + Paid Version

“Cache incidents” and prevention checklist

1. Three root causes of “wrong content” due to caching

A. Treating “stateful” pages as “stateless static pages”

Typical: account page, shopping cart, checkout page are cached.WooCommerce Officials have repeatedly emphasised Cart/Checkout/Account should not be cached.

B. Multi-language/multi-currency/regional variants are not cached correctly

If your site displays different content based on cookie, query parameters, and geographic location, then the cache must take into account “variant dimensions”. Otherwise, a cache generated by a user in region A may be reused by a user in region B.

C. Front-end optimisation (JS/CSS) rewriting leading to functional anomalies

In particular, JS compression, merging, and delayed execution.Avoiding JS file compression。

2. Pre-launch regression testing checklist

• Logging in/out is normal
• Form submissions (contact form, subscription, login registration) are working properly
• E-commerce process: add purchase → coupon → shipping/taxes → payment → order page
• Stability of multilingual switching (content, URLs, hreflang, currency after switching)
• Mobile menus, pop-ups, scrolling, lazy loading are working properly
• Track if scripts are still triggering (GA, Meta Pixel, transformation events)

common problems

Q1：Why is overseas access still slow even though I have installed the caching plugin?

The most common reason for this is that you have only solved “duplicate rendering at source”, but not “cross-continental network latency”.
Caching plugins allow the server to spit out content faster (TTFB down), but static resources (images, CSS, JS, fonts), and RTT for global links, still need to be CDN to shorten the distance.
👉 So the correct path is:Make the source station cache stable first.And then CDN for global distribution.。

Q2: Why doesn't the content update after I change it after caching?

Because you are seeing the “old cache”. Solution idea:

• Create a cleanup strategy: clean up corresponding cache after updating articles/pages (instead of site-wide cleanup)
• For scenarios with warm-up/crawlers: clean up and then warm up, otherwise the first visit will be slow
• For CDN: need to consider that CDN edges may also cache old resources

Q3: Can I install WP Rocket + WP Super Cache at the same time?

Not recommended. One page caching plugin at a time is the most stable. You can understand the idea of “one for caching and one for optimisation” as “division of labour”, but in reality they often touch page caching/resource rewriting, and the probability of conflict is high. It is more recommended to choose a “main caching plugin”, other needs with a clearer single tool to fill the gap.

Q4: Isn't it dangerous to use caching for e-commerce sites?

It's not dangerous, it's “no rules” that's dangerous.WooCommerce RecommendationsIt's very clear: cart/checkout/accounts are not cached and JS compression is avoided.
In addition, WooCommerce also mentions that it works with the WP Super Cache Native Compatibility, and avoid caching critical pages by default.
So the e-commerce site can be cached, but it has to be tested as a “live change”.

Q5: Should I choose LiteSpeed Cache or WP Rocket?

• Are you sure the host is LiteSpeed/OpenLiteSpeed?: Priority LiteSpeed Cache (free and strong, with core benefits from server-level LSCache)
• You're not sure about the hosting stack / you don't want to compromise / you want to integrate and save.: WP Rocket is more stable
• You're a content site and you're budget-sensitive: WP Super Cache is more stable and lighter.

Cache plug-in with CDN

The caching plugin solves the problem of “less counting of source stations and lower TTFB”; CDN solves the problem of “static resources and pages closer to global users”. The superposition of the two is the common optimal solution for global access.

• A common combination of content stations:Page Cache + CDN Static Distribution
• Common combinations of dynamic stations:Page Cache (tight exclusion control) + Object Cache (on demand) + CDN static distribution

👉 Read:CDN Acceleration (Global Node and Caching Policy)

Recommended combinations for website caching

1. Content site / blog / document site

Objective: Reduce TTFB, make the first screen more stable, reduce server pressure, work with CDN for global distribution.

1.1 The most hassle-free business mix

• WP Rocket (page caching + preloading + front-end optimisation)
  • CDN (go to CDN page talk)

Applicable:

• You want “low setup, fast results, low risk.”
• Themes/plugins galore, want to reduce compatibility tossing around

Points of Attention:

• Front-end optimisations (especially JS latency) are enabled in stages to avoid functional anomalies (menus, forms, tracking, etc.)
• Frequent revision/posting sites should have a “clean + warm up” strategy, otherwise the first visit to the cold pages will be slow.

1.2 Free and stable classic combinations

• WP Super Cache (static HTML cache): Generate static HTML from dynamic pages, mainly for unregistered users.
  • CDN

Applicable:

• Budget sensitive but stable
• Visitors basically don't log in
• Controlled pace of content updates

Points of Attention:

• It's a combination of “page caching first”, don't expect it to solve all CSS/JS complexities along the way!

---

2. Corporate site / brand site / landing page

Objective: Be fast, but more importantly “don't break the conversion link because of optimisation”.

2.1 Robust and controllable (recommended global placement/conversion stations)

• WP Rocket
• + (optional) light image optimisation (you have the “image optimisation” page)
  • CDN

Why it's good for conversion stations:

• Converting sites are afraid of “forms/popups/tracking scripts being screwed up by optimisation”
• WP Rocket is more “integrated” in the sense that you can enable and regress test each item in a system.

The “on-line principle” of the enterprise website:

• Performance optimisation is a “go-live change” and must have a regression test checklist
• Any settings involving JS latency/merge/compression should be verified in a pre-release environment before going live!

---

3. WooCommerce e-commerce site (orders + dynamic page security)

Objective: It is important to be fast, but also to ensure that the shopping cart, checkout, and account pages are absolutely correct.

The official WooCommerce bullet points for the caching plugin are very clear:Shopping Cart / Checkout / Account Page Do Not CacheIt is also recommended that JavaScript file compression be avoided to minimise compatibility issues.

3.1 Free and safe routes that are more “newbie-friendly”

• WP Super Cache + WooCommerce
  • CDN

Why is it listed as a “safer place to start”:

• WooCommerce officially mentions that it is natively compatible with WP Super Cache, and will inform WP Super Cache that it doesn't cache key pages such as cart/checkout/accounts by default.
• For sites starting out in e-commerce, “no accidents first” is more important than “extreme performance”.

3.2 If you're using a LiteSpeed host (free but powerful)

• LiteSpeed Cache (must be a LiteSpeed/OpenLiteSpeed host to take advantage of core server caching)
• + (optional) object caching (Redis/Memcached, depending on hosting capacity and site size)
  • CDN

Applicable:

• The host stack is clear and you are willing to establish caching rules and exclusion policies
• The volume of orders and goods is large, and a stronger source station is needed to carry the pressure.

3.3 Engineered teams/complex e-commerce (multi-module controllable)

• W3 Total Cache (performance framework, multiple cache layers integrated with CDN)
  • Object caching (on demand)
  • CDN

Applicable:

• With Dev/Ops, you can go live with “Module Step-by-Step Enablement + Pressure Testing + Regression Testing”.
• Need for fragment caching / more complex variants of the strategy (e.g. fine-grained caching by device/region/language)

---

4. Membership site / community / online courses (many logins, strong personalisation)

Objective: Make public content fast while ensuring that “logged-in user content is not strung”.

4.1 Save but need strict exclusion strategies

• WP Rocket
• + (optional) object caching (if dynamic queries are numerous)
  • CDN

Key Points:

• You must exclude from caching the “Change by user” pages: Personal Centre, Orders, Progress, Messages, Shopping Cart, etc.
• This type of site is most prone to “seeing other people's content/wrong permissions”, and the risks should be spelled out on the page.

4.2 LiteSpeed Hosting + Advanced Policy

• LiteSpeed Cache (server caching + more sophisticated policy tools)
• + (on-demand) object caching
  • CDN

Key Points:

• Membership sites tend to need more of a “cacheable body + non-cacheable fragment” mentality.
• Warm-up and clean-up strategies need to be more refined, otherwise “users still see old content after update” will be very frequent

Web cache “Demining Casebook”

Case 1: Installed the caching plugin, the speed is almost unchanged

Phenomenon:

• Local/co-regional speeds OK, overseas (cross-continental) still slow
• TTFB has improved, but overall load times have not dropped significantly

Common Causes:

• You only do source caching (TTFB), but static resources (images/JS/CSS/fonts) are still loaded from the source across continents
• Third-party scripts (ads, chat, stats) slow down rendering and interaction
• Slow downloads due to large image sizes (caching doesn't solve the “first download” size problem)

Solution Idea:

• The cache plugin takes care of “source undercounting + hits” first.”
• Static resources go CDN
• Image away image optimisation
• Third party scripts do delay/split strategies

Reading:

• CDN Acceleration: Global Nodes and Caching Strategies
• Image optimisation: format/compression/lazy loading

---

Case 2: After enabling caching, the page is changed but the frontend is not updated.

Phenomenon:

• Content/style has been updated in the backend and the old version is still displayed in the frontend
• Or only some regions are updated and others remain the same (common for global stations)

Common Causes:

• Page cache not cleared or cleared to incorrect extent
• Warm-up/crawler not running, cleaned cache gets cold resulting in slow first visit, while you mistakenly think there is no update
• If you enable CDN edge caching, the edge may also retain old resources

Solution Idea:

• Create a “clean-up strategy after release/revamp”: clean up relevant pages, not a site-wide hard clean-up
• Create a warm-up strategy for important pages (home page, core landing pages) to avoid “clean up = slow down”
• CDN Layer to do edge cleaning when required

---

Case 3: Misplaced content after multi-language/multi-currency switching

Phenomenon:

• The page still shows the previous language after switching languages
• Or users in certain regions see the wrong currency/wrong content

Common Causes:

• The cache does not distinguish between “variant dimensions” (cookie / parameters / language prefixes / subdomains).
• Cache Hit Gives Language A Page Results to Language B Users

Solution Idea:

• Clarify your multilingual programme: directories/subdomains/parameters/cookie
• Adding “variant policies” to caching rules or excluding key pages
• Some sites require more advanced “slice and dice” caching ideas (W3TC is better suited for engineering control).

---

Case 4: Problems with shopping cart/checkout on e-commerce site with caching enabled

Phenomenon:

• Shopping cart with wrong quantity, wrong price, checkout button not working
• Logging in and seeing content that doesn't belong to you (seriously)

Common Causes:

• Critical pages such as Cart/Checkout/My Account are cached.
• JS minify/merge causes payment/dynamic component incompatibility

Solution Idea:

• WooCommerce is official: cart/checkout/accounts should not be cached and it is recommended to avoid JS file compression.
• Run “page cache + exclude” first, then consider front-end optimisation
• If you use WP Super Cache, WooCommerce mentions that it is natively compatible and avoids caching key pages by default.

---

Case 5: Menu/form/popup broken after enabling “Delay JS/Merge Scripts”.

Phenomenon:

• Navigation menu won't open
• Form validation failed or could not be submitted
• Popup/Rollup Exception
• Stats/conversion events not triggering (the most painful for launch sites)

Common Causes:

• Deferred JS changes the timing of script execution: scripts are not executed until the user interacts with them, and some components rely on “initialise on page load”.”
• Merging/compression may change script order or break dependencies

WP Rocket officially describes “deferred JS execution” as one of its strongest JS optimisations: scripts are deferred until after the user interaction to prioritise page rendering. This is a great capability, but it also means a higher compatibility risk.

Solution Idea:

• Enable in stages: cache, then images, then CSS, then JS.
• Add exclusions to key scripts (payments, forms, menus, tracking)
• Do a regression test checklist for every change

---

Case 6: Only LiteSpeed Cache is installed, but it doesn't feel like it's working.

Phenomenon:

• LiteSpeed Cache is on, but TTFB isn't dropping much.
• The hits aren't obvious either

Common Causes:

• Your server is not LiteSpeed/OpenLiteSpeed and cannot use the core capabilities of LSCache
• Or maybe you enabled a bunch of optimisations for it, but the “page caching policy/preheat/exclude” wasn't created!

Solution Idea:

• Check the host stack first: is it LiteSpeed/OpenLiteSpeed (this is a prerequisite)
• Putting the focus back on “Page Cache Policy + Warm Up + Exclude + Clean Up”
• If not a LiteSpeed host: Consider WP Rocket or WP Super Cache