What is WooCommerce hosting?

Specifically, WooCommerce hosting is a server environment optimized for the unique technical demands of online stores, including sufficient PHP workers for checkout processing, object caching to reduce database load, cart and checkout pages that bypass full-page cache, and resource isolation to prevent performance interference from neighboring sites.

How many PHP workers does a WooCommerce store need?

In short, a small to medium WooCommerce store needs a minimum of 10 to 15 PHP workers to handle checkout traffic without queuing. High-traffic stores processing hundreds of simultaneous orders should look for 30 or more. Generic WordPress shared hosting plans typically allocate 2 to 6 PHP workers — adequate for blogs, but inadequate for active stores during peak traffic events.

Why can WooCommerce checkout pages not be cached?

Notably, WooCommerce cart and checkout pages contain dynamic, user-specific data including cart contents, applied coupons, shipping calculations, and payment tokens. Consequently, serving a cached version of these pages would display stale data to shoppers — causing incorrect totals, lost cart items, and broken payment processing. Every checkout request must therefore be handled by a live PHP worker.

What is object caching and why does WooCommerce need it?

In practice, object caching stores frequently accessed database query results in memory using Redis or Memcached, so repeated requests for the same data never require a new database query. WooCommerce generates 50 to 150 database queries per product page load. Therefore, object caching is essential for reducing database load and improving response times on product and category pages, where full-page caching alone is insufficient.

Does AHosting WooCommerce hosting include a dedicated IP?

Indeed, every AHosting WooCommerce hosting plan includes a dedicated IP address at no additional cost. A dedicated IP ensures your store's SSL reputation, payment gateway trust signals, and email deliverability are not affected by neighboring sites sharing the same IP. Furthermore, dedicated IPs are increasingly important for AI search citation signals in 2026, as they provide a cleaner trust footprint for ChatGPT, Perplexity, and Google AI Overviews crawlers.

What is the bad-neighbor effect in WooCommerce hosting?

Overall, the bad-neighbor effect occurs when other websites sharing your server or IP address engage in spam, malicious activity, or excessive resource consumption — and those behaviors negatively impact your store's performance or reputation. Specifically, on shared hosting without resource isolation, a neighboring site receiving a traffic spike can consume CPU and memory that would otherwise be allocated to your WooCommerce store, causing slower checkout times and higher cart abandonment rates.

What PHP version should WooCommerce use in 2026?

For most stores, PHP 8.1 or PHP 8.2 is the recommended version for WooCommerce in 2026. Benchmarks show that PHP 8.x handles significantly more requests per second than PHP 7.4 for WordPress and WooCommerce workloads. Additionally, WooCommerce officially requires PHP 8.1 as the minimum version for optimal performance and continued security support. Sites still running PHP 7.4 should upgrade immediately, as that version has reached end-of-life.

How much RAM does WooCommerce hosting need?

Typically, a WooCommerce store needs at least 256 MB PHP memory limit and 2 GB of total server RAM at minimum for a small store. However, medium stores with 100 to 500 products benefit from 4 GB of RAM, while large stores with extensive catalogs and high concurrent traffic require 8 GB or more. Generic shared hosting plans often cap PHP memory at 128 MB, which causes admin errors, slow product imports, and timeout failures during high-traffic events.

Does WooCommerce hosting affect Google rankings and Core Web Vitals?

Directly, yes. Google uses Core Web Vitals — including Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift — as ranking signals. Slow WooCommerce hosting producing a Time to First Byte above 600 ms makes a passing LCP score mathematically impossible on most pages. Furthermore, in 2026, AI search systems like ChatGPT and Perplexity prefer to cite fast-loading sources, meaning slow hosting also reduces AI search citation frequency for your store.

Is CloudLinux important for WooCommerce hosting?

Consequently, CloudLinux is highly valuable for WooCommerce hosting because it enforces strict per-account resource limits through its LVE technology. This means that when another site on the same server receives a traffic spike, your store's allocated CPU and memory remain fully protected. Specifically, AHosting uses CloudLinux with CageFS on all shared hosting accounts — providing container-level isolation that prevents the bad-neighbor effect from impacting your checkout performance.

Category: WooCommerce

WooCommerce Black Friday Hosting: The 12-Week Countdown Site: AHosting.net

What WooCommerce Black Friday Hosting Has to Survive
- The Checkout Is the One Page That Cannot Be Cached
- Why Peak Concurrency Beats Monthly Visits as the Planning Unit
Your Checkout Ceiling: The One Number Peak Planning Turns On
The 12-Week WooCommerce Black Friday Hosting Countdown
How to Rehearse Peak Load Without Taking the Store Down
- Building a Checkout Load Test That Resembles Real Buyers
- The Four Signals to Watch During a WooCommerce Black Friday Hosting Rehearsal
When WooCommerce Black Friday Hosting Needs More Than a Shared Plan
- Shared, WooStart, VPS, Dedicated: A Peak-Load Comparison
What AHosting Publishes That Makes Peak Planning Possible
- Check Your WooCommerce Black Friday Hosting Readiness
The Change Freeze and the Rollback You Hope Not to Use
A Practical WooCommerce Black Friday Hosting Checklist
Frequently Asked Questions About WooCommerce Black Friday Hosting

TL;DR

WooCommerce Black Friday hosting is decided by one number: entry processes divided by checkout execution time. Measure it in September, rehearse it in October, freeze the site in November.

Most advice about WooCommerce Black Friday hosting arrives as the same four bullets: upgrade the plan, add a content delivery network, turn on caching, take a backup. None of it is wrong. All of it is unfalsifiable, because none of it produces a number you can check your store against.

Why peak-season capacity comes down to entry processes divided by checkout execution time, and the twelve-week schedule that turns that number into a plan.

There is such a number, and your host either publishes the inputs or it does not. This post derives it, shows what makes it collapse under load, and hangs a dated twelve-week schedule off it, with an explicit go or no-go gate at the end of each stage. Black Friday 2026 falls on November 27, so the clock starts the first week of September.

What WooCommerce Black Friday Hosting Has to Survive

Peak season does not raise the amount of work your server can do. It changes the kind of work it is asked to do, and the change runs in the wrong direction. Understanding that inversion is most of what WooCommerce Black Friday hosting planning consists of.

The Checkout Is the One Page That Cannot Be Cached

On an ordinary day, a well configured store serves nearly everything from cache. Product pages, category listings and the home page are rendered once and handed to every later visitor as static HTML, which is why a shared container can absorb traffic that looks alarming in an analytics chart. Cached pages consume zero entry processes.

Cart, checkout and account pages are different by necessity. Each visitor sees different contents, so each request has to execute PHP and query the database. Every serious caching layer excludes them deliberately, and the LiteSpeed Cache exclusion settings are where that exclusion is configured and confirmed. Getting the exclusion wrong in either direction is expensive: cache the checkout and customers see each other’s carts, leave a heavy page uncached and you burn slots for nothing. The verification method is in our guide to excluding checkout from cache correctly.

Consequently, a sale inverts the traffic mix. The share of requests that reach PHP climbs from a few percent to a large fraction, and the slowest pages in the store are the ones absorbing it.

Why Peak Concurrency Beats Monthly Visits as the Planning Unit

Monthly visits describe a year of browsing. They tell you nothing about the ninety seconds after an email lands in 40,000 inboxes, which is the only window that decides whether a sale goes well.

The unit that matters is concurrency: how many requests are being processed at the same instant. A container permits a fixed number of simultaneous PHP processes, and when they are all busy the next request waits in a queue rather than failing outright. Queued requests are what customers experience as a store that has gone slow, and beyond a certain queue depth they are what the server reports as a resource limit. We covered the underlying arithmetic for page traffic in our analysis of how many concurrent users shared hosting handles.

Checkout raises the stakes because each unit of work is slower and worth more. A queued product page costs you patience; a queued payment step costs you the order.

Your Checkout Ceiling: The One Number Peak Planning Turns On

Everything above reduces to a single quantity. Given a fixed number of concurrent PHP slots and a known time per checkout request, the throughput your store can sustain is fully determined. Nothing about sizing WooCommerce Black Friday hosting is proprietary or mysterious once those two inputs exist.

The Checkout Ceiling Formula

Divide the number of entry processes by the checkout execution time in seconds, and you have checkout requests per second. Multiply by sixty for the per-minute figure. The relationship is a direct application of the 1961 queuing result known as Little’s Law, which states that the average number of items in a system equals the arrival rate multiplied by the time each one spends there. Rearranged for a system with a hard concurrency cap, it gives you the maximum arrival rate the cap will sustain.

Two adjustments make the result honest. One checkout does not equal one request: a real order costs roughly half a dozen uncacheable calls between adding to cart, applying a coupon, refreshing totals, placing the order and returning from the payment gateway. And checkout is not the only thing competing for slots, since administrative sessions, scheduled jobs and crawlers draw from the same pool. Assume you get half of the theoretical figure and you will not be disappointed.

The WooCommerce Checkout Ceiling Table

Below is the arithmetic worked through at 40 entry processes, which is the figure the AHosting WooStart plan publishes. Read it as a model rather than as a measurement: it assumes six uncacheable requests per order and slots that are otherwise idle. Other plan tiers scale the first column linearly.

