Key performance metrics to judge 1M-visit readiness
What to measure before a big traffic wave
You plan to serve a huge crowd. Hitting one million visits is great, but it can break a slow site. The fix is simple: track the right numbers early, and test often. The metrics below show if your stack is ready. They also show where to tune first for the biggest wins.
Know your traffic shape
- Peak vs average: One million visits in a day is not the same as a month. Peaks cause pain.
- Requests per second (RPS): Count all requests, not just pages. APIs, images, CSS, and JS count too.
- Concurrent users: A fast site can serve more users at once. Slow pages pile up and choke the server.
- Simple rule of thumb: More cache hits + lower response time = fewer servers needed.
Core speed signals users feel
Web Vitals that matter
These are user-facing speed scores. They predict bounce and sales.
- Largest Contentful Paint (LCP): Aim under 2.5s at the 75th percentile.
- Interaction to Next Paint (INP): Aim under 200ms at the 75th percentile.
- Cumulative Layout Shift (CLS): Aim under 0.10.
Learn more from Google’s guide: Core Web Vitals.
Time to First Byte (TTFB)
TTFB shows how fast the server and network respond. Keep it under 200ms on cached hits and under 500ms on origin for most pages. Place a CDN close to users and cut slow database calls to lower it. See Google’s TTFB guidance.
P95 and P99 latency
Average time hides pain. Track the slowest tails. P95 means 95% of requests are faster than this value. Set clear goals, like “P95 under 600ms, P99 under 1.2s” during peak.
Reliability under load
Error rate
- 5xx errors: Keep under 0.1% at peak.
- 4xx spikes: Often rate limits or bad cache rules. Fix at the edge.
Saturation and headroom
- CPU: Stay under 70% at peak. Spikes to 100% cause timeouts.
- Memory: Watch for swap or out-of-memory kills. Keep a 30% buffer.
- Database: Track queries per second, slow query count, and lock time.
- Thread/worker pools: Queue depth should be near zero under steady load.
Cache hit ratio and origin offload
- CDN cache hit ratio: Aim 80%+ for static and 50%+ for HTML if using edge caching.
- Origin offload: Keep 70%+ of traffic served from edge to protect your origin.
Great primers: What is a CDN? and Caching basics.
Capacity and cost signals
Throughput
- Sustained RPS: Can you hold your peak for at least 30 minutes?
- Burst RPS: Can you absorb a 2× spike for 5–10 minutes without errors?
Network and edge
- DNS time: Keep under 50ms. Use a fast DNS.
- TLS handshake: Reuse connections; use HTTP/2 or HTTP/3.
- Bandwidth: Watch egress. CDNs cut cost and keep speed stable.
Autoscaling and cold starts
- Scale-up lag: New capacity should be ready in under 2 minutes.
- Serverless cold starts: Keep warm pools or pre-warm paths for hot APIs.
See the cloud lens on scale: AWS Well-Architected and Google Cloud Architecture Framework.
Observability that catches real issues
Real User Monitoring (RUM)
Track live users, not just tests. Capture Web Vitals, device, network, and location. Tools like RUM for Web Vitals, Grafana, and New Relic help.
Service-level goals
- Set SLOs: For example, “99.9% availability, P95 under 600ms.”
- Alert on burn rate: Warn fast when you are missing targets.
Test it before the spike
Load patterns to run
- Baseline test: Find current limits.
- Stress test: Push until it breaks. Note the first fail point.
- Soak test: Hold load for hours. Watch leaks and slow creep.
Trusted tools
- k6 for modern, scriptable load tests.
- Locust for Python-based user flows.
- WebPageTest and PageSpeed Insights for front-end speed.
Simple test plan
- Map top 10 pages and APIs.
- Build scripts that match real paths and cache rules.
- Warm the CDN, then test cold and warm runs.
- Step up load every 2 minutes until you hit 2× your peak.
- Record CPU, memory, RPS, P95/P99, errors, and cache hits.
Target guardrails you can use today
| Metric | Healthy target at peak | How to measure | Why it matters |
|---|---|---|---|
| CDN cache hit ratio | 80%+ static, 50%+ HTML | CDN analytics | Reduces origin load and egress cost |
| RPS sustained | Meets 1.2× planned peak for 30+ min | Load test (k6, Locust) | Shows true capacity, not just bursts |
| P95 latency | < 600ms | APM, load tests | Protects most users from slow tails |
| P99 latency | < 1.2s | APM, load tests | Prevents timeouts and cart drops |
| TTFB (edge/origin) | < 200ms edge, < 500ms origin | RUM, WebPageTest | Faster first paint and data fetch |
| LCP (p75) | < 2.5s | RUM, PageSpeed | Better user feel and SEO |
| INP (p75) | < 200ms | RUM, PageSpeed | Fast clicks and scrolls |
| CLS (p75) | < 0.10 | RUM, PageSpeed | Stops page jump and misclicks |
| Error rate (5xx) | < 0.1% | APM, logs | Reliability during spikes |
| CPU usage | < 70% at peak | Host metrics | Headroom for bursts |
| DB slow queries | < 1% over 500ms | DB profiler | Prevents lock and queue buildup |
| Autoscale readiness | < 2 min to add nodes | Chaos drills | Quick recovery and cost control |
Action checklist
- Set SLOs for P95, error rate, and uptime.
- Push more cache to the edge. Add stale-while-revalidate.
- Trim image and script weight. Use compression and HTTP/2 or HTTP/3.
- Fix slow queries. Add indexes and tune pool sizes.
- Test with real flows. Record and repeat the top 10 user paths.
- Alert on tail latency and error bursts, not just averages.
Want deeper benchmarks and guides? Try Lighthouse, Grafana docs, and New Relic docs. These help you measure, test, and tune with confidence.
