Speed Up WooCommerce: From 6 Seconds to Under 1

A slow store does not fail dramatically. It leaks. Conversion drops a little, bounce rises a little, Google notices, and six months later the owner cannot explain why a site that looks the same as last year sells less. WooCommerce has a reputation for being slow that it only half deserves — the platform is fine, but the default way stores get assembled is not. This is the process we actually follow, in order, when a store arrives loading in six seconds.

Measure properly before you touch anything

Almost everyone optimises the wrong thing because they measured the wrong way. Test from a device and connection like your customers', not from a fast laptop on office broadband, and test the pages that matter: a product page, a category page with filters, the cart, and the checkout. Those four behave completely differently, and the homepage — the page everyone tests — is usually the least representative. Record Largest Contentful Paint, Interaction to Next Paint and the total number of requests for each, then keep that as your baseline. Without it you cannot tell improvement from coincidence.

Start with hosting, because nothing else can compensate

If your server takes 1.5 seconds to produce the HTML, no amount of front-end work will save you. Check Time To First Byte on an uncached page. Cheap shared hosting, an outdated PHP version and a database on a congested neighbour will each cost you more than every image optimisation combined. Move to hosting with adequate PHP workers for your traffic, run a current PHP release, and make sure object caching is available. This is the least exciting recommendation in the guide and the one with the largest effect on a genuinely slow store.

Caching, and the parts of a store you must never cache

Page caching turns a database-driven page into a static file, and on a content page it is transformative. Stores are more delicate: the cart, the checkout and the account pages are different for every visitor, and caching them causes the single worst bug in ecommerce — a customer seeing someone else's basket. Exclude those routes explicitly. Then add the two layers people forget: object caching, so repeated database queries within a single request are not re-run, and a CDN so your images and scripts are served from near the customer rather than from one city. Done in that order, a product page that was hitting the database forty times now hits it once.

The database is usually worse than you think

WooCommerce writes a lot. Expired transients, abandoned sessions, old order metadata, post revisions stacked dozens deep on every product, and the action-scheduler table that quietly grows to millions of rows are all normal on a store a few years old. Clean them, then keep them clean on a schedule rather than once in a panic. While you are in there, confirm that WooCommerce's high-performance order storage is enabled, because order lookups against the old post-table structure get slow exactly when a store starts succeeding. A database cleanup on a neglected store routinely takes a second off every page.

Images: the biggest easy win

Images are usually more than half the weight of a product page, and almost always unoptimised. Serve modern formats — WebP or AVIF — and let the browser pick. Size them to how they are actually displayed rather than uploading a 4000-pixel photograph for a 400-pixel thumbnail. Give every image explicit width and height so nothing shifts as the page loads, which protects your layout-shift score. Lazy-load everything below the fold, but never the main product image, because that is almost certainly your Largest Contentful Paint element and lazy-loading it directly harms the score you are trying to improve.

Audit your plugins honestly

The average struggling store we see runs between thirty and sixty plugins, and a handful of them are loading their CSS and JavaScript on every single page for a feature used on one. Measure, do not guess: disable plugins one at a time on a staging copy and re-measure. You are looking for two things — plugins that cost far more than the value they return, and plugins loading assets globally that should be conditional. Expect to remove a few entirely, and expect at least one surprise. This is tedious work, which is why it almost never gets done, which is why it keeps being worth doing.

Then fix the cart and checkout specifically

These pages cannot be page-cached, so they need separate attention — and they are the pages where slowness costs the most, because the customer has already decided to buy. Reduce the number of cart fragment requests, which in a default setup fire on every page load whether or not anything changed. Trim the checkout to the fields you genuinely need. Remove third-party scripts from the checkout route entirely unless they are payment-critical; a chat widget and three analytics tags on the page where money changes hands is a poor trade. If the store is leaking sales at this exact point, the wider fix is the work described in our ecommerce order growth programme, because speed is only one of the reasons checkouts fail.

Keeping it fast

Performance decays. New plugins arrive, the catalogue grows, someone uploads an enormous banner, and six months later you are back where you started. Re-measure monthly against the baseline you recorded at the beginning, set a budget you refuse to exceed — a page weight and a request count — and treat a regression as a bug rather than as something to live with. Keeping a store fast after launch is the main reason our website maintenance plans exist, because the work is small and continuous rather than large and occasional.

Going from six seconds to under one is not a single trick. It is hosting, then caching, then the database, then images, then plugins, then the checkout — in that order, measuring after each step so you know which change earned which second. Most stores can get most of the way there in a focused week. If you would rather hand it over, our WooCommerce team does exactly this work and reports the before-and-after numbers rather than adjectives; tell us your store URL and the first thing you will get back is an honest assessment of what is actually slowing it down.