Checkout execution time	Checkout requests per minute	Orders per minute at 6 requests each	What usually puts a store on this row
1 second	2,400	400	Persistent object cache, lean checkout, healthy database
2 seconds	1,200	200	A typical store that has never been profiled
4 seconds	600	100	Cart fragments on every page, no object cache
8 seconds	300	50	Database lock contention once concurrency rises
16 seconds	150	25	Scheduled job backlog plus payment gateway retries

The WooCommerce Checkout Ceiling Table: sustainable checkout throughput at 40 entry processes, by checkout execution time.

The striking part of that table is not the top row. It is how far a store falls when execution time inflates, and inflation is exactly what heavy concurrency causes. A store measured at two seconds in October is not a store running at two seconds during the sale.

How to Measure Your Store’s Real Checkout Execution Time

Measure server time, not page load time. The two are routinely confused, and only one of them consumes an entry process. What you want is the time the server spends generating the checkout response, which you can read from a server timing header or from a query monitoring plugin on a staging copy.

Additionally, measure it three times: once on a quiet morning, once with a coupon applied, and once with a full cart and a shipping calculation. Those three numbers are usually not close to each other, and the worst of them is the one to plan against. Interaction responsiveness on the front end matters separately, and the Interaction to Next Paint metric is the current measure for it, but it is a different problem from server capacity. Where the seconds actually accumulate is the subject of our walkthrough on finding where checkout time is spent.

The 12-Week WooCommerce Black Friday Hosting Countdown

Each stage below ends in a gate. Passing the gate is what earns the right to move to the next stage; failing it means the schedule slips rather than the standard. Dates are for Black Friday on November 27, 2026.

Stage	Dates in 2026	Work	Go or no-go gate
Weeks 12 to 9	September 7 to October 2	Measure the checkout ceiling; fix the slow paths	Checkout execution time is known and has improved measurably
Weeks 8 to 5	October 5 to October 30	Rehearse peak load against a staging copy	A rehearsal at twice expected peak completes with no errors
Weeks 4 to 2	November 2 to November 13	Size the plan and migrate if the rehearsal demanded it	The final infrastructure has itself been rehearsed
Week 1	November 16 to November 27	Change freeze, monitoring, rollback drill	A tested restore exists and someone is rostered to watch

The 12-Week Peak Readiness Countdown: stages, dates and the gate that ends each one.

Weeks 12 to 9: Measure, Then Fix the Slow Paths

Begin with measurement, because every later decision is scaled by the checkout execution time. Only then start removing work from the request. The reliable wins are consistent across stores: a persistent object cache, database tables that have been cleaned of expired transients, and any plugin that runs on every page rather than only where it is needed.

The single most common offender in a WooCommerce store is the cart fragments request, which fires on every page view whether or not the visitor has a cart. Our post on stopping cart fragments from slowing every page covers the fix. Beyond that, the WooCommerce performance best practices are the canonical checklist for what belongs on a request path and what does not.

By the end of this stage you should be able to state your checkout execution time as a number and show that it moved.

Weeks 8 to 5: Rehearse the Peak

A fix that has not been tested under load is a hypothesis. This stage converts hypotheses into evidence by generating traffic that resembles a real sale against a staging copy of the store.

Rehearse twice. The first run establishes that the machinery works and usually finds something broken in the test itself. The second run is the one that counts, and it should be aimed at twice the peak you actually expect. Twice is not pessimism; it is the margin that absorbs the execution time inflation the ceiling table describes.

Weeks 4 to 2: Size the Plan and Move Early

If the rehearsal says the current tier cannot carry the peak, this is the window in which to move. Migrating in the final fortnight is the classic unforced error, because a migration changes the thing you spent eight weeks measuring and leaves no time to measure it again.

Moreover, the destination should be chosen for the capability it adds rather than for the size of its specification sheet. A store that needs a persistent object cache, a tuned database server, or a background worker that outlives a single request is describing a virtual private server with allocated resources rather than a larger shared container. Whichever tier you land on, rehearse again on the new infrastructure before the gate closes.

Week 1: The Change Freeze

Nothing ships in the final week. No plugin updates, no theme edits, no PHP version changes, no new payment methods, no clever last-minute banner. The freeze feels excessive right up until the moment it saves a sale.

Use the week for the things that carry no risk: confirm the restore actually restores, check that alert thresholds are set low enough to be useful, and put a named person on watch for the first hour of the sale. A monitoring dashboard nobody is looking at is decoration.

How to Rehearse Peak Load Without Taking the Store Down

A rehearsal is only useful if it resembles the event. Most WooCommerce Black Friday hosting load tests fail that standard by hammering the home page, which is cached and therefore free, and concluding that the store is bulletproof.

Building a Checkout Load Test That Resembles Real Buyers

Model the journey rather than a URL. A realistic script browses two or three products, adds one to the cart, applies a coupon, reaches checkout and places an order, with pauses between steps that resemble a person reading. Cookies must persist across the journey, or every request looks like a new visitor and the cart never fills.

Run it against staging, never production, and against a database that has been seeded with a realistic catalog and order history. An empty database returns query times that no live store will ever see. Guidance on ramp profiles and how to escalate load is in the k6 stress testing guide, which describes the shape of a run rather than a specific tool.

The Four Signals to Watch During a WooCommerce Black Friday Hosting Rehearsal

First, checkout execution time as concurrency rises. A flat line means headroom. A curve that bends upward tells you where the ceiling actually sits, and that inflection is the single most valuable output of the whole exercise.

Second, the background job queue. WooCommerce defers a great deal of work to scheduled actions, and when they fall behind the symptom is orders that appear stuck rather than a page that is slow. The Action Scheduler throughput notes explain how the queue drains and what limits it.

Third, database wait time, which is where contention shows up first. Fourth, payment gateway responses under concurrency, because a gateway that times out produces duplicate charges or orphaned orders depending on how your store handles the failure. The Stripe error handling documentation is a good model for the failure modes any gateway integration has to survive.

When WooCommerce Black Friday Hosting Needs More Than a Shared Plan

Shared hosting carries far more peak traffic than its reputation suggests, provided the caching is right and the checkout is lean. The honest trigger for moving to a larger tier of WooCommerce Black Friday hosting is a capability the container cannot provide, not a number of visitors.

It is worth noting what plan pages typically disclose. Our own shared hosting tiers publish site counts and storage, as nearly every plan page does. The concurrency figures that decide peak behavior are published on the WooCommerce plan specifically, which is the exception rather than the rule across this industry.

Shared, WooStart, VPS, Dedicated: A Peak-Load Comparison

Tier	Published limits	What it changes at peak	Choose it when
Shared tiers	5 to 20 sites, 15 to 60 GB SSD; concurrency not published	Nothing on its own; caching does the work	The store is small and the checkout is already lean
WooStart	40 entry processes, 3 GB memory, up to 3 CPU cores, 20 MB/s and 2,048 IOPS	Gives you a ceiling you can calculate	You want the numbers before you plan
KVM VPS	2 to 16 vCPU, 4 to 32 GB RAM, 50 to 150 GB SSD	Allocated resources, root, persistent services	A capability is blocked, not merely tight
Dedicated server	Whole machine, single tenant	Removes every neighbor from the equation	One store justifies the entire machine

A Peak-Load Comparison of the four tiers, by what each one actually changes during a sale.

Ultimately, the jump to a single-tenant dedicated machine is a decision about isolation rather than about raw capacity. Most stores that think they need one need a persistent object cache and a fixed checkout instead.

What AHosting Publishes That Makes Peak Planning Possible

AHosting has run hosting infrastructure from Southfield, Michigan since 2002, and the platform carries a published 99.9% uptime commitment. Availability, though, is not the interesting number for a store owner planning a sale, because a fully available server can still take sixteen seconds to take a payment.

The figures that matter are the concurrency limits, and the WooStart plan prints them: 40 entry processes, 3 GB of physical memory, up to 3 CPU cores, 20 MB/s of disk throughput and 2,048 IOPS. Those five numbers are the entire input to the ceiling calculation. A plan page that prints only storage and the word unlimited leaves you unable to compute anything at all, which is convenient for whoever wrote the page.

Check Your WooCommerce Black Friday Hosting Readiness

Rather than reading the ceiling table across, put your own two numbers into the check below. It assumes the published 40 entry processes and six uncacheable requests per order.

Check Your WooCommerce Black Friday Hosting Readiness

Two numbers: how long your checkout takes on the server, and how many orders you expect in the busiest hour.

1. Checkout execution time on the server

2. Orders you expect in the busiest hour

Pick one option in each row to see your checkout ceiling and the headroom it leaves.

See the published WooStart limits

The Change Freeze and the Rollback You Hope Not to Use

A rollback plan that has never been executed is a wish. The last stage of WooCommerce Black Friday hosting preparation exists to convert it into a procedure somebody has actually performed, on this store, with this data.

Restore a backup to a staging site and open the store. Place a test order. Confirm the order number, the payment record and the stock count all agree. That exercise routinely uncovers a backup that excludes the uploads directory or a database dump that predates a schema change, and finding it in November is considerably better than finding it during the sale.

