Fluxx Tech
The worst time to discover your website cannot handle traffic is the morning your campaign goes live. The ad spend runs, people arrive, the site times out, and you pay for every one of those visits twice: once to the ad platform and once in lost sales.
Load testing is simulating that traffic before it happens.
When it is worth doing
• A festival or seasonal sale
• A product launch with advertising behind it
• A TV, radio or influencer campaign with a known spike
• Admission or registration opening at a fixed time
• Ticket sales going live
• Exam results publication
• A new site replacing one that already gets traffic
• Any event where many people arrive in the same minute
A registration that opens at 10 am sharp is harder than a sale lasting a week, because the entire load arrives in sixty seconds.
Decide the target numbers first
Testing without a target tells you nothing. Work out:
Question | How to estimate |
Expected concurrent users at peak | From past events, or ad reach and expected click-through |
Peak arrival rate | Users per minute in the busiest minute |
Key journeys | What those users will actually do |
Acceptable response time | Usually under 2–3 seconds for a page |
Acceptable error rate | Close to zero for checkout |
Duration of the peak | A minute, an hour, a day |
Then test at that number, and again at two or three times it, because campaigns over-perform as often as they under-perform.
Test real journeys, not the homepage
Hitting the homepage repeatedly proves almost nothing. Real load comes from the expensive operations:
• Homepage → category → product page
• Search with filters applied
• Add to cart → checkout → payment initiation
• Login and account pages
• Form submission
• Coupon code application
• Order confirmation
Database writes and dynamic pages are where sites fall over, not cached homepages.
Payment gateways: never load-test against a live gateway. Use their sandbox, and tell your gateway provider about the expected volume in advance.
Where sites typically break
Failure | Symptom |
Database connection limit | Errors under load, fine when idle |
Slow queries without indexes | Response time climbs steeply |
No caching | Every request rebuilds the page |
PHP or application worker limit | Requests queue, then time out |
Memory exhaustion | Crashes, restarts |
Third-party scripts | Chat widgets, analytics, pixels slowing every page |
Image delivery | Uncompressed images saturating bandwidth |
Shared hosting limits | The host throttles or suspends you |
Email or SMS sending inline | Order confirmation blocking the response |
Inventory locking | Deadlocks when many people buy the same item |
That last one matters for flash sales: a hundred people buying the last five units simultaneously is a specific and nasty failure mode. Test it deliberately.
Fixes that make the most difference
1. Caching. Page caching, object caching, and a CDN for static assets. Usually the single largest improvement.
2. Database indexes on the fields your queries filter and sort by.
3. Image optimisation. Compress, modern formats, correct sizes, lazy loading.
4. Move slow work out of the request. Emails, SMS, WhatsApp, report generation and invoice PDFs should go to a background queue, not run while the customer waits.
5. Scale the server for the event, and plan to scale back afterwards.
6. Rate limiting to stop bots and scrapers consuming capacity during the peak.
7. Remove unnecessary third-party scripts from critical pages.
8. A static fallback page for the worst case, so visitors see something rather than an error.
Also check Core Web Vitals separately; speed for one user and capacity for ten thousand are related but different problems. See our Core Web Vitals guide.
Run the test properly
1. Test against a staging environment that matches production, or production during a quiet window with the team watching
2. Start low and increase in steps, so you find where it degrades
3. Watch server metrics at the same time: CPU, memory, database connections, disk
4. Note the response time curve, not just pass or fail
5. Find the breaking point, then fix the top bottleneck
6. Re-test
7. Repeat until comfortably above your target
Tell your hosting provider before you run a large test. Unannounced load testing can look like an attack and get your account suspended.
A pre-event checklist
• ☐ Target concurrency agreed and tested at 2–3× that
• ☐ Caching enabled and verified under load
• ☐ CDN serving static assets
• ☐ Database indexed; slow query log reviewed
• ☐ Background queue handling emails, SMS and PDFs
• ☐ Server scaled up for the event window
• ☐ Payment gateway informed of expected volume
• ☐ Monitoring and alerting switched on. See our uptime monitoring guide
• ☐ A named person on standby during the peak
• ☐ Rollback plan if a last-minute change breaks something
• ☐ Code freeze for 48 hours before the event
• ☐ Backup taken immediately before
• ☐ Status page or holding page ready
The code freeze is the cheapest item on this list and prevents the most common cause of launch-day failure: a well-meaning change deployed the night before.
Frequently asked questions
How far ahead should we test? At least two to three weeks, so there is time to fix what you find and re-test.
Is load testing expensive? Open-source tools make the testing itself cheap. The cost is engineering time to fix what it reveals.
Our site is small. Do we need this? Only if you expect a spike. A steady trickle of traffic does not need load testing.
