Performance profile · Butchers
Butchers: pricing by weight is a live calculation
A joint priced per kilo cannot be cached at a price, and a Christmas cut-off that closes itself depends on a scheduled job actually running.
The short answer
On a butcher's site the two things worth measuring both happen behind the page: a weight-based price that has to be recalculated for every basket, and a scheduled job that closes seasonal ordering when you reach capacity.
Time them individually. Add a joint to the basket with the network panel open and read that request; then check that your scheduled task actually fires rather than waiting for a visitor to trigger it. Cached product pages here answer a nearby visitor comfortably below 200ms, while basket arithmetic runs the full PHP path — which is why a current PHP release, Redis object caching and NVMe storage matter, all standard from $2.42/mo.
By the HostingFast team · Reviewed 12 August 2026
Free
Migration in, at no cost
24/7
Answers from people, any hour
Daily
Backups taken daily
$0
No setup charge
Most shops sell units. A butcher sells weight, and that difference reaches all the way down into the site's behaviour: prices are computed rather than stored, quantities carry a tolerance, and the basket has to do arithmetic every time it changes.
On top of that sits a seasonal capacity problem. Festive ordering compresses a large share of the year's direct sales into a few weeks, and the site has to stop taking orders at a number you choose rather than at the number people would like to place.
Neither of those is a page-speed issue in the usual sense. They are server-side behaviours, and the way to look after them is to time them and to verify that the scheduled work runs.
Time the basket, not the product page
Product pages cache. Confirm that once — two loads, look for 'x-litespeed-cache: hit' — and then leave them alone. The interesting measurement is what happens when somebody adds a 2.4 kilo joint: a price calculation, a stock check against the remaining weight, and a basket rebuild, none of which can be served from a stored copy.
Open the network panel, add an item, and read the request on its own. That figure is the one that matters at four in the afternoon in December. If it is high, the levers are query count and PHP version rather than image compression.
Cut-offs depend on a job that actually runs
A cut-off date that closes ordering, a stock cap that closes a product, a reminder that goes out to collection customers — all of those are scheduled work. On a quiet site, scheduling that relies on visitor traffic to fire can simply not happen, and the first sign is a hundred orders you cannot source.
Use a real cron entry from the control panel rather than relying on a visit to wake the scheduler. Then verify it: set a test task, watch it fire on time, and confirm the log. Ten minutes now removes the failure mode that costs a December.
Stock caps are the arithmetic that saves you
Set the quantity you can genuinely source and let the shop close the product when it is reached. The decrement is a database write, uncached, and it is the only thing standing between you and a hundred apologetic phone calls. Keep the product simple, without a matrix of options, so each write does less work.
Test it properly on staging. Set a cap of two, order three, and confirm the third is refused. A cap you have never exercised is a cap you are trusting rather than relying on, and December is a bad month to discover the difference.
Then check what leaves the server
Order confirmations and collection reminders are the invisible half of the flow. A checkout can return a success page whether or not any message left. Place a test order in a quiet week, confirm the mail lands in an inbox, and check that SPF and DKIM are published for the domain.
Keep a backup and know how to use it. Daily copies restore from the panel in minutes, files or database or both, which is the difference between a bad hour and a bad week when a plugin update lands badly in the middle of a busy season.
The work that happens after the click
Traditional butchers, dry-aging specialists and meat box producers selling direct have a site whose interesting behaviour is all server-side: weight arithmetic, stock caps and scheduled cut-offs.
NVMe storage, a current PHP release, Redis object caching and real cron entries from the panel are what those depend on — and they are on every tier.
- Cron jobs configured from the control panel, not visitor-triggered
- Redis object caching to cut the queries per basket rebuild
- NVMe storage under every stock write
- Staging clones for exercising a stock cap before December
Why HostingFast
Standard on every plan
Basket arithmetic on quick hardware
Weight pricing recalculates per basket and never caches. NVMe, current PHP and Redis object caching are standard, exactly where that lands.
Scheduled jobs that really fire
Real cron entries from the panel, so a cut-off closes on the date you set rather than when a visitor happens to arrive.
Product pages served from cache
LiteSpeed sits in the web server, so browsing costs the application nothing and leaves the capacity for baskets.
A clone to test a cap on
Staging lets you set a limit of two, try to order three, and confirm the refusal before a season depends on it.
Mail you have watched arrive
Mailboxes on your own domain with spam and virus screening, so a confirmation reaches an inbox rather than a spam folder.
Restores in minutes, not days
Daily backups, restored from the panel yourself, files or database or both, at whatever hour it went wrong.
Quick Start
From order to online
- 1
Confirm product pages are cache hits
Two loads, headers checked. Once that is true, stop optimising them and move to the part that does actual work.
- 2
Time an add-to-basket with a weight
Network panel open, add a 2.4 kilo joint, read that request alone. That is the December number.
- 3
Move scheduling onto real cron
Configure the job from the control panel and watch a test task fire on time. Visitor-triggered scheduling fails on quiet days.
- 4
Exercise the cap on staging
Set a limit, exceed it, confirm the refusal. A cap you have never tested is a hope rather than a control.
Built In
Loaded onto every plan
- Cron jobs scheduled from the control panel
- Redis object caching to reduce queries per basket rebuild
- NVMe SSD storage on every tier
- LiteSpeed caching in the web server for product pages
- Per-site PHP version switching from the control panel
- Staging environments for exercising stock caps safely
- Daily backups with a self-service restore
- Free SSL on every plan, reissued automatically
- Spam and virus screening on every mailbox as standard
- Zero setup charges, and free migration by our engineers
Frequently Asked
What people ask us most often
Does selling by weight make the site slower?
It makes the basket do work a unit-priced shop does not. Every change recalculates a price and checks remaining weight, and none of that can be served from cache. Product pages still cache normally, so the fix is not more image compression — it is fewer queries per basket rebuild, which is what object caching and a current PHP release deliver.
My cut-off date passed and the shop kept taking orders. What went wrong?
The scheduled job did not run. Scheduling that depends on visitor traffic to fire can simply not happen on a quiet morning. Configure a real cron entry from the control panel instead, then set a test task and watch it run on time. That check takes ten minutes and removes a failure that costs a season.
How do I know the stock cap will actually hold?
By exercising it. On a staging clone, set a limit of two, then try to place a third order. If the third is refused you have a control; if it goes through you have a setting. Do it in October rather than in the second week of December when the phone calls start.
Is a collection reminder email a hosting problem?
It is a hosting question and worth testing like one. A checkout returns a success page whether or not any message left the server, so place a real order in a quiet week and watch the mail arrive in an inbox. Every plan includes mailboxes on your own domain with spam and virus screening, and SPF and DKIM are worth confirming while you are there.
Keep reading
Nail Studios — Hosting Guide
A salon booking calendar, timed: the request no cache is allowed to answer.
Interior Designers — Hosting Guide
A heavyweight portfolio measured properly, and what to change first.
Best Hosting With Free SSL
A shortlist with the reasoning shown, and the trap most buyers walk into.
WooCommerce Hosting — Built for Butchers
Store-ready hosting with Redis caching and headroom kept for checkout traffic.
VPS Hosting
KVM virtual servers with root access, DDoS filtering and one flat monthly rate.
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.
Time the basket, verify the cron.
NVMe, Redis and panel-configured cron from $2.42/mo, with no setup fee at either end.
View WooCommerce Hosting — Built for Butchers plans