Capacity brief · Accountancy Sites
Web hosting for accountants — Model the last week of January before it arrives
Eleven quiet months tell you nothing about the fortnight that matters, and the fortnight is not the time to discover which of your pages runs PHP.
The short answer
Model the peak as two numbers rather than one: cacheable page views, which cost almost nothing because a cache hit never boots PHP, and concurrent uncached requests, which cost a PHP worker each for as long as they run. On a practice site the second group is short and expensive — the discovery-call booking, the enquiry form, the client-portal login — and it is what sets your ceiling in the last week of January.
Everything else absorbs traffic almost for free. What the platform contributes is identical across the range — NVMe storage, LiteSpeed caching at server level, free SSL, free migration, email on your own domain and support through the deadline week itself — from $2.42/mo, with the renewal figure printed the same as the first term.
By the HostingFast team · Reviewed 24 August 2026
Free
Migration by our team
24/7
Answers, day or night
Daily
Restore point interval
$0
Activation charge
Accountancy traffic is seasonal in a way few trades match: the fortnight before a filing deadline generates more enquiries than several ordinary months put together. That makes an average measurement close to useless, because the average describes a site nobody is using at the moment it matters.
It also makes the failure specific. A deadline page can be read by two thousand people with no strain at all if it is cached, while forty simultaneous booking submissions can queue behind each other on the same account. Traffic volume and traffic cost are different quantities.
So the work is to separate them, measure each, and then decide about capacity with arithmetic rather than nerves in the third week of January.
Count the requests that cost something
List every route on the site that cannot be served from cache. On a typical practice site that is the discovery-call booking, the contact form submission, any client login, and the search page. Everything else — services, deadline explainers, fee packages, the blog — is cacheable and effectively free once warmed.
Then estimate concurrency rather than volume for that short list. Twenty submissions spread over an hour is not the same event as twenty in the same ninety seconds. Your last January's analytics will give you the shape; the number you want is peak simultaneous uncached requests, because that is the figure a plan's cores and memory actually constrain.
Where more resource helps, and where it does nothing
Headroom buys you concurrency on the uncached routes. Sprint provides 1 core and 2 GB, Turbo the same with more storage and sites, and Nitro steps up to 2 cores and 4 GB — so more booking submissions can be in flight before requests begin waiting on each other.
It buys you nothing at all on a page that should be cached and is not, and nothing on a booking plugin that calls a calendar API synchronously inside the render. Those two failures are the ones that actually take practice sites down in January, and both of them survive an upgrade untouched. Measure first; a plan change afterwards happens in place, with no migration and no downtime.
Check the cache is doing what you think
Warm the cache and then verify it. Request a deadline page logged out and read the response headers for the LiteSpeed cache status; a hit means the web server answered from a stored copy without booting PHP. Do the same for the booking page and confirm it misses, because a cached booking page is worse than a slow one.
Watch for the plugin that quietly disables caching everywhere. Practice sites accumulate them — a live-chat widget, a countdown timer to the deadline, a tax-calculator shortcode — and any one can set a no-cache header sitewide. That single header converts your cheap traffic into expensive traffic, and it is invisible until somebody reads a response.
The review in the first week of February
While the peak is still recent, write down what happened: peak concurrent uncached requests, the slowest response you saw, whether the booking route held, and whether any monitoring alert fired. Ten minutes of notes now is worth more than a fortnight of recollection in December.
Then let the field data confirm it. Search Console reads a rolling 28-day window of real visits, so late January's experience lands in the report during February — which is the right time to look at it, and the right time to make a change while nothing is urgent.
What absorbs a peak, and what limits one
Cached reads are absorbed by LiteSpeed inside the web server: one PHP render, then cache hits for everyone else. That is the mechanism that makes a deadline page cheap.
Uncached writes are limited by the tier's cores and memory, which is why the plan decision should be made against a measured concurrency figure rather than a traffic total. Upgrades happen in place, with no migration.
- Cache hits answered without booting PHP at all
- NVMe storage under every tier for the uncached routes
- Upgrades in place, no migration and no downtime
- Support on shift through the deadline week itself
Why HostingFast
Standard on every plan
Cheap traffic stays cheap
A cached deadline explainer costs one render and then bandwidth. That is what lets a small plan carry a large fortnight.
Concurrency you can plan against
Sprint runs 1 core and 2 GB, Nitro 2 cores and 4 GB. The uncached ceiling becomes arithmetic instead of an anxious guess.
Upgrade without a migration
Plan changes happen in place from the client area, so a January decision does not involve moving anything anywhere.
Six-hourly restore points on Nitro
Daily backups on every plan, and every six hours on Nitro — which is the difference between losing an afternoon of enquiries and losing a day.
A certificate that will not expire in January
Free SSL on every plan. A certificate expiring on 29 January is entirely avoidable, and here it is avoided by default.
Support through the peak
Humans at any hour, including the week when a queued booking form is not something that can wait until Monday.
Quick Start
From order to online
- 1
List the uncacheable routes
Booking, form submission, login, search. Four routes, usually. Everything else is cacheable and does not belong in your capacity model at all.
- 2
Estimate peak concurrency, not volume
Pull last January's busiest hour and work out simultaneous uncached requests. That is the figure a tier's cores and memory actually constrain.
- 3
Verify the cache, then size the plan
Confirm hits on the cacheable pages and misses on the transactional ones. Only then decide whether more resource is what you need.
Built In
Loaded onto every plan
- Every uncacheable route on the site written down explicitly
- Peak simultaneous uncached requests estimated from last January's data
- LiteSpeed cache status confirmed as a hit on deadline and service pages
- Booking and form routes confirmed as excluded from the page cache
- Calendar or gateway calls checked for blocking the render synchronously
- Plugins audited for setting a no-cache header across the whole site
- Plan concurrency compared against the measured figure, not a traffic total
- Upgrade path confirmed as in place, with no migration and no downtime
- Free SSL renewing itself well before the deadline fortnight
- A short written review taken in the first week of February
Frequently Asked
What people ask us most often
How do I work out what capacity January needs?
Not from page views. Take your busiest hour from last year, count only the requests that cannot be cached — bookings, form submissions, logins, searches — and estimate how many of those overlap in the same few seconds. That concurrency figure is what a tier's cores and memory constrain. Cached page views barely enter the calculation, because a cache hit never boots PHP.
Should I upgrade before the deadline just in case?
Only if your measurement says the uncached lane is the constraint, in which case yes and it takes minutes. If the real problem is a page that should be cached and is not, or a booking plugin blocking on an external calendar call, a bigger plan moves the failure later in the week without preventing it. Upgrades happen in place afterwards, so there is no penalty for measuring first.
Can a countdown or calculator plugin break caching?
Yes, and it is a common finding on practice sites. Anything that renders per-request output often disables page caching sitewide rather than just on its own page, which converts every visit into a full PHP render. Read the cache status header on a page you expect to be cached; if it is missing, the plugin list is where to look before the hardware is.
What is the backup cadence if something goes wrong mid-deadline?
Daily on every plan, and every six hours on Nitro, with Imunify360 in front of it. Restores run from the panel — files, database or both — in minutes rather than through a ticket queue. Rehearse one before January so the recovery path is something you have done rather than something you have read about.
Keep reading
Dog Trainers — Hosting Guide
Small-business site, real numbers: what to measure on a service-led build.
Esports Teams — Hosting Guide
Streaming schedules and burst traffic — capacity for a spike that arrives on cue.
SSL Certificate (Glossary)
The certificate in the handshake, and confirming the renewal actually happened.
SSL Certificates — Built for Accountants
Paid certificate options and when the free one is already sufficient.
Web Hosting
The platform underneath: NVMe, LiteSpeed, free SSL and engineer-run migration.
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.
Size the plan against a measured number.
Cache hits absorbed by LiteSpeed, NVMe under every tier for the routes that cannot cache, and in-place upgrades with no migration.
View SSL Certificates — Built for Accountants plans