A Slow Checkout Page Is the Speed Problem Your Homepage Test Never Shows

Consider a composite case, put together from the kind of conversation I have with shop owners most weeks between October and Christmas. An Offaly Christmas tree grower sells cut trees online, with home delivery booked into time slots, and opens those slots on one advertised evening in November. Their homepage is quick. They have the PageSpeed Insights score to prove it, saved as a screenshot on their phone. Then the slots open, a few hundred regular customers try to book at once, and the basket and checkout pages slow to a crawl. People start ringing the yard instead.

Nothing in that score was false. It was measuring the wrong page.

I want to follow this grower through the problem, the decisions and the following season, because the pattern applies to almost every online shop on WordPress. The pages that show your products and the pages that take the money run on different rules. Most owners only ever test the first kind.

The Test That Said Everything Was Fine

The grower did what nearly everyone does. They typed the homepage address into PageSpeed Insights, got a score in the green, and moved on to the next job.

Google's own documentation explains why that is a narrower test than it looks ^[5]. The lab score comes from a simulated load of one page, on one device, over one fixed set of network conditions. The real-visitor data shown underneath only covers that exact address if enough people have visited it. If they have not, PageSpeed falls back to a figure for the whole site. A checkout that gets busy on one evening a year rarely builds up enough visits of its own to be reported separately, so its slowness is blended into a site-wide average or never shown at all.

Testing the Window, Not the Till

I made a version of this mistake for years. When a customer asked whether their shop was fast, I would open the homepage on my phone and give an answer. I never once put anything in the basket, and I gave that answer more than once.

So what does that mean for you? Your speed test is a test of the shop window. Nobody has tested the till. If you want the longer explanation of why scores and real experience drift apart, we have covered the gap between a PageSpeed score and what real visitors actually experience separately.

Why the Till Cannot Be Pre-Printed

Think of a café that prints its menu once and hands the same card to every table. Fast. Cheap. Nobody waits for a menu. Now think of the docket the waiter writes for each table, which has to be written fresh every time because no two orders are the same. Page caching is the printed menu. The server builds a page once, keeps the finished copy and hands that copy to the next few hundred visitors. Product pages, the homepage, the "about us" page: they look identical for everyone, so a stored copy works perfectly. That is why the shop window feels quick.

The basket is the docket. So is the checkout, and so is the customer's account page. WooCommerce's own developer documentation says those three pages "need to stay dynamic since they display information specific to the current customer and their cart", and tells shop owners to make sure caching tools exclude them ^[2]. If they were cached, one customer could be shown another customer's basket. Nobody wants that.

This is the consequence the speed test never mentions. Every customer who reaches your checkout is asking the server to build the page from scratch. All of them. At the exact moment they are most likely to hand you money.

When the Basket Switches the Cache Off

It can go further than three pages. Server caching rules commonly watch for the shop's cart cookie, and on some setups a visitor who has something in their basket stops being served cached copies elsewhere too. The customer who adds a tree and then wanders back to look at stands and lights may be browsing an uncached shop for the rest of the visit. Whether that happens on your site depends on how your host has written the rules, so it is a fair question to put to them.

What the Server Does When There Is No Copy to Hand Out

When a page cannot come from the cache, the server has to assemble it. It starts WordPress, loads the shop plugin and every other active plugin, then asks the database for the customer's session, what is in the basket, the prices, the delivery options and the tax settings. Only then does anything travel back to the phone in the customer's hand.

The time that takes shows up in a measure called time to first byte. Google's web.dev guidance treats 0.8 seconds or less as good and anything over 1.8 seconds as poor, while describing those numbers as a rough guide rather than a hard rule, and noting that time to first byte is not itself one of the Core Web Vitals ^[4]. A cached homepage on decent hosting clears that bar without trying. A checkout built from scratch on a crowded server is where it starts to slip.

The Evening the Slots Open

Now add the evening itself. Hundreds of people, all in the checkout together, all needing a freshly built page. A server works through requests with a limited number of workers, and when those workers are busy, new requests wait their turn. The customer never sees a queue. They see a page that has not arrived yet, so they tap the button again.

