You test your online store’s homepage and it loads quickly. A product page looks fine too. Then a customer tells you checkout felt slow, or a payment page stalled. You test again and the homepage is still quick.
Both observations can be true. A store is made of different kinds of pages that work in different ways, so each can have its own performance profile. Treating “the site is slow” as a single problem often leads to guesses, such as a different plugin or a bigger hosting plan, that may not touch the real cause.
This article explains why page types differ and gives you a test plan to investigate before spending money.
Different pages do different jobs
Think of your store as having three broad kinds of page.
| Page type | What it mostly does | How personal is it? |
|---|---|---|
| Public content (homepage, categories, blog, about) | Shows the same information to everyone | Low |
| Product pages | Shows product details, perhaps stock and options | Low to medium |
| Cart, checkout, account | Shows this customer’s basket, address, shipping, tax, payment | High |
Public pages can be saved and served quickly, because everyone gets roughly the same page. That is what caching does. A cache keeps a ready-made copy and avoids rebuilding the page for every visitor.
Cart, checkout and account pages cannot work that way. WooCommerce’s own caching guidance says these pages must not be cached, because they display information specific to the current customer and their cart. WooCommerce advises excluding the cart, checkout and account pages from page caching because they show customer-specific information. Hosts and caching plugins are meant to exclude them.
So the homepage benefits from caching and checkout does not. The two are not comparable, and a good homepage result tells you little about checkout.
What can slow a checkout
Several things can add time to checkout that do not affect your homepage. None is guaranteed to be your cause. They are places to look.
- Building the page from scratch each time. Without a cached copy, the server has to run the code and database queries for each visit.
- Shipping and tax calculations. If rates come from an outside service, the page may wait for it to reply.
- Payment gateway scripts. Payment providers load their own scripts, forms and security checks.
- Stock and coupon checks. The store verifies items and discounts while the customer progresses.
- Plugins that hook into checkout. Extra fields, upsells, loyalty tools, address lookups and fraud checks each add work.
- Third-party scripts. Chat tools, tracking tags and reviews widgets may run on checkout as well.
- A busy or underpowered server. Dynamic pages place more load on the server than cached ones.
- A large or untidy database. Queries slow down as tables grow with old data.
- Logged-in versus logged-out visitors. Logged-in customers are often served uncached pages even on parts of the site that guests see cached.
These are common patterns, not a diagnosis. Your store may have none, one or several.
Why a single speed score misleads
Speed tools are helpful if you read them properly.
Google’s PageSpeed Insights reports two kinds of results. Field data comes from real Chrome users over the previous 28 days. Lab data comes from one simulated test in controlled conditions. Google notes that lab data is useful for debugging, that lab scores can change from run to run, and that the two sets of data can disagree.
Field data also needs enough visitors. Pages with little traffic may not have any, so PageSpeed Insights can fall back to site-wide data. In a store, checkout often sees far fewer visits than the homepage, so a checkout report may be thin or missing, and a sitewide figure may not describe it at all.
The takeaway: do not judge checkout by the homepage’s score, and do not trust one run of a lab test.
A page-by-page test plan
Follow this plan before you change anything. Keep notes as you go.
Step 1: define “slow”
Write down what the problem actually is.
- Which page: cart, checkout, payment step, order confirmation?
- What stage: loading the page, updating shipping, applying a coupon, pressing “Place order”?
- Who noticed: customers, staff, or a speed test?
- When: all day, or certain times?
- On which devices and networks?
“Slow” can mean a heavy first load, a delayed update after typing a postcode, or a long wait after payment. Each points to a different cause.
Step 2: test each page type separately
| Page to test | What to check | What to record |
|---|---|---|
| Homepage | Load time, any large images or scripts | Baseline, time, device |
| Category page | Load time with many products | Baseline, number of products |
| Product page | Load, option selection, add to cart response | Time to add item |
| Cart | Load time, quantity update, coupon | Time for each action |
| Checkout (first load) | Load time with items in basket | Time to usable form |
| Checkout (address entry) | Time for shipping and tax to update | Time after entering a postcode |
| Payment step | Load of payment fields, response after submitting | Time and any errors |
| Order confirmation | Load and email receipt | Time, and email arrival |
| My account | Login and order history | Time |
Repeat each test several times, at different times of day. Use a phone on mobile data as well as a desktop on office wifi. Write down the dates and conditions. Because one result can vary, a pattern across several runs is more reliable.
Step 3: test as a customer, safely
Use a test product and, where possible, test mode on your payment gateway or a staging copy of the store. Do not place real orders to test unless you can cancel and refund them, and check how your payment provider recommends testing. Never type a real card number into a test.
Test as both a guest and a logged-in customer. Differences between the two are evidence.
Step 4: separate server time from browser time
When a page is slow, ask whether the delay is the server preparing it or the browser handling it afterwards.
- If the page takes a long time before anything appears, the server is probably slow to respond.
- If the page appears but then freezes or jumps around, scripts and images in the browser are more likely.
A developer can measure this with browser tools and server logs. You can note it by watching what happens and when.
Step 5: check what runs only on checkout
Ask your developer for a list of everything loaded or run on cart and checkout: plugins, scripts, third-party services and custom code. Then look for items that don’t need to be there. Removing a rarely used feature may help more than any hosting upgrade.
Tools that profile plugin impact exist, and WooCommerce’s performance guidance mentions testing with Query Monitor. A developer should use them on a staging copy, not your live store.
Step 6: confirm caching rules
Ask your host or developer to confirm that:
- Cart, checkout and my-account pages are excluded from page caching.
- Cookies WooCommerce uses to track carts are excluded, as WooCommerce’s guidance recommends.
- Any caching in front of the site, such as a CDN or server-level cache, follows the same rules.
Public pages can be cached and these pages cannot, so speeding up checkout usually means looking elsewhere, such as plugins and scripts, server resources or the speed of outside services.
Step 7: change one thing at a time
When you do make changes, make them one at a time and retest. If you change hosting, remove a plugin and rewrite settings in one afternoon, you will not know which one helped.
What to avoid promising yourself
Be wary of:
- “Install this caching plugin and everything will be fast.” WooCommerce advises keeping cart, checkout and account pages out of page caching, so a caching plugin does not speed them up in the same way.
- Blaming a single cause before you have measured.
- Judging by one test, one device or one score.
- Upgrading hosting as the first step with no evidence.
Better hosting can help, especially for dynamic pages. But it is one possible fix, and it should follow evidence rather than replace it.
A record to keep
| Date | Page | Step tested | Device and network | Result | Notes |
|---|---|---|---|---|---|
After any change, run the same tests and add rows. This gives you before and after evidence taken under similar conditions, which is far more useful than a memory of “feeling faster”.
Who can help with what
- Your developer can check plugins, custom code, caching rules and database health.
- Your host can look at server resources, server-level caching and logs.
- Your payment, shipping and tax providers can advise on their own services.
- You can supply the clear description and test notes that make the investigation quicker.
At Vibes Design, our managed hosting includes performance optimisation along with updates, security monitoring, daily backups, uptime monitoring, troubleshooting and direct support. For an online store, we look at the page types separately, not just the homepage.
A sensible next step
Run the page-by-page table on your own store this week and record the results. You will learn which part of the journey is slow, which is the information any fix should start from.
If you would like a second pair of eyes, our WordPress support team can review your results with you. You can also read about our WooCommerce web design work.
