Speed and caching

The bar adds one small stylesheet and one small script, minified, together about 8KB as a browser downloads them, and only on pages where it can actually appear. The label in the product lists needs the stylesheet alone, on the shop, category, tag, search and product pages when a label can appear there at all (not where your free shipping needs a coupon, for instance), and elsewhere on a page that draws one. There is no third-party request unless you choose a Google font, and no tracking of any kind. A Google font is loaded so that the page never waits for it.

The room a pinned bar keeps at the edge of the screen is set as the bar is drawn, by a class on the page's root element, rather than by a rule the browser asks about the whole page again whenever anything on it changes. On a test page of 1,500 products that rule cost about 125ms of the browser's style work for 300 small changes elsewhere on the page; the class costs about 3ms.

With the bar switched off under Setup, the label in the product lists is off too, and costs nothing: no product in a list is looked at for it.

Whether a cart's delivery is already free (see When delivery is already free another way) is read from the rates WooCommerce worked out when the cart last changed, and kept with the shopper's cart. It asks WooCommerce for nothing more.

On a cached site the bar is rendered into the cached page like any other markup, and then updated in the browser as soon as the cart changes — through WooCommerce's own cart refresh for the classic cart, and through the Store API for the block cart and checkout. When the cart is changed from the Mini-Cart block or a block theme's add-to-cart buttons, the script asks the Store API for the cart once per change, since those blocks keep the cart where no other script can read it. A bar with nothing to show yet — below your minimum cart total, say — keeps an empty place on the page, so it can appear the moment the cart qualifies without waiting for a page load.

The cart suggestions are worked out on the cart page, which is never cached. They ask the database once per ten minutes for each whole amount a cart can be short by, through the index WooCommerce keeps on product prices, and keep the answer; every other cart view in those ten minutes asks nothing. The answers are kept together in one row, which holds at most a hundred of them, however many different carts your visitors make. Adding one to the cart is WooCommerce's own add to cart, and nothing else is fetched from the browser. The script and styles for them come with the bar's own, on every page the bar shows on.

This next part applies in one case only: shipping zones that ask for different amounts, on a shop where WooCommerce → Settings → General → Default customer location is set to Geolocate. A browsing visitor's country is a guess there, and a cache hands the first such visitor's page to everybody after them — so the figure in the cached page is the one for your shop's own address instead, and a visitor gets their own zone's figure as soon as they have a basket or are signed in. On Shop base address, which is how WooCommerce ships, and on Geolocate (with page caching support), which gives each country its own cached copy, nothing is guessed and nothing stands in: every visitor is given a figure straight away.

After an update to the plugin, it empties your page cache once — NimbleCache, WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, WP Fastest Cache, SiteGround Speed Optimizer, Breeze, WP-Optimize and Cloudflare's own plugin, whichever you use — so cached pages pick up the new bar at once. LiteSpeed Cache is asked for its pages only: its CSS and JS files, the object cache and Cloudflare stay as they are.