Performance profile · Florists
Florists: the two mornings your checkout has to hold
Your browsing pages cache and cope; the cart, the checkout and the delivery-date lookup do not — and those are the only three URLs that matter on the two mornings that pay for your year.
The short answer
For a florist the page to measure is the checkout, not the homepage, because the cart, the checkout and the account screens are uncacheable by design and they are the only pages under real pressure on the two biggest ordering days of the year.
Get the reading right. A cached product page on our platform serves a UK visitor comfortably below 200ms, but the checkout runs the full PHP and database path on every request, so measure its TTFB separately and treat a persistent figure above roughly 600ms as work to do in January rather than a discovery to make on the morning. Every plan runs NVMe storage with LiteSpeed caching in the server, from $2.42/mo.
By the HostingFast team · Reviewed 15 August 2026
24/7
Support, any hour
1-click
WordPress, one click
Free
SSL, no invoice line
Daily
Backups, every day
A florist's site has an unusual load profile. For fifty weeks it is a brochure with an ordering path attached; for two mornings it is a store taking more traffic than the rest of the quarter combined, with stock that will be worthless by Thursday.
The pages that spike are also the pages that cannot be cached. WooCommerce excludes the cart, the checkout and the account screens on its own, and it is right to — you cannot serve one customer's basket to the next visitor. So the browsing pages get faster and faster while the checkout stays exactly as fast as the account beneath it.
That is the whole engineering problem, and it is measurable. This page is about measuring it in January, when there is still time to fix what you find.
The three URLs worth benchmarking
Product page, cart, checkout. Load each one, take the TTFB from the network panel or from WebPageTest, and record the figures somewhere you will find them again next January. The product page should be a cache hit — check the response headers for 'x-litespeed-cache: hit' on a second load — and the other two never will be.
The gap between those readings is your work. A 180ms product page next to a 1.4-second checkout is not a caching failure; it is a PHP and database figure, and it is the figure that decides whether an order completes at eight in the morning on the busiest day you have.
Why the delivery-date field is quietly expensive
The plugin that gives customers a delivery date, blocks the days you cannot cover and enforces a cut-off time is the most useful thing on the site and often the heaviest. It usually resolves availability through admin-ajax on every page view, which means an uncached PHP request riding along behind a page that was otherwise served from cache.
Measure it directly. Open the network panel, filter to admin-ajax, and see what the date picker costs. If it is adding half a second to every product page, cache its response, move it to the cart step, or replace it. Redis object caching helps here far more than any further image work will.
Warm the cache, then leave the site alone
Two days a year are known months in advance, which makes being surprised by them a choice. In the week before, publish everything, purge once, then walk your own sitemap so the cache is populated before the traffic arrives. A cold cache on a spike morning means every early visitor pays the full PHP cost on your behalf.
Then stop changing things. A theme edit at seven in the morning purges the cache you spent a week filling. The most common release-day failure is not capacity — it is somebody shipping a change into the busiest hour of the year.
The part of the flow that fails silently
Order confirmation email. The checkout returns a success page whether or not the message ever left the server, so this is the one step that can be broken for weeks without anybody noticing. Place a real order in a quiet week, confirm the mail lands in an inbox rather than a spam folder, and check that SPF and DKIM are published for the domain.
Then rehearse the recovery. Daily backups restore from the panel in minutes — files, database or both — and knowing you can do that at eight in the morning without opening a ticket is worth more on the day than any further millisecond.
Built for the two mornings, not the fifty quiet weeks
Independent florists, wedding floral designers and studio florists working to order do not need more speed on the pages that already cache. They need the checkout to hold when the year arrives all at once.
NVMe storage, LiteSpeed caching in the server and Redis object caching for the queries a page cache cannot reach — the same stack on every tier, including the cheapest.
- Cart and checkout exclusions handled by WooCommerce out of the box
- Redis object caching for the queries a page cache cannot help
- NVMe storage on every plan, not just the top one
- Daily backups you restore yourself, in minutes
Why HostingFast
Standard on every plan
A checkout that is not an afterthought
Cart and checkout run uncached by design, so PHP 8.x, Redis and NVMe decide how fast they are. All three come as standard.
Cache you can verify
LiteSpeed sits in the web server. Check for 'x-litespeed-cache: hit' in the response headers and you know it works, rather than hoping.
Room for a spike
A cached response never reaches the origin, so a browsing surge costs the server almost nothing. Capacity is a caching question first.
Test on a clone, not on the shop
Staging lets you swap the delivery-date plugin and measure the difference without a single customer meeting the experiment.
Email that actually leaves
Mailboxes on your own domain with spam and virus screening, so the order confirmation lands where the customer looks for it.
Restores without a ticket queue
Daily backups, restored from the panel in minutes at whatever hour it goes wrong. Files, database, or both.
Quick Start
From order to online
- 1
Benchmark in January
Product page, cart, checkout. TTFB for each, written down. Confirm the product page is a cache hit and accept that the other two are not.
- 2
Cost out every dynamic add-on
Filter the network panel to admin-ajax and see what the delivery-date picker, the currency switcher and the live stock counter charge every visitor.
- 3
Warm, then freeze
Populate the cache the week before, then stop shipping changes. A purge at seven in the morning undoes all of it.
- 4
Rehearse the restore
Restore a backup onto staging once, so the procedure is familiar before you ever need it under pressure.
Built In
Loaded onto every plan
- LiteSpeed caching compiled into the server, not added by plugin
- Redis object caching for the queries a page cache cannot answer
- NVMe SSD storage on every tier
- Per-site PHP version switching from the control panel
- Staging clones for testing a plugin swap safely
- Daily backups with a self-service restore
- Free SSL, reissued automatically before expiry
- Spam and virus screening on every mailbox as standard
- 99.9% uptime as the target, monitored around the clock
- Money-back cover: 30 days on hosting plans, 7 on reseller
Frequently Asked
What people ask us most often
Which URL fails first when the orders all arrive at once?
The checkout, every time. Browsing pages are served from cache and a cached response barely touches the server, so a hundred people reading product pages costs almost nothing. Ten people paying simultaneously costs real PHP and database work. Benchmark the checkout in January and you will know whether you have a problem while there is time to fix it.
How do I tell whether the delivery-date plugin is slowing the site?
Open the browser network panel on a product page, filter to admin-ajax, and read the timings. Most delivery-date plugins resolve availability on every page view. If that request costs 300 to 500ms, either cache its response, move it to the cart step, or replace the plugin — then retest to confirm which of the three actually helped.
Should I be warming the cache before a big day?
Yes, and in the week before rather than on the morning. Publish everything, purge once, then walk the sitemap yourself so every page is populated. After that, freeze the site: a theme tweak on the day empties the cache you just filled and hands the first hundred visitors the uncached version.
The checkout says the order went through. How do I know the confirmation email did?
You test it, in a quiet week. Place a real order, confirm the message arrives in an inbox rather than a spam folder, and check that SPF and DKIM are published for the domain. Mailboxes on your own domain come with every plan and carry spam and virus screening, but nothing substitutes for having watched one arrive.
Keep reading
Veterinarians — Hosting Guide
Where a veterinary site spends its seconds, and the request that never caches.
Pet Groomers — Hosting Guide
What a grooming salon's booking calendar costs every visitor, measured.
Uptime (Glossary)
The term defined, and the measurement that gives it meaning.
WordPress Hosting — Built for Florists
LiteSpeed in the server, Redis behind it, staging to prove the change.
cPanel Reseller Hosting
WHM and cPanel for resellers, on the same NVMe platform.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Benchmark it in January.
NVMe and LiteSpeed on every plan from $2.42/mo, with Redis for the requests your cache can never serve.
View WordPress Hosting — Built for Florists plans