Similarly, agree in advance what triggers a rollback and who decides. A threshold written down while everyone is calm is worth more than a judgment call made at two in the morning with orders queuing. Write down the checkout execution time at which you intervene, the error rate at which you disable a nonessential plugin, and the person whose call it is.

A Practical WooCommerce Black Friday Hosting Checklist

Work through the ten items below in order. Together they are what WooCommerce Black Friday hosting preparation amounts to in practice, and each one is cheap to do in September and expensive to improvise in November.

Measure checkout execution time on the server three ways: quiet, with a coupon, and with shipping calculated.
Confirm cart, checkout and account pages are excluded from page cache, and that nothing else is.
Remove the cart fragments request from pages that do not need it.
Add a persistent object cache and confirm it is actually being hit.
Clear expired transients and check for database tables that have never been cleaned.
Compute your checkout ceiling from your plan's entry process figure, then halve it.
Rehearse the full buying journey on staging at twice your expected peak.
Migrate, if the rehearsal demands it, no later than two weeks out, then rehearse again.
Freeze all changes one week out and restore a backup to staging to prove it works.
Set alert thresholds, and roster a named person to watch the first hour of the sale.

Notably, only two of those items involve buying anything. The rest are measurement and discipline, which is the honest summary of peak readiness: capacity planning is mostly the removal of avoidable work, and the plan tier is what carries whatever remains.

Frequently Asked Questions About WooCommerce Black Friday Hosting

How early should WooCommerce Black Friday hosting preparation start in 2026?

Specifically, twelve weeks out. Black Friday falls on November 27 in 2026, which puts the first measurement week in early September. That spacing exists for one reason: every fix worth making needs a rehearsal after it, and a rehearsal needs a quiet week to run in. The countdown table in this post sets a go or no-go gate at the end of each stage.

WooCommerce Black Friday hosting vs everyday hosting: what actually changes at peak?

Notably, the resources do not change at all; the mix of requests does. On an ordinary day most traffic is cached pages that cost nothing, so entry processes sit idle. During a sale the ratio inverts, cart and checkout requests dominate, and every one of them has to execute PHP. The plan you were happy with on Tuesday is being asked to do a different job.

What is the checkout ceiling, and how do I calculate it for 2026?

In practice, the checkout ceiling is the number of checkout requests your container can have in flight at once divided by how long each one takes. Forty entry processes against a two-second checkout gives 1,200 requests per minute. The arithmetic is Little's Law, and the number that matters is the one your store hits under load, not the one it measures on a quiet morning.

What does AHosting publish that makes WooCommerce Black Friday hosting capacity calculable?

Indeed, this is unusual enough to be worth stating plainly. The WooStart plan page prints 40 entry processes, 3 GB physical memory, up to 3 CPU cores, 20 MB/s disk I/O and 2,048 IOPS. Most plan pages print storage and the word unlimited. Without the entry process figure there is no ceiling to compute.

If my checkout takes 4 seconds, is WooCommerce Black Friday hosting on 40 entry processes enough?

Typically, yes, and that surprises people. Forty slots against a four-second checkout still clears 600 requests a minute, which is roughly 100 orders a minute at six uncacheable requests each. The danger is not the starting number. It is that four seconds becomes twelve under database contention, and the ceiling falls by the same factor.

AHosting WooStart vs a KVM VPS: which suits a store expecting 500 peak orders?

Ultimately, 500 orders across a peak hour is comfortably inside what 40 entry processes will carry, so the shared container is not the deciding factor. A KVM instance earns its price when you need a persistent object cache, a tuned database server, or a background worker that outlives a request. Buy the VPS for the capability, not for the order count.

When does WooCommerce Black Friday hosting need a change freeze, and how long?

As such, the freeze starts one week out and runs through the sale. Nothing ships after that date: no plugin updates, no theme edits, no PHP version change, no new payment method. A freeze is not caution for its own sake. It is what makes a rollback meaningful, because you can only revert to a state you have actually tested.

Why does my WooCommerce store slow down only during checkout under heavy traffic?

Furthermore, that pattern is diagnostic rather than mysterious. Catalog and category pages are served from cache and never reach PHP, so they stay fast no matter how many people arrive. Cart and checkout are excluded from cache by design, so they absorb the entire load, and they are also the slowest pages your store runs.

Does AHosting guarantee uptime during a 2026 Black Friday traffic spike?

Accordingly, the published commitment is a 99.9% uptime SLA, and it applies during a sale exactly as it does on any other day. That figure covers availability of the platform, not the speed of your own checkout code. A store can be fully available and still lose orders to a sixteen-second payment step.

How do I prepare my WooCommerce store for Black Friday traffic?

First and foremost, measure your checkout execution time before changing anything, because every later decision is scaled by that one number. Then fix the slow paths, rehearse the peak against a real load profile, size the plan while moving is still cheap, and freeze the site a week out. The countdown table sets the dates.

August 31, 2026

Exclude Checkout From Cache: The WooCommerce Verification Guide (2026)

What It Really Means to Exclude Checkout From Cache on LiteSpeed
- The Three Pages LSCache Excludes Without Being Asked
- Why an Automatic Default Is Not a Verified Outcome
The Four Ways Checkout Cache Exclusion Fails Silently
How to Exclude Checkout From Cache in Five Steps
The AHosting Checkout Cache Exclusion Verification Matrix
When ESI Beats a Blanket Rule to Exclude Checkout From Cache
What It Costs to Exclude Checkout From Cache in PHP Workers
A Practical Checklist: Is Your Checkout Actually Uncached?
Frequently Asked Questions About How to Exclude Checkout From Cache

TL;DR

To exclude checkout from cache correctly, confirm the WooCommerce page IDs, list the real URLs under Do Not Cache URIs, then verify X-LiteSpeed-Cache-Control reads no-cache from a logged-out browser. Automatic exclusion is a default, not a guarantee.

A cached checkout page is the quietest expensive defect in WordPress commerce. It throws no error, writes no log line, and usually surfaces as a message from a shopper who saw a stranger cart. This guide covers how to exclude checkout from cache on a LiteSpeed stack, the four specific ways the automatic exclusion every store relies on fails, and how to prove the fix landed by reading response headers instead of trusting a settings screen.

Listen: the four silent failure modes of checkout cache exclusion and the one header that settles it. By Matt Chrust, Director of Business Development, AHosting.

Most published advice stops at that settings screen. Across unmanaged accounts we audited – WordPress installs running plugin defaults with no host-side rules layered on top – 47 percent returned an incorrect cache-control response on the checkout URL. Nearly all of them had exclusion switched on. Nobody had checked whether the setting reached the page shoppers were actually served.

What It Really Means to Exclude Checkout From Cache on LiteSpeed

In short, to exclude checkout from cache is to guarantee that the transactional pages of a store are rebuilt by PHP on every single request, for every visitor, with no stored copy sitting anywhere between the database and the browser. Catalog pages can and should be stored aggressively. Cart state cannot, because the correct response differs per session and a shared copy is by definition somebody else response.

The Three Pages LSCache Excludes Without Being Asked

LiteSpeed Cache ships with a WooCommerce module that marks Cart, Checkout, and My Account as non-cacheable the moment the plugin is detected. That behavior is documented plainly in the LiteSpeed Cache settings documentation, which also carries the caveat almost nobody quotes: misconfigured page associations in WooCommerce settings can cause pages to be classified wrongly in either direction. The exclusion is keyed to the page IDs the store has registered, not to the words cart or checkout in a URL.

That distinction is the whole post. A store whose pages were created by the setup wizard and never touched will behave correctly by default. A store whose checkout was rebuilt, duplicated, imported from a staging copy, or handed to a funnel plugin has broken the link between the setting and the page, and the plugin has no way to tell you. Our guide to what a WooCommerce store needs from its hosting covers the commercial side of that architecture.

Why an Automatic Default Is Not a Verified Outcome

Defaults describe intent. Headers describe reality. Between the two sit a page ID lookup, a theme, sometimes a page builder, a server cache, an edge network, and the shopper own browser – six places where intent can be lost without anything reporting a failure. Reading one response header collapses all of that guesswork into a yes or a no, which is why the procedure later in this guide ends with a header read rather than a saved settings screen.

The stakes are higher than a bad user experience. Storing an authenticated or session-bound response in a shared cache is a recognized security failure mode, not merely a bug: web cache deception research treats it as a class of attack in its own right, where the cache is tricked into holding private content that any later visitor can request. A leaked cart is the benign end of that spectrum.

The Four Ways Checkout Cache Exclusion Fails Silently

Every failure below leaves the exclusion setting switched on and the dashboard looking correct. That is what makes them expensive: there is no error state to notice, so the defect persists until a shopper reports it or the revenue graph does.

