Astra speed optimization for WooCommerce

Open the network panel on a product page, disable cache, and sort by transfer size. Then attribute every request to one of three buckets: theme, page builder, plugins. Fifteen minutes, and it decides everything that follows. On a healthy Astra store the theme bucket lands under 50KB. If your total page weight is 2MB and the theme is 40KB of it, the useful work is entirely in the other 1.96MB — and if a consultant proposes theme tuning after seeing that split, they have not looked.

• Disable cache and record transfer size, not resource count
• Attribute each request to theme, builder or plugin
• Record the number before any change so you can prove the delta
• Repeat on a category page — the mix is usually different

Astra has settings that are off by default under WordPress Dashboard → Astra → Settings → Performance, and a surprising share of stores have never been there. The one that matters most is loading Google Fonts locally: it downloads the fonts to your own server, which removes a third-party connection from the critical path and settles the GDPR question about Google's font CDN at the same time. This is a five-minute change with a measurable effect on LCP for any store whose headline text uses a webfont. Check it before anything more ambitious.

The astra-addon plugin ships as a bundle of modules that can be enabled and disabled individually, and that control is the main reason Astra stays lean when it does. It also means the modules are enabled by whoever set the site up, often all of them, and then never revisited. Go through the list and turn off anything the store does not visibly use. Each disabled module removes its assets from every page load, not just the pages that would have used it. A module nobody can point at in the live storefront has no defence for staying enabled. The usual finds are a slider module for a slider removed two years ago, and a WooCommerce feature nobody can locate on any page.

Astra ships no builder, so whatever is producing your pages is a separate product with a separate performance profile. Elementor stores carry the most weight and also have the most recoverable headroom: its performance experiments are off by default, and enabling conditional Swiper loading alone saves 26.7KB of CSS on any page without a carousel. Spectra and core blocks are the lightest case and usually need nothing. Beaver Builder sits in between. Work out which one you have before reading any generic advice, because the fixes do not transfer between them.

• Elementor: enable the performance experiments before concluding anything
• Spectra and core blocks: usually already fine, look elsewhere
• Beaver Builder: check module-level asset loading
• Mixed sites: measure a page from each builder separately

Starter Template imports install more than a design: a slider plugin, a forms plugin, a widget pack, a builder. The import needs PHP memory raised to at least 256MB to complete, which tells you how much it puts in place. Audit that list against what the storefront visibly does today.

A page cache serves stored HTML and improves your lab scores immediately. It does not reduce the CSS and JavaScript the browser still parses and executes, which is what INP measures, and it does nothing for the first visit to an uncached URL — on a large catalog, most product pages. Good LCP with poor INP in field data is the signature: cached HTML arriving fast, then the main thread stalling on scripts the cache never touched.

Be honest about the ceiling. If the theme bucket is already under 50KB, every remaining optimization is happening in the builder and plugin layers, and there is a floor below which those cannot go while they remain installed. When the store has done the settings pass, disabled unused modules, enabled the builder's own performance features and fixed images, and field data is still red on mobile, further tuning is not worth the time — the remaining weight is structural. That is the point where replacing the frontend becomes a real option rather than an upsell, and not before it.

It is worth ending on the least interesting cause, because it is the most common one. An unoptimized hero image, a product gallery serving 2000px files to a 400px viewport, or a logo shipped as a 300KB PNG will dominate every measurement discussed above. Serve WebP or AVIF, size images to their display dimensions, set explicit width and height to stop layout shift, and mark the hero with fetchpriority so it does not queue behind decorative assets. Until that has been done, theme tuning is a distraction from the thing actually costing you the metric. On a good number of Astra stores this alone closes the gap, and it costs an afternoon.