Storefront Theme Speed: The Header Cart, Cart Fragments and the Pages No Cache Can Hold

What Storefront sends to every shopper's browser

Storefront's file list is short, and much of it is sensible. The main enqueue function in inc/class-storefront.php and the WooCommerce class beside it load a handful of stylesheets and small scripts, and the extra CSS for WooCommerce extensions such as Bookings, Brands, Wishlists or Product Bundles loads only when that extension is installed. The table shows what version 4.6.2 queues and when.

Seven font weights sounds alarming, but the browser downloads only the font files that the page's CSS actually uses. The request to Google's stylesheet is the fixed cost: another connection to another server before text can render in the brand font. The theme exposes a filter, storefront_google_font_families, for changing the families. To stop the request entirely, a child theme dequeues the storefront-fonts handle and loads self-hosted files instead.

The header cart that keeps cart fragments on every page

Look in inc/woocommerce/storefront-woocommerce-template-hooks.php and you find one line that explains most of this page: storefront_header_cart is hooked to storefront_header at priority 60, right after the product search at 40. The function prints a cart link and then renders WooCommerce's classic Cart widget as a dropdown mini cart. A filter, storefront_cart_link_fragment, tells WooCommerce how to refresh the cart count. And the theme's own scripts function enqueues wc-cart-fragments on every page, with no condition attached.

WooCommerce's developer blog describes what that script does. It calls an AJAX endpoint, get_refreshed_fragments, to bring the mini cart up to date without a page reload, and it runs on several triggers: after cart events, on a daily interval to keep several open tabs in step, when a shopper returns through the browser's back button, and inside the Customizer. WooCommerce stopped loading it everywhere in 7.8 because it caused performance trouble on stores that did not need it.

Here is the speed problem in plain terms. Your page cache can serve a product page from memory in a blink, and then the fragments script can ask PHP for a fresh cart, uncached, through WordPress and WooCommerce. On a busy store, those requests add up on the server even when every page view is a cache hit. On a blog post that never sells anything, the request is pure overhead.

Three ways to tame the header cart, mild to thorough

Whichever route you take, change it on a staging copy and walk through add to cart, the cart page and checkout before you push. If the header goes blank or misaligned after the edit, Storefront header not showing covers the hook mistakes that cause it, and Storefront CSS not updating helps when your new styles refuse to appear.

Cart, Checkout and My Account: the pages no cache can hold

WooCommerce's caching documentation tells you to exclude three pages from the page cache: Cart, My Account and Checkout. They show one customer's data, so a cached copy would show the wrong cart to the wrong person. The same guide lists the cookies a cache should respect, among them woocommerce_items_in_cart, woocommerce_cart_hash and wp_woocommerce_session_. A cache set up to respect them builds fresh pages for a shopper once something is in the cart.

That is the irony of store speed. Your most valuable visitors, the ones holding a full cart, get the pages that no cache can help. Those pages are built by PHP and the database on every request, so their speed is decided by the server, the PHP version, the database and the plugins hooked into checkout: payment gateways, shipping calculators, tax services, fraud checks. Storefront plays a small role here. The theme cannot make an uncached checkout fast; it can only avoid making it slower.

One theme-level item belongs here. Storefront 4.6.2 fixed product page timeouts on WordPress 6.9 when neighboring products shared publish dates and were hidden, a slow query in the previous and next product links. If product pages ever returned a 504 gateway timeout, check the theme version before upgrading the server. For checkout failures rather than slowness, see WooCommerce checkout not working.

A faster Storefront store in nine steps

1. 1

   Measure four templates

   Test the homepage, a category page, a product page and the cart with something in it. Use PageSpeed Insights for the first three and your browser's Network panel for the cart. Our speed test guide explains reading both.

2. 2

   Update Storefront to 4.6.2

   It carries the WordPress 6.9 product page timeout fix. Test it on staging with your extensions first.

3. 3

   Set page caching to WooCommerce's rules

   Exclude Cart, Checkout and My Account, respect the WooCommerce cookies, and nothing more. Over-excluding throws away the cache on pages that could have it.