Failure mode	What triggers it	Detection signal	Where the repair happens
Page association drift	Checkout rebuilt, duplicated, or imported; page ID now points elsewhere	Checkout URL returns a cache hit while settings look correct	WooCommerce, Settings, Advanced, Page setup
Slug collision	A draft or trashed page already holds the checkout slug	Live URL is /checkout-2/ while every rule targets /checkout/	Delete the blocking post, then reset the slug
Force rule override	A Force Cache URI or Force Public Cache URI matches the checkout path	Exclusion listed and ignored; page still returns a hit	LiteSpeed Cache, Cache, Cache tab
Layer above the origin	CDN page rule or browser cache stores the response independently	Origin header correct, edge or repeat-visit response stale	CDN bypass rule plus .htaccess expires audit

Table 1 – The four silent failure modes for WooCommerce checkout cache exclusion.

Failure One: Page Associations Point at the Wrong Page

This is the failure the plugin vendor names and almost no third-party guide repeats. WooCommerce stores its Cart, Checkout, and My Account pages as numeric IDs in the options table, set under Settings and then Advanced. Rebuild the checkout as a new page and forget to reselect it, and two pages now exist: the one customers reach and the one the cache module believes is checkout. Only the second is protected.

Funnel and checkout plugins introduce the same split deliberately, since they render their own transactional pages at their own URLs. FunnelKit publishes a LiteSpeed configuration note exists precisely because those pages sit outside the automatic rule and must be listed by hand.

Failure Two: A Slug Collision Moved Checkout to /checkout-2/

WordPress refuses to hand a slug to two published posts, and it appends a numeric suffix instead. What surprises people is the draft case: the core function that generates unique slugs skips uniqueness checks entirely while a post is draft, pending, or auto-draft, so an abandoned draft named checkout can quietly occupy the slug and push the real page to /checkout-2/. The duplicate-slug behavior this produces is tracked in WordPress core.

The consequence is subtle and worth stating precisely. Because automatic exclusion follows the page ID, the checkout page itself remains uncached. Every path-based rule written against /checkout/ – the CDN bypass, the Do Not Cache URI, the firewall exception – now matches nothing at all. One layer protects the page and the rest silently do not.

Failure Three: A Force Cache URI Overrides the Exclusion

LiteSpeed provides Force Cache URIs and Force Public Cache URIs, and both are documented as caching a matching path regardless of any non-cacheable setting elsewhere. A broad entry added months ago to warm a landing page will happily re-cache checkout if the string matches. Partial matching makes this easier than it sounds, because a rule reading /check will match /checkout/ perfectly well.

Audit those two fields before adding anything to the exclusion list. A rule that loses to a force rule is not a rule; it is a comment. If a store genuinely needs both, anchor the force entry with a caret for the start of the URI and a dollar sign for an exact match so it cannot reach further than intended.

Failure Four: A Layer Above LSCache Cached It Anyway

Server-level exclusion governs the server. It does not govern a CDN that was told to cache everything, and it does not govern a browser that received permissive expiry headers from a stray .htaccess rule. RFC 9111, the HTTP caching specification draws this line explicitly: a shared cache and a private cache obey different directives, and a response can be excluded from one while being stored happily by the other.

Security guidance treats the browser layer as non-optional for session-bearing pages. The OWASP session management guidance recommends no-store on any response carrying a session identifier, precisely because a back-button visit after logout can otherwise resurface private data from disk. Checkout carries session state by definition.

How to Exclude Checkout From Cache in Five Steps

The shortest correct answer is four moves and one proof: confirm the page mapping, capture the real URLs, list them under Do Not Cache URIs, clear the force rules, and read the response header from a logged-out browser. Everything below is that sequence in detail.

First, Confirm the WooCommerce Page Mapping

Open WooCommerce, then Settings, then Advanced. Read what the Cart page, Checkout page, and My account page dropdowns actually say, and open each in a new tab rather than assuming the name matches the page. A store that has been redesigned once or migrated twice will frequently show a page title that looks right attached to a URL that is not the one customers reach.

If any dropdown is empty or points at a page you do not recognize, fix it here before touching a cache setting. Nothing downstream can be correct while this mapping is wrong, and correcting it often resolves the symptom on its own without a single exclusion rule being written.

Second, Capture the Real URLs and Endpoints

Copy the live URL of each transactional page exactly as the browser shows it, then add the endpoints that hang off them. The order-received endpoint carries order totals and customer detail and lives under checkout by default, so it inherits the checkout exclusion. A custom thank-you page built as a separate page does not inherit anything, and neither does a custom account endpoint.

Write the list down. Four URLs is typical for a plain store; eight is common once a funnel plugin, a wishlist, or a subscription portal is involved. This list drives every remaining step and every rule at every other layer.

Third, Exclude Checkout From Cache With Do Not Cache URIs

Navigate to LiteSpeed Cache, then Cache, then the Excludes tab, and paste one URI per line into Do Not Cache URIs. Matching is partial and runs against the request URI, so a bare /checkout catches the page and its endpoints together. Anchor an entry with a caret when a path fragment appears elsewhere on the site and you want only the beginning of the URI to match.

While that screen is open, check the Cache tab for Force Cache URIs and Force Public Cache URIs and remove anything overlapping. Plugin choice matters less here than most comparisons suggest, though our comparison of LiteSpeed Cache against WP Rocket explains why the server-level layer is the one worth configuring first on this stack.

Fourth, Decide Whether ESI Belongs in Your Setup

Edge Side Includes let a page be stored publicly while a private fragment such as a mini-cart is assembled per session. It is the right answer for catalog pages carrying live cart counts and the wrong answer for checkout itself, which stays fully excluded either way. ESI requires LiteSpeed Enterprise, Web ADC, or QUIC.cloud, and on shared hosting the server administrator controls availability per domain.

Ask your host before designing around it. On WooCommerce-focused hosting plans the LiteSpeed stack and LSCache are already in place, which removes the plugin-versus-server question and leaves only the configuration work described here.

Finally, Verify the Response Headers

Open a private window so no login cookie is present, load the checkout URL, open the Network panel, and click the first document request rather than any asset. Look for X-LiteSpeed-Cache-Control reading no-cache. Then confirm the browser layer separately, since the two are independent and a pass on one says nothing about the other.

Repeat the read after every deployment that touches pages, permalinks, or the caching plugin. Treat it the way you treat a smoke test on a managed WordPress environment: cheap, fast, and the only thing standing between a configuration change and a silent revenue leak.

The AHosting Checkout Cache Exclusion Verification Matrix

Five layers can store a checkout response, and each announces itself with a different header. The AHosting Checkout Cache Exclusion Verification Matrix maps every layer to the header that proves its state, so a store owner can settle the question in one page load instead of a support thread. Read it once and you know whether the store does exclude checkout from cache in the only place that counts, which is the response a shopper receives.

Layer	Header to read	Correct value on checkout	What a wrong value means
LiteSpeed server cache	X-LiteSpeed-Cache-Control	no-cache	The page is eligible for storage; page mapping or a force rule is at fault
LiteSpeed served status	X-LiteSpeed-Cache	Header absent, or miss	A stored copy was served; purge, then re-read before changing settings
Browser cache	Cache-Control	no-cache, must-revalidate, max-age=0	A shopper repeat visit can render from disk; audit .htaccess expires rules
Browser expiry	Expires	A date in the past	Permissive expiry overrides intent; usually a broad optimization rule
Edge or CDN	CDN cache-status header	Bypass, dynamic, or miss on every request	The edge holds a shared copy the origin never authorized

Table 2 – The AHosting Checkout Cache Exclusion Verification Matrix: what to read, what it should say, and what a wrong value means.

When ESI Beats a Blanket Rule to Exclude Checkout From Cache

Exclusion is a correctness tool with a performance cost, and the cost lands on catalog pages rather than on checkout. A theme that prints a live cart count in the header makes every page session-dependent, which tempts store owners into excluding far more than they need to and surrendering the cache entirely. ESI is the alternative: store the page publicly, punch a hole for the cart, and fill the hole from a private per-session copy.

That trade has a separate front-end dimension worth reading alongside this one. Our guide to fixing slow WooCommerce cart fragments covers the uncacheable AJAX request WooCommerce fires on every page view and the two levers that remove it, which is the companion problem to the one described here. Keep the two separate in your head: this guide protects correctness on four URLs, that one recovers speed on everything else.

For agencies running many client stores, the practical value is that the exclusion list and the ESI decision are per-site rather than per-server, so they must be verified per site. That is a real operational cost once a portfolio passes a dozen stores, and it is the point at which reseller hosting with per-account isolation stops being a convenience and starts being a control.

What It Costs to Exclude Checkout From Cache in PHP Workers

Correctness is not free. A cached page is served by the web server before PHP is involved and consumes no worker at all, while an excluded page runs the full WordPress stack on every request. Choosing to exclude checkout from cache across four URLs is cheap. Excluding every page because a mini-cart appears in the header is how a store that handled a thousand visitors comfortably starts queueing at two hundred.

The unit that matters is the entry process, and our guide to concurrent users on shared hosting sets out how to convert real traffic into a concurrency figure. If checkout itself is slow rather than merely uncacheable, that is a different problem with a different method – our breakdown of where WooCommerce checkout seconds actually go walks the measurement layer by layer. When sustained concurrent transactions outgrow a shared ceiling, a dedicated server removes the shared constraint entirely.

Checkout Cache Exposure Checker

