Cache Everything for Everyone

Most WordPress caching tools bypass a page as soon as they see a logged-in cookie or an active basket. That protects correctness, but it also leaves some of the store’s most valuable visitors waiting for PHP, WordPress and WooCommerce on every page view.

Cache Everything for Everyone changes that safely. Eligible catalogue and content pages can remain fully cached while each visitor’s prices, stock and basket state are loaded through a per-visitor AJAX request. Other personal areas, such as wishlists, account names, loyalty balances and customer-specific notices, are identified during the survey and either loaded separately or kept outside the shared cache. The separate Cart/Basket, Checkout, My Account and any other page that shows private information stay outside the shared cache.

Visit the Super Speedy Plugins page, add any plugin to your basket, then carry on browsing the shop. No checkout is required. Eligible shop, category and product pages will still come from full-page cache while your basket count, prices, stock and other personal details are loaded separately.

Figure 1 – Basket-holder cache HIT

Exhibit A: One item in the basket, and the catalogue page still came from full-page cache.

Measured cache proof

On Dave’s own store, a shopper with an item in their basket got cached pages with an 80 ms median time to first byte (3 requests, measured 13 August 2026). All three were verified cache HITs. That’s Dave’s own site measured from Athens. A cached page’s time to first byte depends mainly on the speed of the cache service and where the visitor’s computer is, so Dave measures your store before and after rather than quoting you his.

• Technical survey and personalisation map for one WooCommerce site.
• Review of the complete plugin list, must-use and host plugins, Code Snippets and relevant child-theme customisations.
• Baseline measurements and cache-behaviour checks.
• Store-specific compatibility code in the separate consultancy plugin where required.
• Staging implementation and state-based correctness testing.
• Production deployment and immediate post-launch verification.
• A concise handover covering changes, exclusions and verification steps.
• Three months of support for faults in the work delivered under this engagement.

Dave first scans the theme, active plugins, must-use plugins, host plugins, Code Snippets and child-theme customisations to find everything that changes by login state, customer, country, role or basket. That includes pricing, stock, menus, wishlists, loyalty balances, side baskets, recently viewed products, customer-specific notices and cookies set while a page is being generated.

Where a theme or plugin outputs personal information into a cacheable page, Dave adds store-specific compatibility code inside a separate consultancy plugin. That code can load personal output after the cached page arrives, keep a genuinely private page outside the shared cache, defer a cookie to a per-visitor request or configure the cache around a real exception.

The resulting setup is tested as a guest, a logged-in customer and a customer carrying a basket before it is allowed to go live. A mass-market plugin cannot safely guess these details across every possible WordPress stack, which is why this is a fixed-scope implementation service rather than a one-click setting.

This refers to the separate Cart/Basket page, not to browsing after an item has been added. Eligible shop, category, product and content pages can still come from full-page cache for a visitor carrying a basket. Side baskets, mini-carts and fast-cart panels are personal parts of the page and are loaded separately. Product filters, searches, currency selectors and other options that genuinely change the requested content also stay uncached. Normal Facebook, Google, email and other tracking links do not stop an otherwise eligible page being cached.

Supported systems include WP Rocket, W3 Total Cache, LiteSpeed Cache, Nginx FastCGI cache, Varnish, Cloudflare APO and Cloudflare Cache Rules. For host-managed caching, Dave checks that the required controls and cache-response headers are available before accepting the store. He needs access to configure the safe cache inclusions and exclusions, clear old copies and confirm that the correct page is being served.

The implementation already covers standard WooCommerce sale prices, stock, Add to Cart state, basket counts, classic mini-carts, tax and geolocation rules, simple and variable products, Advanced Dynamic Pricing and Super Speedy Country Based Prices. The underlying system supports classic and block themes, although the store’s actual theme is always tested.

Other pricing, membership, wishlist and customer-specific plugins are not assumed compatible. Dave checks the installed version and either reuses an existing compatibility recipe, adds store-specific code or keeps the affected page outside the shared cache.

Scope: send Dave the plugin list and confirm that the store is accepted before purchasing. Once accepted, the price is exactly €1,450 excluding VAT where applicable, even if safe delivery needs more work than anticipated. A store outside these boundaries needs a separate scope and price.

Dave takes the delivery-time risk: if an accepted store needs more compatibility work than expected, the fixed price does not increase. The aim is to cache every eligible page a shopper browses, including after they have added products to their basket or logged in. The separate Cart/Basket, Checkout and My Account pages stay private, as do any other pages showing information meant only for that visitor. Normal Facebook, Google and email tracking links will not stop an otherwise eligible page being cached.