What are P50, P95, and P99 latency percentiles and why do they matter?
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".
What is Lighthouse CI and how does it integrate with a CI/CD pipeline?
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.
What is the difference between performance testing and load testing?
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.
How do you identify the cause of a slow API response?
Diagnosing a slow API response requires measuring where time is spent in the request lifecycle. ClickMasters uses a layered approach: total response time measured by k6 (the end-to-end time from request send to response received the user-visible latency), server-side timing breakdown (instrumented with OpenTelemetry spans measure time spent in each middleware, each database query, each external API call, each computation), database query timing (pg_stat_statements identify the slowest queries in the call path, run EXPLAIN ANALYZE on each), external API timing (if the endpoint calls a third-party API, measure the round-trip time identify if a slow downstream service is the bottleneck), and application CPU profiling (Node.js inspector or clinic.js if response time is high but database queries are fast, CPU-bound computation in the application code is the bottleneck). The root cause is almost always in one of three places: an unindexed database query (a sequential scan on a large table), an N+1 query pattern, or a slow external API call that should be asynchronous.