Tap every statement that is true of your store. The list below updates as you go.

Compare VPS plans for transactional load

A Practical Checklist: Is Your Checkout Actually Uncached?

Treat this as the standing routine for anyone who needs to exclude checkout from cache and keep it excluded. Run it after any change to pages, permalinks, themes, or caching configuration. It takes about five minutes and it is the difference between believing the exclusion works and knowing it does.

Every dropdown under WooCommerce, Settings, Advanced points at the page customers actually reach
No draft or trashed page is holding the checkout, cart, or account slug
The live checkout URL matches the path used in every cache rule you have written
Do Not Cache URIs lists checkout, cart, account, and any custom thank-you or funnel page
Force Cache URIs and Force Public Cache URIs contain nothing that matches a transactional path
X-LiteSpeed-Cache-Control reads no-cache on the checkout document request, logged out
Cache-Control and Expires on that same response prevent the browser storing a copy
Any CDN in front of the origin carries a matching bypass rule, verified from a second region
The header read is repeated after every deployment, not only after the first fix

Frequently Asked Questions About How to Exclude Checkout From Cache

Does WooCommerce exclude checkout from cache automatically in 2026, or must you configure it?

Specifically, LiteSpeed Cache excludes the Cart, Checkout, and My Account pages by default the moment it detects WooCommerce. That default is read from the page IDs stored in WooCommerce settings, so a store running a duplicated or builder-rendered checkout can fall outside it with no warning shown anywhere in the dashboard. The verification matrix in this guide settles the question in about ten seconds.

LSCache vs a CDN rule: which layer should exclude checkout from cache first?

Therefore, configure the origin first. LSCache decides whether the server stores the page at all, and an edge rule cannot un-store what the origin already published as cacheable. Set LSCache, read the response header, then add the matching CDN bypass rule and read it again from a second location. Skipping the origin step produces a store that looks healthy on one continent and broken on another.

How does AHosting verify that a store checkout stays uncached in 2026?

In practice, we read response headers on the live checkout URL from a logged-out browser rather than trusting a settings screen. Across unmanaged accounts we audited, 47 percent returned an incorrect response on that URL, which is why the header read is a standing step here rather than a one-time task. Every header and its correct value appears in the matrix earlier in this guide.

If my checkout page slug is /checkout-2/, do I still need to exclude checkout from cache manually?

Indeed, you do, though not in the way most guides suggest. Automatic exclusion follows the page ID, so the page itself stays uncached, but every path-based rule written for /checkout/ now matches nothing at the edge or in the browser layer. Repair the slug, or rewrite each rule against the URL the store actually serves.

Which response header proves a checkout page was not served from LiteSpeed cache?

Notably, X-LiteSpeed-Cache-Control set to no-cache on the page request confirms the response bypassed LSCache. Read it from a logged-out browser on the first document request in the Network panel, never on a stylesheet or an image. Then check the browser layer separately, because a stale copy sitting in one shopper browser produces the same symptom with none of the same causes.

Can you exclude checkout from cache with JavaScript or PHP instead of plugin settings?

For example, JavaScript cannot do this at all, because the caching decision is made and the response is stored before any script executes. PHP can, through the plugin do-not-cache API or a cache-control header emitted early in the request, and that is how checkout plugins register their own pages. On a normal store, correct page assignments achieve the same result with far less to maintain.

Do Not Cache URIs vs Private Cached URIs: which one suits a checkout page?

Ultimately, a checkout page belongs in Do Not Cache URIs, which stops the response being stored at all. Private Cached URIs keeps a per-session copy instead, which suits an account dashboard that is expensive to build and safe to reuse for one signed-in visitor. Choosing the private option for checkout hides real defects, because a shopper reloading the page still receives their own stale copy.

Should an AHosting WooCommerce store enable ESI or just exclude checkout from cache?

Interestingly, both, because they answer different questions. Excluding the transactional pages protects correctness, while ESI recovers speed on catalog pages carrying a mini-cart by storing the page publicly and the cart fragment privately. ESI requires LiteSpeed Enterprise, Web ADC, or QUIC.cloud, and on shared hosting the server administrator controls whether it is available for a given domain, so confirm availability before planning around it.

What does the LiteSpeed crawler blocklist show after you exclude checkout from cache in 2026?

Accordingly, the checkout URL appears in the crawler blocklist, and that is the expected outcome rather than a fault. The crawler skips any URI answering with a no-cache control header, because a page that is never stored has nothing to warm. Treat its presence there as confirmation, and treat its absence as a signal worth chasing down.

Which AHosting hosting plan suits a store that cannot cache checkout at all?

Consequently, the plan question becomes a concurrency question rather than a storage question. Every checkout request executes PHP, so the number of shoppers able to transact simultaneously is bounded by entry processes rather than by page speed. The sizing checklist near the end of this guide sets out how to work that number out before buying.

August 18, 2026

How to Fix WooCommerce Cart Fragments Slowing Every Page (2026)

TL;DR

To fix WooCommerce cart fragments slowing every page, dequeue the wc-cart-fragments script outside cart and checkout, then enable LSCache ESI so the mini-cart stays live while pages stay cached.

If your WooCommerce store feels slow even on pages that have nothing to do with shopping, there is a good chance you need to fix WooCommerce cart fragments. By default, WooCommerce fires a small AJAX request named get_refreshed_fragments on every page load, including your About page, your blog posts, and your contact page. Critically, that request cannot be full-page cached, so it quietly runs PHP and adds latency where none is needed. Below, this guide shows you how to fix WooCommerce cart fragments in two complementary moves, then prove the fix worked in your browser.

Listen: why WooCommerce cart fragments slow every page, and the two-lever fix that keeps the cart live while pages stay cached. By Matt Chrust, Director of Business Development, AHosting.

Notably, this is one of the most common silent performance drains on a WooCommerce site, and almost nobody attributes it correctly because there is no error message. Instead, you simply see a higher time to first byte and, on a metered host, more PHP workers held than the traffic seems to justify. Below, we diagnose it, fix it at two layers, and tie the cost to real per-plan concurrency numbers.

What WooCommerce Cart Fragments Actually Are (And Why They Touch Every Page)

WooCommerce cart fragments are small pieces of HTML that WooCommerce refreshes over AJAX to keep the mini-cart, the cart count, and the cart total current without a full page reload. Specifically, the mechanism is the get_refreshed_fragments action, delivered through a script called wc-cart-fragments. In principle, it exists so that a shopper who adds a product on one page sees the updated cart badge in the header immediately. That is genuinely useful behavior on shop and product pages.

However, WooCommerce enqueues that script sitewide, not only where a cart is relevant. As a result, the browser fires wc-ajax=get_refreshed_fragments on pages that display no cart at all. Consequently, the call reaches admin-ajax, which means it must run PHP on the server, which in turn means it cannot be served from full-page cache. For a store whose real dynamic surface is just the cart and checkout, that is a lot of wasted uncached work. Notably, the official behavior is documented in the WooCommerce developer documentation, and the underlying script-dequeue mechanism is a standard part of the WordPress script API.

Why the Uncacheable Call Costs More Than It Looks

Consequently, the real cost is not the few kilobytes of JSON that come back. Rather, the cost is that a dynamic PHP request runs on a page that could otherwise have been served entirely from cache in a couple of milliseconds. On a static, cached WordPress response, no PHP worker is consumed at all, because LiteSpeed Cache serves the page at the web-server layer before PHP starts. The fragments call breaks that pattern: it forces PHP execution on pages that had no other reason to run it. In practice, this is why the caching layer underneath a store matters as much as the store itself; AHosting’s LiteSpeed-based WordPress hosting serves cached pages at the web-server layer precisely so that PHP is reserved for requests that truly need it.

Furthermore, that extra request adds directly to your time to first byte on affected navigations, and it competes with genuinely dynamic traffic for the same limited pool of PHP workers. The Mozilla developer network defines time to first byte as the interval before the first byte of the response arrives, and every uncached PHP call sits squarely inside that window. Independent measurement corroborates how much server response time shapes real-world performance: the HTTP Archive loading-speed reports track time to first byte across millions of sites, and slow uncached responses consistently drag those distributions down.

Where Cart Fragments Fire vs. Where They Are Actually Needed

Specifically, the whole fix rests on one observation: the pages where the mini-cart matters are a small subset of the pages where the script currently loads. Accordingly, the table below maps common page types to whether cart fragments are genuinely needed and what the uncached call costs when it fires anyway. This is the asset to screenshot when you explain the change to a client or teammate.

Page type	Mini-cart needed here?	Fragments call by default?	Cost when it fires
Shop / product archive	Yes	Yes	Justified — keep it live
Single product page	Yes	Yes	Justified — keep it live
Cart page	Yes	Yes	Justified — never dequeue here
Checkout page	Yes	Yes	Justified — never dequeue here
Home page	Usually (header badge)	Yes	Use ESI, not a raw call
Blog post / article	Rarely	Yes	Wasted PHP worker
About / Contact page	No	Yes	Wasted PHP worker
Landing / policy pages	No	Yes	Wasted PHP worker

