Load profile · Dance Studio Sites
Web hosting for dance studios — One morning a year decides whether your hosting is good enough
Term enrolment and show ticket release put a year's traffic through your site in ninety minutes, and the pages that fail are never the ones you tested.
The short answer
A dance studio site is quiet for eleven months and then takes its entire year's traffic in one morning, so the only measurement that matters is how it behaves under concurrency rather than how it scores at 3pm on a Tuesday. Cached pages — classes, term dates, uniform, the show page itself — are served from LiteSpeed without touching PHP, so they scale almost for free. Checkout, account and any "my bookings" screen are uncacheable by definition and consume a PHP worker each for as long as they run.
That means the ceiling on ticket morning is set by the uncached requests, not by the total traffic. The platform side of that sum is settled before you start — NVMe under every tier, LiteSpeed caching in the server rather than in a plugin, free SSL, an engineer-run migration, mailboxes on your own domain and people on shift at any hour — from $2.42/mo, at a rate that reads exactly the same when renewal arrives.
By the HostingFast team · Reviewed 24 August 2026
24/7
Cover, every hour of the day
1-click
WordPress install time
Free
Certificate cost
Daily
Restore points, every plan
Enrolment and ticket release are not marketing events, they are load tests with an audience. Several hundred parents arrive inside a few minutes, most of them on phones, most of them on mobile networks, all of them doing the same three things in the same order.
The useful mental model is two lanes. Everything a logged-out visitor reads is cacheable and cheap: one PHP render, then thousands of cache hits. Everything transactional is expensive: a worker occupied per request, a database write, sometimes a payment API call adding its own latency to yours.
Optimise the wrong lane and nothing improves. A studio that spends a week compressing show photographs and never checks whether the checkout page is being cached by accident — which breaks baskets — has done work that will not survive contact with ticket morning.
Two lanes: cached reads and uncached writes
Separate the site into pages that can be served from cache and requests that cannot. Class listings, term dates, the uniform page and the show information page are all in the first group; there is no reason for any of them to run PHP more than once per cache lifetime. Basket, checkout, account and booking confirmation are in the second, and each one occupies a PHP worker until it finishes.
Confirm which lane a page is really in rather than assuming. Load it in a private window and look at the response headers for the LiteSpeed cache status. A surprising number of studio sites discover that a plugin has set a no-cache header sitewide, which means every one of those cheap reads has been quietly expensive for a year.
What to measure in the fortnight before
Take three numbers and date them. Median TTFB on the show page from `curl -s -o /dev/null -w '%{time_starttransfer}'`, run five times. The PageSpeed Insights field block for the same page, where you want LCP under 2.5 seconds and INP under 200 ms at the 75th percentile. And the wall-clock time of a full test purchase, measured end to end with DevTools open.
Then do the thing almost nobody does: repeat the test purchase from a throttled mobile profile. Ticket morning is a mobile event, and an INP figure taken on a desktop with a warm cache is not evidence about a parent tapping a quantity selector on a bus.
Where the ninety minutes actually breaks
Three failure modes recur. A checkout page accidentally cached, so parents see somebody else's basket. A payment gateway call made synchronously inside the page render, so your response time is now the gateway's response time plus your own. And a plugin that writes a row to the options table on every request, turning a read-heavy morning into a write-heavy one.
None of those is fixed by a bigger plan, which is why "upgrade and hope" is such an expensive strategy. Where headroom does help is the uncached lane: Nitro runs 2 cores and 4 GB against Sprint's 1 core and 2 GB, so more concurrent checkouts can be in flight before requests start queueing behind each other.
The rollback plan is part of the performance plan
Freeze the site a week out. No plugin updates, no theme changes, no "quick" additions to the show page. Anything that must change goes to a staging copy first and gets the same three measurements before it is allowed near the live site.
Keep the restore path rehearsed rather than theoretical. Daily backups restore from the panel in minutes — files, database or both — and knowing you have actually done it once is what lets you make a change on the Thursday instead of freezing everything from October. If something does go wrong at 09:05, support answers at any hour and can look at the same numbers you are looking at.
Built for the morning, not the average
Cached pages come off LiteSpeed at server level, so a thousand parents reading the show page is one PHP render and 999 cache hits rather than a thousand of each.
Underneath, every tier runs NVMe storage, so the uncached requests that do reach the database are not also waiting on a slow disk. Staging copies let you rehearse the whole thing on a clone first.
- Server-level caching, so reads cost almost nothing
- NVMe under every tier for the uncached writes
- Daily restore points, recoverable from the panel
- Humans on support through the peak, at any hour
Why HostingFast
Standard on every plan
Reads that scale without PHP
A cached listing page is answered by the web server itself. That is the difference between a spike that is boring and a spike that is a story.
Headroom you can name
Sprint gives 1 core and 2 GB, Nitro gives 2 cores and 4 GB. Concurrency in the uncached lane is a number you can plan against rather than guess at.
A clone to rehearse on
Staging takes the risk out of a pre-show change: measure on the copy, push only what improved, and leave the live site untouched until you are sure.
Rollback in minutes
Restore files, database or both from the panel. A bad plugin update at 08:50 becomes a ten-minute problem instead of the show's problem.
Certificates reissued before expiry
Free SSL on every plan, reissued long before expiry — so a browser warning is never what greets a parent with a card in their hand.
A renewal price that does not move
You renew at the rate you ordered at. Capacity planning is hard enough without a year-two price change on top of it.
Quick Start
From order to online
- 1
Find out what is actually cached
Check the cache status header on your five busiest pages. Anything transactional should miss; everything else should hit. Fixing a wrongly-set no-cache header is usually the single biggest win available.
- 2
Baseline, then move, then baseline again
Record TTFB, field vitals and a timed test purchase. Our engineers migrate the account free and you approve before DNS switches, so the same three readings afterwards tell you exactly what the move was worth.
- 3
Freeze, rehearse, then open the doors
A week of no changes, one rehearsed restore, and a test purchase from a throttled mobile profile on the morning itself. Ticket release should be the least surprising thing that happens all term.
Built In
Loaded onto every plan
- Cache status header verified on the five pages that carry the spike
- Checkout and account pages confirmed as excluded from the page cache
- Median TTFB on the show page recorded and dated before the release
- A full test purchase timed end to end on a throttled mobile profile
- Payment gateway calls checked for synchronous blocking in the render
- A restore rehearsed from the daily backup at least once, not just assumed
- Plugin and theme freeze in place for the week before release
- NVMe storage and server-level LiteSpeed on the plan you are actually on
- Free SSL renewing itself well ahead of the release date
- Renewal billed at the rate you ordered at, with no year-two step
Frequently Asked
What people ask us most often
How many simultaneous visitors can a cached page take?
Far more than most studios expect, because a cache hit never boots PHP — the web server answers from a stored copy and the cost per extra visitor is close to bandwidth alone. The number that actually constrains you is concurrent uncached requests: checkout, account and anything logged in. Count those, not total visitors, when you are deciding whether a tier has enough headroom.
Should the checkout page be cached to make it faster?
Never. A cached checkout can serve one parent's basket to another, and it is one of the few configuration mistakes that is worse than being slow. Keep checkout, basket and account excluded from the page cache, then make them fast the legitimate way: fewer plugins running on those routes, an object cache holding repeated query results, and no synchronous third-party calls in the render path.
Does upgrading the plan fix a slow ticket morning?
Only if the bottleneck is concurrency in the uncached lane, where more cores and more memory genuinely buy you more requests in flight. If the real problem is a page that should be cached and is not, or a gateway call blocking the response, a bigger plan moves the failure later in the morning without preventing it. Measure first; the upgrade is easy afterwards and happens in place with no migration.
How long before the field data reflects a fix?
Search Console reads a rolling 28-day window of real visits, so a change made in the week before a show will not appear in the field report until well after the show. Use lab tools — a throttled Lighthouse run and a timed test purchase — for the short-term decision, and treat the field report as the verdict on the term rather than on Tuesday.
Keep reading
Nail Studios — Hosting Guide
Small treatment images, big plugin stacks: where a booking site's milliseconds go.
Online Course Creators — Hosting Guide
Video, drip content and logged-in members — the traffic a page cache cannot touch.
SSL Certificate (Glossary)
What the handshake costs, why it renews itself, and how to check it never lapsed.
VPS Hosting — Built for Dance Studios
Dedicated resources when the uncached lane, not the cached one, is your ceiling.
WordPress Hosting
Managed WordPress with Redis object caching and staging copies for the rehearsal.
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.
Test the spike before the spike tests you.
Server-level LiteSpeed, NVMe under every tier and staging copies to rehearse on — with support answering through the morning itself.
View VPS Hosting — Built for Dance Studios plans