The grower's evening went the way these evenings go. Some customers got as far as payment and gave up when it stalled. Others tapped twice and booked the same slot twice. The phone in the yard rang without a break, and the shop's Facebook page filled with people asking whether the website was down. It was not down. It was busy building the same page for everyone, one at a time, and every lost booking that night went to whichever grower down the road had a till that worked.

What a Setup Built for the Till Looks Like

A hosting setup that copes with a busy checkout does three things, whoever provides it.

1. It keeps every cacheable page cached, so the server's effort is saved for the pages that genuinely cannot be stored.
2. It holds frequently requested database answers in memory. That is what object caching does: building a checkout page stops meaning the same questions sent to the database hundreds of times in a minute.
3. It runs PHP on a stack tuned for WordPress, rather than a general-purpose shared server where your shop competes with everyone else's.

That is the standard we built Web60 to meet. The Nginx, FastCGI and Redis caching stack Web60 runs on Irish infrastructure uses FastCGI page caching for the shop window, Redis object caching for the pages that cannot be cached, and PHP-FPM handling the work in between. In practice, when a customer's checkout asks for prices and delivery settings, the answer comes back from memory instead of waiting on the database, and the till arrives while the customer is still in the mood to pay.

For the wider picture of how each layer fits together, our complete guide to WordPress performance for business owners walks through it from the ground up.

The Weight the Shop Added Itself

Not all checkout slowness belongs to the server. Shops pile things onto the most important page they have, usually one plugin at a time, and nobody adds it all up.

Payment Scripts

If you take card payments through Stripe, its documentation recommends loading the Stripe.js script on every page of your site, not just the checkout, so its fraud detection can watch for suspicious behaviour as people browse ^[6]. That is a reasonable trade, and I would not strip it out. But it is worth knowing it is there, because it means the payment provider's code is part of every page your customers load, not only the last one.

The Little Basket in the Header

For years WooCommerce loaded a script called "cart fragments" on every page, so the basket icon in the header could update itself. From version 7.8 it only loads where a cart widget is actually shown, and WooCommerce's developers explained the change plainly: those background requests could put a strain on busy stores ^[3]. Some themes still put that widget on every page. When they do, each page view sends a request the cache cannot answer, which is precisely the load you were trying to avoid.

Plugins That Live on the Checkout

Delivery-slot pickers, upsell boxes, gift-message fields, address lookups, a live chat bubble. Each one may be useful. But every one of them can also add database queries or scripts to the one page that cannot be cached. On the grower's site, a "customers also bought" box and a chat widget that nobody answered after six o'clock were both running on the checkout. Neither was earning its place there.

Five Checks Before Your Next Busy Evening

The grower's fix was not one big change. It was a short routine, done a few weeks before the season, that any shop owner can repeat.

1. Verify the real journey. On your own phone, on mobile data, add a product, open the basket and go to the checkout, stopping before you pay, and time each step; the homepage score tells you nothing about this.
2. Audit the checkout dependencies. List every plugin and script that appears on the basket and checkout pages, and remove anything that is not genuinely helping a customer finish their order.
3. Clone to staging first. Make those changes in a staging copy of the site, so that if a plugin conflict breaks the checkout, it breaks the copy and not the shop.
4. Deploy well ahead of the rush. Push the changes to production a week or more before the busy evening, then place a real small order yourself to confirm everything still works end to end.
5. Verify on the night. Once the rush starts, have someone place one more small order, so you hear about a problem from your own test rather than from a customer's Facebook comment.

What Faster Hosting Cannot Fix

I would be overselling if I told you good hosting solves every slow checkout. It does not, and you should know where its limits are before you spend money chasing the wrong thing.

The bank step is not yours. Many card payments in Europe now ask the customer to approve the purchase in their banking app, and the seconds they spend doing that belong to their bank, not your server. A badly built plugin that runs a heavy database query on every checkout will be faster on good hosting, but it will still be the slowest thing on the page, and the honest fix is to replace it. And every server has a ceiling. If demand on one evening is many times anything your shop sees for the rest of the year, staggering the opening (by delivery area, or across two evenings) is a business decision that no amount of infrastructure replaces.