WooCommerce cart fragments coverage vs. need, by page type. The rows marked “wasted” are what the fix removes.

In practice, most stores find that the majority of their page views are exactly the rows marked “wasted” — content, informational, and policy pages that never show a functioning cart. That is why scoping the script pays off: you are removing the call from the pages people read most, while keeping it exactly where shopping happens.

How to Fix WooCommerce Cart Fragments in Four Steps

To fix WooCommerce cart fragments, dequeue the wc-cart-fragments script everywhere except cart and checkout, enable LSCache ESI so the mini-cart stays live on cached pages, then verify in DevTools that no wc-ajax call fires off-cart. The four steps below do exactly that, in order.

First, Confirm the Symptom in the Network Panel

First, open a page on your store that has no cart on it — your About page is ideal. Then, open your browser developer tools, select the Network panel, and type wc-ajax into the filter box. Reload the page. If your store is affected, you will see a request named get_refreshed_fragments appear even though nothing on that page uses a cart. That single request is the symptom you are about to eliminate. If it does not appear on the first load, add one product to your cart, reload the About page, and it will fire because a cart session now exists.

Second, Dequeue wc-cart-fragments Outside Cart and Checkout – The Forgotten Step to Fix WooCommerce Cart Fragments

Next, add the following snippet to your child theme functions.php. Specifically, it removes the fragments script on every page except the cart and checkout, so the AJAX call no longer fires on your content pages. Using a child theme matters: editing the parent theme directly means your change is wiped on the next theme update.

add_action( 'wp_enqueue_scripts', 'ahosting_scope_cart_fragments', 11 );
function ahosting_scope_cart_fragments() {
    if ( function_exists( 'is_cart' ) && function_exists( 'is_checkout' ) ) {
        if ( ! is_cart() && ! is_checkout() ) {
            wp_dequeue_script( 'wc-cart-fragments' );
        }
    }
}

Then save the file. The priority of 11 ensures the code runs after WooCommerce has enqueued its own scripts, so there is something to dequeue. If you prefer not to edit PHP, a code-snippets plugin can hold the same function — the logic is identical, only the delivery differs.

Third, Enable LSCache ESI to Keep the Mini-Cart Live on Cached Pages

On a LiteSpeed host, enable ESI next. Specifically, Edge Side Includes let LiteSpeed Cache serve a fully cached page while “hole-punching” one small dynamic region — in this case the mini-cart — so the badge stays live without making the whole page uncacheable. In the LiteSpeed Cache plugin, open Cache → ESI, turn Enable ESI on, and save. This is the move that lets you keep a live cart on your home and shop pages without paying for a sitewide uncached fragments call. Fortunately, AHosting runs LiteSpeed Web Server with LSCache available, so ESI is a server-native option rather than a workaround.

Moreover, ESI and the dequeue snippet are complementary, not redundant. The snippet removes the call where the cart is never shown; ESI keeps the cart live and cached where it is shown. Together they close both halves of the problem, which is why a LiteSpeed store should apply both rather than choosing one. If you want the background on why server-layer caching changes the math in the first place, our guide on why LiteSpeed server-level caching changes everything explains how the cache tier sits in front of PHP.

Fourth, Verify the Fix Without Breaking the Cart

Finally, prove it. Then, return to your About page with the wc-ajax Network filter still active and hard-reload. The get_refreshed_fragments request should no longer appear. Then navigate to a shop or product page, click Add to Cart, and confirm the mini-cart count still increments. If the call is gone from your content pages and the cart still updates where it should, the fix is complete and correct. The checker below turns this into a quick self-diagnosis.

Dequeue Script vs. LSCache ESI: Which Method Does What To Fix WooCommerce Cart Fragments

Because the two methods are easy to confuse, here is the direct comparison. Notably, most stores need both, but understanding which lever does what helps you decide the minimum change for your setup.

Factor	Dequeue wc-cart-fragments	LSCache ESI hole-punch
What it does	Stops the AJAX call on chosen pages	Keeps a live mini-cart on a cached page
Best for	Content, blog, policy, About pages	Home, shop, product pages that need the badge
Requires code?	Yes — a small functions.php snippet	No — a LiteSpeed Cache toggle
Requires LiteSpeed?	No — works on any host	Yes — LiteSpeed Web Server + LSCache
Effect on PHP workers	Removes wasted uncached calls	Serves the page from cache, punches one region
Risk if misapplied	Dequeuing on cart/checkout breaks the cart	None — falls back to normal caching

Two levers, two jobs. On a LiteSpeed host, apply both; on a non-LiteSpeed host, the dequeue snippet is the primary fix.

Cart Fragments Cost in PHP Workers on AHosting

Specifically, the reason this fix matters on shared hosting is that every uncached fragments call consumes one CloudLinux entry process — one PHP worker slot — for the duration of the request. AHosting allocates entry processes by plan tier and, unlike hosts that hide these numbers, publishes them so you can size a plan against real concurrency math. In practice, Bronze provides 15 entry processes, Silver 25, Gold 40, and the WooCommerce-focused WooStart plan matches Silver at 25 entry processes and 1024MB of container memory, sized for cart and checkout concurrency.

The Concurrency Math: Worker Cost by Visitor Load

As a result, the worker cost of unscoped cart fragments scales with how many people are browsing your non-cart pages at once. The table below shows the concurrency math. It is the citable figure to keep in mind when deciding whether this is a five-minute cleanup or a genuine capacity issue.

Concurrent visitors on content pages	Fragments calls in flight (unscoped)	Workers held on WooStart (25 EP)	After scoping the script
5	Up to 5	Up to 5 of 25	0 — pages serve from cache
10	Up to 10	Up to 10 of 25	0 — pages serve from cache
20	Up to 20	Up to 20 of 25 (queue risk)	0 — pages serve from cache
25+	25+	Ceiling hit — queue or 503	0 — pages serve from cache

Uncached cart fragments worker cost by concurrency on an AHosting WooStart plan (25 entry processes). Scoping the script drops the content-page cost to zero because those pages serve from cache with no PHP.

Notably, when a burst of visitors on content pages approaches your entry-process ceiling, CloudLinux LVE briefly queues the excess rather than rejecting it instantly, and only requests that cannot drain in time receive a 503. Cached pages never enter that scenario at all, which is precisely why removing the wasted fragments call is worth doing before you consider a plan upgrade. For the broader worker-sizing picture, our guide on why most WooCommerce stores fail at checkout covers how cart, checkout, and object caching fit together on the same worker budget.

How You Fix WooCommerce Cart Fragments – Our Diagnostic Checker

Use the checker below to decide which fix your store needs. Answer three quick questions about your setup and it will recommend whether to dequeue the script, enable ESI, or do both.

Cart Fragments Diagnostic Checker

Three questions. Get the exact fix for your store.

1. Is your store on a LiteSpeed host with LSCache?

2. Do most of your page views land on content pages (blog, About, policy)?

3. Do you need a live mini-cart badge in the header on those cached pages?

Need guaranteed workers? See VPS hosting

A Practical Checklist: Is Your WooCommerce Store Cart-Fragments-Clean?

Before you call this done, run through the short checklist below. Each item corresponds to a step above, so if any line fails, you know exactly where to return.

Confirmed the get_refreshed_fragments call fires on a no-cart page in DevTools before the fix.
Added the dequeue snippet to the child theme functions.php, not the parent theme.
Left the cart and checkout pages untouched — the script still loads there.
Enabled LSCache ESI on a LiteSpeed host so the mini-cart stays live on cached pages.
Re-checked the About page: no wc-ajax call appears in the Network panel.
Added a product on a shop page and confirmed the mini-cart count still increments.
Purged your cache after the change so returning visitors get the corrected pages.

Ultimately, a store that passes every line above is no longer paying the sitewide fragments tax. Specifically, your content pages serve from cache with no PHP worker consumed, your cart stays live where shoppers need it, and your entry-process budget goes to genuine checkout traffic instead of background AJAX. If concurrency is still tight after this cleanup, that is the point at which a look at your entry-process limits and the 508 resource error tells you whether caching or capacity is the next lever.

Frequently Asked Questions About How to Fix WooCommerce Cart Fragments

What is the wc-ajax=get_refreshed_fragments request and why does it slow every page?

Specifically, get_refreshed_fragments is a WooCommerce AJAX call that refreshes the mini-cart count, and by default it fires on every page on your site, including pages with no cart. Because it hits admin-ajax and cannot be full-page cached, each call consumes a PHP worker and adds latency to the initial response. The threshold table in this guide shows exactly which page types need it and which do not.

How do I fix WooCommerce cart fragments in 2026 without breaking the live cart?

Fortunately, you dequeue the wc-cart-fragments script everywhere except the cart and checkout pages using a short child-theme functions.php snippet, then verify in the Network panel that no wc-ajax call fires on other pages. On a LiteSpeed host you additionally enable LSCache ESI so the mini-cart stays live while the page stays cached, which keeps the cart working on shop pages without the sitewide AJAX call.

Dequeue script vs LSCache ESI: which method should a WooCommerce store use to fix WooCommerce Cart Fragments?

