Know Your Site Will Hold Before It Has To

A test is only as useful as the traffic it imitates, so the profile comes from your own analytics rather than a round number. We look at which pages carry real volume, the ratio of browsing to checkout, how many users are signed in versus anonymous, and the think time between actions, because a script with no pauses generates a pattern no human population produces. Peak concurrency from your busiest recent day sets the starting point, and the ramp climbs from there. Getting that mix wrong is the most common reason a comfortable test result is followed by a bad launch day.

A soak test holds a moderate load for hours instead of pushing for a peak, and it finds a different class of fault. Memory leaks, connection pools that never release, log files filling a disk and caches that grow without bound all look perfectly healthy in a twenty minute run and surface somewhere around hour six. It earns its place if your site stays busy for long stretches, during a multi day sale for instance, or if you have ever watched performance degrade until somebody restarts the application. If a restart fixes it, that is precisely the symptom a soak test is built to reproduce.

Usually because the test environment differs in a way that matters more than it looks. Three things account for most of the gap: data volume, since a staging database holding a thousand products behaves nothing like one holding two hundred thousand; cache state, because a warm production cache hides work that a cold environment performs in full; and third party services, which are often stubbed or rate limited outside production. We document those differences before testing rather than after, and where a gap cannot be closed we say which direction it biases the result, so every number is read with the right caveat attached.

Because server metrics only measure the part of the journey that ends when the response leaves your infrastructure. If the server answers in 200 milliseconds and the page still takes six seconds to become usable, that time is going into what happens in the browser: render blocking scripts, fonts, images without reserved dimensions, and third party tags for analytics, chat and advertising that your own monitoring never sees. Interaction to Next Paint is a front end measurement in particular, so a comfortable server response can sit right alongside a poor score. We measure both sides for exactly this reason, because fixing the wrong half is expensive and changes nothing.

Tie it to change rather than to the calendar, with one standing exception. Retest before each known traffic event, and after any release touching checkout, search, a major integration or the caching layer, since those are where regressions actually enter. Beyond that, a light quarterly run catches the slow drift that comes from growing data volume, because a query that was fast against fifty thousand orders can be slow against half a million with no code change at all. Teams shipping weekly usually get more value from a small automated test inside the deployment pipeline than from occasional large set piece exercises.

We plan so that it does not. Tests normally run against a staging or dedicated environment that mirrors production closely enough for the results to mean something, which keeps real customers entirely out of it. Where testing against production is genuinely necessary, and occasionally it is because staging cannot reproduce a third party dependency, we schedule a low traffic window, agree limits and monitoring in advance, and keep the ability to stop immediately. Protecting the live service is part of designing the test rather than a precaution added at the end, and we will tell you plainly which approach your situation needs.

Less than most teams expect. An environment resembling production closely enough to be meaningful, credentials for test accounts, and clarity on which journeys matter commercially, which is usually browse, search, add to cart and checkout. We also need to know what is safe to touch: whether payment is in sandbox, which emails, webhooks and warehouse integrations must be suppressed so a run never reaches real customers, and an agreed window with a named contact who can stop the test. Suppressing outbound integrations is the item forgotten most often, and it is the one that produces an awkward phone call.

For generating load we use k6, JMeter, Gatling and Locust, chosen to fit your stack rather than our habits. For front end and Core Web Vitals work we use Lighthouse, WebPageTest and real user data from the Chrome UX Report, which matters because lab numbers and field numbers regularly disagree and only the field data reflects your actual visitors. For finding causes we profile the application and database with tools such as Blackfire and query analysis, watching the system through Grafana and Prometheus while the test runs. We prefer widely used tools so your team can rerun the tests without us.

A focused load test of a specific journey such as checkout, with findings and recommendations, typically takes one to two weeks including setup, execution and reporting. Setup is usually the longest part, because realistic test data and a working test environment take longer to arrange than the tests take to run. A broader engagement covering several journeys, stress and soak testing, and implementation of the fixes runs longer. If you have a fixed date such as a sale, say so at the start and we will scope the work to give you a dependable answer while there is still time to act on it.

Yes. Because the DevOps and development teams are in house, we can implement what a test surfaces, whether that means adding database indexes, tuning queries, introducing caching, right sizing infrastructure or optimizing front end assets, then retest to demonstrate the gain rather than assert it. That retest is the part worth insisting on, from us or anyone else, because a fix that was reasoned about but never measured is still a hypothesis. Some clients want the fixes handled end to end, others want a ranked plan for their own team. Either way you finish with something actionable, not just a diagnosis.