Where a Different Setup Is the Better Call

There is one kind of shop I would point elsewhere. If your whole business is built around drops where thousands of people try to buy the same limited item in the same minute, think ticket releases or limited-edition product launches, then a hosted commerce platform or an enterprise managed host with automatic scaling is genuinely the better fit. Those platforms are engineered for a stampede that would overwhelm any single shop's server, and they charge accordingly.

That is not most local businesses. A Christmas tree grower, a butcher taking turkey orders, a florist the week before Valentine's: these are busy evenings, not stampedes. For them, a well-tuned WordPress stack with proper caching handles the load, and the owner keeps full control of the shop rather than renting a checkout from someone else.

How the Following Season Went

In this composite, the grower moved the shop onto hosting with object caching, stripped the upsell box and the chat bubble off the checkout, ran the plugin updates in staging a fortnight early, and opened the slots on the same advertised evening. Bookings went through. The phone in the yard was quieter. Duplicate bookings, which had taken days to untangle the previous year, mostly disappeared.

There is research behind why that matters beyond one evening. In a study Google commissioned from Deloitte, covering 37 European and American brand sites and more than 30 million user sessions, a 0.1 second improvement in mobile speed went with roughly 8% more conversions on retail sites ^[1]. Treat that as a direction rather than a promise, because those were large brands and a small shop's numbers will vary in both directions. The detail most people skip is the important one: the gains only appeared when every page across the user journey got faster, not just the first one. The homepage alone was never going to be enough.

Conclusion

A green score on your homepage tells you the shop window is in good order. It says nothing about the till, which is the one page that has to be built fresh for every customer and the one page where a delay costs you the sale outright. The fix starts with a stopwatch and your own phone, not a speed tool. If you want to see how a shop behaves on a stack built for that work, Web60 sets up a full WordPress site in about a minute for €60 a year, with WooCommerce available like any other plugin, and you can put something in the basket and time it yourself.

Before your next busy evening, put a product in your own basket, walk it to the checkout and time it. Whatever that number is, it is the one your customers are living with.

Frequently Asked Questions

Why is my WooCommerce checkout slow when the rest of my site is fast?

Because the rest of your site is probably being served from a page cache and the checkout cannot be. WooCommerce says the cart, checkout and account pages must stay dynamic because they show information specific to each customer, so the server builds them from scratch on every visit. Slow hosting, heavy plugins and extra scripts on those pages all show up there first.

Should I cache my checkout page to make it faster?

No. WooCommerce's documentation says caching tools should exclude the cart, checkout and my account pages. Caching them risks showing one customer's basket or details to another. The right approach is to make the server faster at building those pages, through object caching and a well-tuned hosting stack, and to remove unnecessary plugins and scripts from them.

How do I test the speed of my checkout page?

Do it by hand. Online speed tools visit your site as a stranger with an empty basket, so they rarely see the real checkout. On your own phone, using mobile data rather than office wifi, add a product to the basket, open the basket, go to the checkout and stop before paying. Time each step. Repeat it after any plugin change, and again on your busiest evening.

Does a slow checkout affect my Google rankings?

Directly, rarely. Checkout pages are not usually pages you want ranking in search. The bigger cost is lost orders. Indirectly, Google gathers real-visitor speed data across your site, and where a page has too few visits of its own, PageSpeed Insights reports a figure for the whole site instead, so a slow checkout is not completely invisible.

Will Redis object caching speed up my checkout?

It helps, often noticeably, because it keeps frequently requested database answers in memory instead of asking the database the same questions again and again. It will not fix a badly built plugin, a heavy theme or the time a customer spends approving payment in their banking app. Think of it as removing the server's share of the delay, not every delay.

How many plugins is too many on a checkout page?

There is no safe number. One poorly written plugin can slow a checkout more than ten well-built ones. Judge each plugin by whether it helps a customer finish their order. If it does not, such as an upsell box nobody clicks or a chat widget nobody answers, take it off the checkout.

Sources