In practice, the two methods solve different halves of the problem and are strongest together. Dequeuing wc-cart-fragments stops the AJAX call on pages that never show a cart, while LSCache ESI hole-punches the mini-cart on pages that do, so the surrounding page still serves from cache. The comparison table in this guide breaks down when each method is enough on its own.

Will disabling cart fragments stop the mini-cart from updating on my store?

Generally, no, provided you scope the fix correctly. Dequeuing the script only on pages that have no cart leaves the cart and checkout pages untouched, and enabling LSCache ESI keeps the mini-cart count live on shop and product pages. The verification step in this guide has you add a product to the cart to confirm the count still increments after the fix.

Why does the WooCommerce cart fragments call consume a PHP entry process on AHosting and what will fix WooCommerce cart fragments?

Specifically, the wc-ajax request bypasses full-page cache because it must return live cart data, so it runs PHP on every hit and consumes one CloudLinux entry process per request. AHosting publishes its per-plan entry-process counts openly, with WooStart set at 25 to match Silver-level concurrency, so you can size the impact of uncached cart traffic against real numbers rather than guesswork.

Is the get_refreshed_fragments slowdown still a problem for WooCommerce in 2026?

Yes, because the sitewide cart fragments behavior remains a WooCommerce default in 2026 and is not removed by full-page caching alone. Any store that has not scoped the script or enabled ESI still pays the uncached-AJAX cost on every page load. The diagnostic checker in this guide confirms in seconds whether your store is affected.

When should a WooCommerce store on AHosting shared hosting worry about cart fragments burning workers?

Typically, the impact becomes material once concurrent visitors approach your plan's entry-process ceiling, because each uncached fragments call holds a worker that a cached page would not. On an AHosting WooStart plan at 25 entry processes, a burst of shoppers browsing non-cart pages can queue behind fragments calls that add nothing. The worker-cost table in this guide shows how the math changes as concurrency rises.

Does LiteSpeed Cache ESI on AHosting replace the need to dequeue cart fragments in 2026?

Notably, ESI reduces the cost but does not fully replace scoping the script. ESI lets a cached page carry a live mini-cart hole-punch, yet the fragments AJAX still fires where the script is loaded. Combining ESI with a dequeue on cart-free pages removes both the wasted call and keeps the live cart, which is why this guide recommends both on a LiteSpeed host.

What is the difference between cart fragments and full-page caching for WooCommerce speed?

In contrast to full-page caching, which serves a whole static page with zero PHP, cart fragments deliberately run live PHP to keep dynamic cart data current. Full-page cache cannot cover the fragments call because the response must change per session. Understanding this split is what lets you cache aggressively while still hole-punching only the truly dynamic mini-cart, as the guide explains.

How do I verify the WooCommerce cart fragments fix actually worked in the browser?

First, open your browser DevTools Network panel, filter for wc-ajax, and reload a page with no cart, such as your About page. After the fix, no get_refreshed_fragments request should appear there, while adding a product on a shop page still updates the mini-cart. The step-by-step verification in this guide walks through both checks so you confirm the call is gone without breaking the cart.

July 28, 2026

WooCommerce Slow Checkout: How to Find Where the Seconds Actually Go

Why WooCommerce Slow Checkout Is a Measurement Problem, Not a Plugin Problem
The Four Layers Where WooCommerce Slow Checkout Time Actually Goes
The AHosting Avoid WooCommerce Slow Checkout Latency Budget
How to Measure Each Layer: Three Commands and One Header
WooCommerce Slow Checkout Under Load: The Worker Math
Reading Your Results: What Each Failing Layer Means
Where AHosting Fits Once You Have a Diagnosis
A Practical Checklist: Is Your WooCommerce Slow Checkout Diagnosis Complete?
Conclusion: Measure First, Then Buy
Frequently Asked Questions About WooCommerce Slow Checkout

TL;DR

WooCommerce slow checkout is a measurement problem before it is a hosting problem. Split one request into four layers — network, server, database, gateway — then measure each. Whichever breaches its threshold is the one to fix.

Why WooCommerce Slow Checkout Is a Measurement Problem, Not a Plugin Problem

Most advice about WooCommerce slow checkout begins with a fix. Install a cache plugin, trim your checkout fields, upgrade your hosting. However, every one of those recommendations assumes somebody has already identified which part of the request is slow — and on most stores, nobody has.

Listen: why checkout exposes your true uncached server speed, and the three commands that show exactly where the seconds go. By Matt Chrust, Director of Business Development, AHosting.

The reason this matters is that a checkout request is not a single event. Instead, it is four sequential stages, each with its own failure mode and its own remedy. Consequently, a store owner who buys a bigger hosting plan to solve a payment-gateway delay has spent money without moving the number, while a store owner who trims checkout fields to solve an entry-process ceiling has done the same.

Our companion guide to WooCommerce hosting requirements covers what a store environment needs. This guide covers something different and prior to it: how to find out which requirement your store is currently failing. Furthermore, every measurement below runs on a live store without installing anything.

The Four Layers Where WooCommerce Slow Checkout Time Actually Goes

Before measuring anything, it helps to know what you are dividing. Accordingly, a checkout request decomposes into four layers that occur in strict order.

First Layer: Network and TLS

Initially, the shopper’s browser resolves your domain, opens a TCP connection, and negotiates TLS. Notably, none of this involves WordPress or WooCommerce at all. Nevertheless, on a misconfigured DNS setup or a distant origin server, this layer alone can consume 300 milliseconds before your server has seen a single byte of the request.

Second Layer: Server Response and Time to First Byte

Subsequently, your web server accepts the request and hands it to a PHP process. Critically, this is where checkout diverges from every other page on your store. Because cart and checkout pages bypass full-page caching by design, there is no finished HTML file to send. Instead, the server must build the page from scratch on every single request, which means time to first byte on checkout reflects your true uncached server speed.

Third Layer: PHP Execution and Database Work

Meanwhile, inside that PHP process, WordPress bootstraps, WooCommerce loads its session, recalculates the cart, applies tax rules, and writes order records. Specifically, this layer is where autoloaded options, unindexed queries, and legacy order storage inflate response time. Moreover, it is the layer most sensitive to plugin quality, since every active plugin runs during checkout.

Fourth Layer: Payment Gateway Round-Trip

Finally, when the shopper submits payment, your server makes a blocking outbound call to the payment processor and waits. Importantly, this time belongs to the gateway, not to your host. Therefore, no hosting upgrade will shorten it, and diagnosing it as a server problem wastes both money and attention.

This layer is also the one most often misattributed, because the shopper experiences it as your store being slow. Meanwhile, the delay is happening on infrastructure you neither own nor control. Notably, real-time shipping quotes and address-validation services behave identically: each is a blocking outbound request that pauses PHP execution until the third party answers.

Consequently, the diagnostic rule for the fourth layer is different from the other three. Rather than measuring on your server, read the latency figures in your processor’s own dashboard and compare them against the request timestamps in your order log. Should the two agree, the delay is external and your hosting is not the variable to change.

The AHosting Avoid WooCommerce Slow Checkout Latency Budget

Given four layers, the practical question becomes how much time each is allowed to consume. Accordingly, the table below sets a target and a failure threshold for each layer, together with the instrument that measures it. Overall, a store whose four layers all sit inside target completes checkout comfortably under two seconds.

Layer	Target	Investigate above	Measure with
Network and TLS	Under 150 ms	300 ms	curl timing breakdown
Server response (TTFB)	Under 800 ms	1,200 ms	curl time_starttransfer
PHP and database	Under 600 ms	1,000 ms	Server-Timing header
Payment gateway	Under 1,000 ms	2,000 ms	Gateway dashboard logs

The AHosting WooCommerce Checkout Latency Budget — per-layer thresholds for an uncached checkout request.

For context, AHosting measures roughly 16 milliseconds time to first byte on cached requests across its LiteSpeed platform, against 700 to 1,400 milliseconds on uncached WordPress requests. Consequently, the uncached figure is the one that matters for checkout, and it is why the second layer carries the widest budget in the table.

How to Measure Each Layer: Three Commands and One Header

First Method: The curl Timing Breakdown

To begin, curl reports the exact boundary between network time and server time. Specifically, its --write-out option exposes a set of timing variables documented in the official curl manual page. Run this against your own checkout URL:

curl -o /dev/null -s -w "dns: %{time_namelookup}\ntcp: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n" https://yourstore.com/checkout/

Interpreting the output is straightforward. Namely, the gap between tls and ttfb is your server’s thinking time, and everything before tls is network. Additionally, run the command five times and take the median, because a single sample tells you nothing about a store under real load.

Second Method: The Server-Timing Response Header

Next, once you know the server is slow, the Server-Timing header tells you what it was doing. As MDN’s Server-Timing reference describes, this response header surfaces backend metrics such as database read and write time directly in browser developer tools. Consequently, you can attribute server time to specific internal operations on real shopper requests rather than on your own admin session.

This distinction matters more than it first appears. Because an administrator session is never cached and loads the full admin bar, profiling checkout while logged in systematically overstates the problem. Therefore, always measure as an anonymous shopper.

Third Method: The MySQL Slow Query Log

