Performance Testing Services

Latency percentiles describe the distribution of response times across all requests more informative than average latency. P50 (median) is the response time that 50% of requests complete within a good measure of "typical" experience. P95 is the response time that 95% of requests complete within a measure of the experience for most users, including those with slightly slower connections or complex queries. P99 is the response time that 99% of requests complete within captures outliers that are typically caused by garbage collection pauses, lock contention, cache misses, or cold starts. Average latency is misleading: a few very slow requests can pull the average up significantly without appearing in the P50, while the P99 reveals that 1% of your users are experiencing 10x slower responses than the median. ClickMasters defines performance SLOs as percentile targets "P95 < 200ms, P99 < 500ms" which are more meaningful than "average response time < 100ms".

Lighthouse CI is the CI/CD-compatible version of Google's Lighthouse performance auditing tool. Where standard Lighthouse is a one-time manual audit in Chrome DevTools, Lighthouse CI: runs automatically in GitHub Actions on every pull request or deployment, compares the performance score against a configured baseline or the previous commit, posts a comment on the PR with the Lighthouse report (showing score changes and metric changes), and can block the PR merge or deployment if performance degrades below a threshold. Integration: the `@lhci/cli` package is installed, a `lighthouserc.js` configuration file defines URLs to test and assertions (minimum scores, maximum metric values), and a GitHub Actions step runs `lhci autorun` after the application is deployed to a preview environment. ClickMasters configures Lighthouse CI with realistic assertions typically performance score ≥ 90, LCP ≤ 2.5s, CLS ≤ 0.1 as a mandatory quality gate before production deployment.

Performance testing measures how fast the application responds under specific conditions typically a moderate, controlled load designed to measure normal operational performance. The questions it answers: what is the P95 response time for the checkout API with 50 concurrent users? what is the Lighthouse score for the dashboard page? where are the database bottlenecks? Load testing specifically tests the application's behaviour under high or extreme load the questions it answers are different: at what concurrent user count does response time degrade significantly? where is the breaking point? does the application recover gracefully when the load spike ends? Performance testing should be done regularly (as a pre-release baseline and a CI regression gate). Load testing is done less frequently before a major launch, before a marketing campaign expected to drive a traffic spike, or when scaling decisions need evidence.