4. 4

   Decide what the header cart does

   Limit fragments to shop pages, swap to the Mini-Cart block, or remove the dropdown, as described above.

5. 5

   Self-host the font

   Dequeue storefront-fonts in a child theme, serve Source Sans Pro from your own server in the two or three weights the design uses, and add font-display swap.

6. 6

   Fix the product images

   Upload photos at sensible sizes, let WooCommerce generate its thumbnails, and make sure the main product image is never lazy-loaded.

7. 7

   Audit extensions on every template

   List which plugins load scripts on product, cart and checkout pages, and remove the ones that load on pages they never serve.

8. 8

   Work on the server for uncached pages

   Current PHP, a persistent object cache if your host offers one, and a clean database. These decide cart and checkout speed.

9. 9

   Re-measure, including a real checkout

   Repeat the four tests and place a test order on staging to confirm nothing in the purchase path broke.

Core Web Vitals on Storefront's shop templates

Largest Contentful Paint on a product page is nearly always the main product photo, and on the homepage it is the hero or the first row of product images. Storefront's own stylesheets are modest, so the big levers are image size, the Google Fonts request and how quickly the server returns the HTML. A cached product page with a right-sized photo can do well; a cart page cannot be cached, so its LCP is a server question. The mechanics are in WordPress vs Next.js on LCP.

Cumulative Layout Shift creeps in from store furniture: a store notice bar that appears after load, review stars and badges from third-party widgets, cookie banners that push the page, and the header cart total changing width when fragments refresh it. Reserve space for anything that arrives late. The CLS comparison explains why late arrivals are the usual cause.

Interaction to Next Paint is about the main thread on product pages: variation dropdowns, gallery zoom and lightbox scripts, add-to-cart handlers, chat widgets and the tracking tags every store collects. The cart fragments script itself listens for jQuery events, so jQuery stays on any page that keeps it. INP on WordPress and Next.js shows how a slow tap is counted, and our Core Web Vitals theme guide compares how other themes start out.

What Storefront will not fix for you

• The theme is in critical-fix mode. Its status file limits work to critical bugs, broad-impact bugs, compatibility and release fixes, so no new performance features are coming.
• No Site Editor, no theme.json. Storefront is a classic theme; anything beyond the Customizer is child theme code, and speed changes are hand work.
• Uncached pages depend on hosting. Cart, checkout and account speed come from the server and the plugins in the checkout path, not from the theme.
• Extensions bring their own weight. Each payment, shipping, review or upsell plugin can add scripts to product and checkout pages.
• The successor is still in beta. WooCommerce announced Purple, its first official block theme, on September 15, 2026. A beta is not where a live store should move its checkout.

If the store already struggles beyond speed, our WooCommerce repair team works on live shops, and Storefront WooCommerce layout broken covers the template problems that often surface during a speed project. For settings and hooks in depth, see Storefront with WooCommerce.

When store speed justifies a Next.js build

Keep Storefront if the store is small, the tuned product pages pass Core Web Vitals and checkout feels quick on a phone. It is free, stable and built by the people who make WooCommerce. Our Storefront review says so plainly, and a simple shop with a few dozen products rarely needs more.

Speed becomes the reason to move when revenue depends on it: paid traffic landing on product pages, a large catalog, custom pricing or bundling logic that piles plugins onto checkout, or seasonal peaks the server struggles to absorb. A Next.js store prerenders catalog pages and serves them from a CDN, resizes product photos with next/image and keeps cart logic in tested code rather than plugins. It costs more to build and needs a developer for structural changes. Storefront vs Next.js and WooCommerce vs Next.js ecommerce set out the trade; Storefront to Next.js maps the move, with every product URL kept or redirected.

A cache can make browsing fast. Only the server can make buying fast.

Athena CMS includes built-in e-commerce, so staff edit products in plain fields with a real preview, and Argus watches for failing forms and slow pages. If you would rather keep Storefront and have it tuned, our theme speed optimization service works through these steps on staging. Every other theme guide is in the WordPress themes section.