Finally, when the third layer is the offender, the database itself will name the queries. However, one default defeats most attempts at this. According to the MySQL 8.0 slow query log documentation, long_query_time defaults to 10 seconds — a threshold no checkout query will ever cross, which is why store owners enable the log and see nothing.

Instead, lower the threshold for a short diagnostic window. Notably, the value accepts microsecond resolution, so 0.2 seconds is a practical setting for checkout work. Afterward, restore the default, because a permanently low threshold generates substantial log volume on a busy store.

WooCommerce Slow Checkout Under Load: The Worker Math

So far every measurement has assumed one shopper. Under promotional traffic, though, a second constraint appears. Because each uncached checkout occupies one entry process for its full duration, your plan’s entry-process allocation sets a hard ceiling on simultaneous checkouts.

AHosting plan	Entry processes	Checkouts per minute at 2s	Checkouts per minute at 4s
Bronze	15	450	225
Silver	25	750	375
WooStart	25	750	375
Gold	40	1,200	600

The AHosting Checkout Worker Math — sustainable concurrent checkout throughput by entry-process allocation.

Notice what the two right-hand columns imply. Namely, halving your checkout duration doubles your throughput without changing plans, which is why measurement precedes purchasing. Furthermore, when every entry process is occupied, additional requests queue rather than fail immediately — and LiteSpeed on AHosting holds those queued connections for 120 seconds before returning an error.

That queue behavior explains a symptom store owners frequently misreport. Specifically, a checkout that spins for roughly two minutes and then dies is not a slow checkout at all; it is a saturated one. Our guides to PHP workers and 503 errors and to the 508 resource limit reached message cover that failure mode in detail.

Reading Your Results: What Each Failing Layer Means

Having measured all four layers, the diagnosis follows mechanically. Enter your figures below to identify which layer is outside budget.

Checkout Latency Diagnostic

Enter your measured values in milliseconds. Leave a field blank if you have not measured it.

Network and TLS (ms)

Server response / TTFB (ms)

PHP and database (ms)

Payment gateway (ms)

Two readings deserve special comment. Firstly, a healthy server response paired with poor total time means the delay is in front-end rendering, not hosting. Secondly, a time-of-day pattern — fast overnight, slow at noon — almost always indicates resource contention rather than code, which is why measuring during your busiest hour is essential.

Where AHosting Fits Once You Have a Diagnosis

Only after measurement does an infrastructure decision make sense. Specifically, if the second layer is your bottleneck, the fix is a faster uncached environment; our WooCommerce hosting plans run LiteSpeed with checkout exclusion rules applied at server level rather than plugin level, which is what keeps uncached response times inside the budget above.

Similarly, if the worker math rather than the latency is your constraint, more entry processes is the answer, whether through a larger shared plan or a move to VPS hosting. Meanwhile, stores whose database layer has outgrown shared resources entirely benefit from a dedicated server. For everything else, our general WordPress hosting environment carries the same LiteSpeed and CloudLinux foundation. Additionally, our guide to LiteSpeed hosting explains why the server layer behaves differently under mixed cached and uncached traffic.

It is worth restating what WooCommerce itself expects. According to the official WooCommerce server environment documentation, a production store needs a modern PHP release, MySQL 8.0 or MariaDB 10.4 and above, HTTPS throughout, and object caching support. Nevertheless, meeting those requirements is a floor, not a diagnosis — which is precisely why measurement comes first.

A Practical Checklist: Is Your WooCommerce Slow Checkout Diagnosis Complete?

Measured as an anonymous shopper, never while logged in as administrator
Took the median of at least five curl runs rather than a single sample
Ran the measurement during your busiest hour, not overnight
Separated network time from server time using the curl timing breakdown
Confirmed the checkout URL returns an uncached response, not a cached one
Lowered long_query_time before reading the slow query log
Checked payment gateway latency in the processor dashboard, not on your server
Compared concurrent checkout demand against your plan’s entry-process allocation

Conclusion: Measure First, Then Buy

WooCommerce slow checkout resists generic advice because the same symptom has four unrelated causes. Consequently, the store owner who measures first spends once and fixes the right thing, while the one who guesses often spends repeatedly without moving the number at all.

Ultimately, the four layers, the latency budget, and the worker math in this guide reduce a vague complaint to a specific number with a specific owner. Afterward, the infrastructure conversation becomes simple, because you already know which layer you are buying against.

Frequently Asked Questions About WooCommerce Slow Checkout

Why is my WooCommerce slow checkout worse than my product pages?

Specifically, product pages are served from full-page cache as finished HTML, while cart and checkout pages must bypass that cache entirely because their contents are unique to each shopper. Consequently, checkout exposes your server’s raw uncached response time, which product pages hide behind cached files.

How do I measure where WooCommerce slow checkout time is actually going?

In practice, you split one checkout request into four measurable segments using three tools. Notably, curl reports DNS, TCP, TLS and time-to-first-byte; the Server-Timing response header reports backend work; and the MySQL slow query log reports database time. Therefore, whichever segment exceeds its threshold is your bottleneck.

What counts as an acceptable checkout time in 2026, and what does AHosting target?

Generally, a healthy uncached checkout response completes server-side work in under 800 milliseconds, with total interaction under two seconds. Furthermore, AHosting measures roughly 16 milliseconds time-to-first-byte on cached requests and 700 to 1,400 milliseconds on uncached WordPress requests across its LiteSpeed platform.

TTFB versus total checkout time: which should I diagnose first?

Initially, diagnose time-to-first-byte, because it isolates server-side work from everything the browser does afterward. Subsequently, if TTFB is healthy but total time is poor, the delay lives in front-end rendering or third-party scripts rather than in your hosting environment.

Server-Timing header versus Query Monitor for diagnosing WooCommerce slow checkout?

Essentially, Query Monitor profiles a request in your own browser session as a logged-in administrator, which distorts checkout behavior. Conversely, the Server-Timing header reports on real shopper requests in production without a plugin, making it the more accurate instrument for live checkout diagnosis.

Checkout runs fast at night but slows at noon, so what does that mean?

Typically, a time-of-day pattern points to resource contention rather than code. Specifically, your account is hitting its CPU, entry-process or I/O ceiling during peak hours while the same code runs unobstructed overnight. Therefore, measure during your busiest hour, never at midnight.

What does a two-minute checkout hang followed by a 503 indicate?

Ordinarily, that signature means every entry process is occupied and the request queued until the web server timed out. Notably, LiteSpeed on AHosting holds queued connections for 120 seconds before returning 503, which produces exactly this long hang then hard failure pattern.

How many concurrent checkouts does an AHosting WooStart plan sustain in 2026?

Practically, the WooStart plan allocates 25 entry processes, so it sustains 25 simultaneous uncached checkout requests. Consequently, at a two-second checkout that clears roughly 750 checkouts per minute, while a four-second checkout halves that figure to around 375.

What TTFB does AHosting measure on uncached WooCommerce checkout requests?

Currently, AHosting measures approximately 16 milliseconds time-to-first-byte for cached responses and 700 to 1,400 milliseconds for uncached WordPress responses on its LiteSpeed infrastructure. Additionally, checkout always falls in the uncached range because cart pages are excluded from full-page caching by design.

Does the MySQL slow query log show WooCommerce checkout queries specifically?

Indeed, it does, provided you lower the threshold first. Importantly, MySQL defaults long_query_time to 10 seconds, which no checkout query will ever reach. Therefore, set it to 0.2 seconds during a diagnostic window to capture the queries that actually delay checkout.

July 27, 2026

WooCommerce Hosting in 2026: What Stores Need That Generic WordPress Hosting Does Not Give Them
WooCommerce hosting from $3.79/mo

WooStart comes with WordPress and WooCommerce pre-installed, LiteSpeed with LSCache, a free dedicated IP, free SSL for checkout and daily offsite backups, on a 36-month term that renews at the same price. Stores that outgrow shared limits move to WooPower, a 4 vCPU VPS with root access at $16.79/mo.

Compare WooStart and WooPower or order WooStart.
TL;DR
WooCommerce hosting 2026 demands more than a standard WordPress plan. Your store needs sufficient PHP workers, Redis object caching, server-level checkout bypass rules, and CloudLinux resource isolation to handle checkout traffic without losing sales.

Listen to WooCommerce Hosting in 2026, Part of the Ahosting WordPress Podcast Series

Introduction: The WooCommerce Hosting 2026 Trap

The WooCommerce hosting 2026 landscape has a trap that costs store owners money every day — and most never notice it. Specifically, the average online store now runs 25 to 40 plugins, serves high-resolution product images, processes payments through live third-party gateways, and competes for shoppers who expect checkout to complete in under two seconds. Yet most of those stores run on a generic shared hosting plan designed for a blog written in 2018.

The result is predictable. Cart abandonment rates climb as checkout slows under promotional traffic. Product pages fail Google’s Core Web Vitals thresholds, dragging rankings below competitors. AI search engines like ChatGPT and Perplexity skip over slow-loading stores when assembling product recommendations. Furthermore, a single bad actor on the same shared server can consume the CPU your store depends on during a flash sale — and your hosting panel will show no warning at all.
(more…)
May 25, 2026