Slow WooCommerce cart and checkout: the server was fine, the scripts weren't

The numbers: before, after, and a recheck

LCP (Largest Contentful Paint) is the moment the main content of a page appears on screen. "Before" was measured on 25.07.2026 and "after" the same evening, once the changes were live. The recheck ran on 20.08.2026. Every run used PageSpeed Insights on mobile with a cold cache, meaning a first visit with nothing stored in the browser, and the same measurement script of mine drove each run and saved its result. The table has a score before only for the cart and the checkout. The checkout row is PageSpeed run on the checkout address, which with an empty cart redirects to the cart page; the PageSpeed section near the end explains why that matters.

Is a slow WooCommerce cart a hosting problem?

Dominik sells two books through his own WooCommerce shop, zespokojem.com. He wrote to me that the cart took 12.5 seconds to load on a phone and that it was costing him sales. My own measurement in mid-July came out a little lower, in the same range: the cart's LCP was 11.0 s, the checkout's 13.2 s and the home page's 16.2 s. The table above starts from a fresh run on 25 July, the day of the changes.

Before you blame the host, compare a light page with a heavy one on the same server. In the same audit the server answered in 50 ms, and one of the book pages, on the same server and the same WordPress install, loaded in 6.5 s. On the same hardware, the difference had to be in what each page asked the browser to download.

Why does the block cart slow WooCommerce down?

Dominik had seen what looked like duplicate scripts in the browser console and suspected them. He was right that something was doubled, but it wasn't individual scripts. The cart page loaded two complete cart systems, each with its own scripts: classic WooCommerce and the newer Cart block, which is built on React. The audit counted 88 external script files and a 537 KB document on that one page.

The block cart also builds the page differently. The server sends a skeleton and the browser assembles the cart with JavaScript, so on a phone the content you came for arrives last. The classic cart comes from the server as finished HTML.

How do you switch back to the classic cart and checkout?

On the cart page I replaced the Cart block with the [woocommerce_cart] shortcode, and on the checkout page I replaced the Checkout block with [woocommerce_checkout]. Then I styled both in the shop's own font and copper accent, so they match the rest of the site.

That alone did not get React off the cart. The shop also takes payments through a Polish gateway, separate from PayPal, and that gateway's plugin added its own block checkout script to every page, whether the page used blocks or not. The script pulls React in as a dependency. I prepared the changes on a copy of the shop, and there the cart still carried 108 script tags after the switch. That is a different count from the audit's 88: it includes inline scripts, not only external files.

How do you reduce unused JavaScript on a WooCommerce cart?

Start with a list of what the cart page actually loads. On this one the audit found the full PayPal SDK, seven scripts from the Polish gateway, and product page scripts, including variations and a jQuery UI date picker. The Facebook Pixel and its Conversions API added around 250 KB. The checkout page made 250 network requests.

The switch took care of the PayPal SDK: the classic cart doesn't load it at all, so after the switch it arrived only on the checkout.

For the rest I wrote a small plugin that keeps its rules in code rather than on a settings screen, so an update or an import can't quietly reset them. When I handed the shop back, the gateway's payment script and stylesheet loaded on the checkout only, the product page scripts on product pages only, and the gateway's block checkout script nowhere, since the shop no longer used blocks.

WooCommerce's block stylesheet, wc-blocks-style, needs one extra step. A plain dequeue does nothing, because WooCommerce adds it again while it renders the page, so it has to be deregistered.

On my copy of the shop this took the cart from 108 script tags to 31, and the home page from 108 to 31 as well. The rules name specific scripts, so anything they don't name still loads. The Facebook Pixel wasn't among the named scripts, and I kept WooCommerce's small add-to-cart script everywhere on purpose. A plugin installed later isn't covered either: it loads wherever its author set it to load until someone adds a rule with its script name.

A few other things came off along the way. I replaced the gift-wrap plugin with a few lines of my own code, so the product page got lighter as well. A doubled header and footer, caused by an Elementor HTML block sitting on top of the theme's own, disappeared from five pages. Google Analytics came back as one small snippet.

Did the cart slow down again after updates?

Not as far as I measured. On 20 August I measured again with the same script: cart 2.8 s, checkout 3.3 s. On 31 August, after a round of plugin and payment gateway updates, the cart came in at 2.1 s with a score of 93.

The job was accepted on an LCP under 4 seconds for both the cart and the checkout. Both pages were under that line on the evening of the rollout and again on 20 August.

I don't look after the shop day to day, and the rules have one weak spot: a rule that names a script stops doing anything once a plugin renames that script. Nothing breaks when that happens. The page just gets heavier, which PageSpeed will show.

Does the fix help pages built in Elementor?

Partly. The home page and the two book landing pages are built in Elementor, and I left them out of the acceptance condition. The first two still got faster, from 16.2 to 9.3 s and from 15.2 to 9.8 s, because the same script load had been hitting every page. The second book's page, the lightest from the start at 4.8 s, got slightly slower, staying within half a second of where it began. A page builder decides too much of its own output for me to hold a number there, so I didn't give one.

Is PageSpeed Insights accurate for a checkout page?

On a checkout address it measures a different page. The test robot arrives with an empty cart, and an empty cart sends the visitor back to the cart page, so the run measures that redirect path. The checkout row in the table is exactly that measurement. I check a checkout with a product in it separately, with a script and a logged-out browser.

The table and the rechecks carry dates because the shop is alive. Dominik keeps adding content and plugins, and an undated speed result stops being true before anyone reads it.

What the client said