09 — Performance and Scalability Checklist#

Verify that priority user experiences and services meet documented latency, throughput, capacity, and efficiency objectives at realistic demand. Separate browser metrics from backend metrics; avoid treating a single benchmark as production capacity proof.

Scope: Shared / cross-cutting. This file is one part of the 09_Performance_and_Scalability.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

• Project / product:
• Release / version / environment:
• Scope and applicable jurisdictions / markets:
• Target workloads, user cohorts, and devices:
• Performance budgets / SLO references:
• Reviewer / owner:
• Review date:
• Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

1. Copy this template into project-specific review records; leave the shared template unchecked.
2. Mark [x] only after verifying a check through a reproducible test, representative field measurement, resource profile, capacity model, or documented decision. Record failed items and N/A reasons outside this template, keyed by PERF ID.
3. Use realistic traffic mixes, data sizes, network/device conditions, and explicit percentiles. Document environment limitations and do not use synthetic tests alone to claim production performance.
4. Review API and frontend performance separately where relevant. An API-only service or static page may make some checks inapplicable; document why in project records.
5. Revisit budgets and tests after workload growth, architecture changes, large frontend changes, or major dependency updates. Coordinate functional correctness, security, reliability, accessibility, and cost reviews with their dedicated checklists.

Performance budgets and measurements#

• PERF-001 Define performance objectives for the most important user journeys and system operations, including measurement units and owner.
• PERF-002 Set measurable budgets for latency, throughput, error rate, resource use, and user-perceived responsiveness appropriate to the product.
• PERF-003 Specify response-time percentiles (such as p50, p95, and p99) instead of relying only on arithmetic averages.
• PERF-005 Define acceptable latency and error behavior for steady-state traffic, peak periods, and anticipated growth.
• PERF-006 Record baseline measurements for critical journeys and endpoints before major performance work.
• PERF-007 Distinguish end-user elapsed time from server processing, queuing, network, rendering, and third-party dependency time.
• PERF-008 Instrument enough spans, metrics, and structured events to identify the dominant latency contributor without exposing sensitive data.
• PERF-009 Set meaningful service-level objectives or performance acceptance criteria where operationally appropriate.
• PERF-010 Document the target test environment's differences from production and how each affects interpretation of results.
• PERF-011 Use representative synthetic or anonymized datasets, including realistic record counts, sizes, and distribution.
• PERF-012 Define performance regression thresholds and compare results against the same test methodology and environment.
• PERF-013 Track performance by build or release version so regressions can be associated with changes.
• PERF-014 Measure resource utilization and saturation alongside user-facing metrics to avoid celebrating throughput that harms reliability.
• PERF-015 Document testing methods, tool versions, traffic models, warm-up periods, and statistical limitations for repeatability.
• PERF-016 Assign an owner and due date for each material violation of a budget or service-level target.

Release gate#

• Performance budgets, workload assumptions, target cohorts, and accountable owners are defined for the release's critical journeys and endpoints.
• Representative baseline and relevant peak-load tests meet documented latency, throughput, error-rate, and saturation criteria, with acknowledged test-environment limitations.
• Major backend or database bottlenecks, cache behavior, and overload/recovery paths are measured and either addressed or accepted with authorized risk ownership.
• Applicable frontend routes have measured Core Web Vitals or equivalent user-centric measures, and critical interaction regressions have been reviewed.
• Expected peak/growth demand has a documented capacity plan, scaling constraints, monitoring signals, and safe response to saturation.
• No unresolved critical performance failure jeopardizes core tasks or overload recovery without an explicit, time-bound acceptance and mitigation plan.

Domain-specific approval rule: Block performance sign-off when material latency or capacity targets are missing, critical workflows breach agreed thresholds without approved mitigation, overload causes uncontrolled failure, or regressions remain unowned. Benchmarks and Web Vitals are context-dependent; meeting a public threshold is not a universal performance guarantee.

Trusted references and scope#

These actionable checks are informed by the following primary engineering and standards sources; they do not reproduce the source publications or imply certification.

• AWS Well-Architected Framework — Performance Efficiency Pillar — workload selection, load testing, resource efficiency, and continual improvement.
• AWS Well-Architected — Performance process and culture — measurement, automated performance tests, and performance tuning.
• Google SRE — Production Services Best Practices — forecasting, measured capacity, and overload behavior.
• Google SRE — Handling Overload — backpressure, throttling, and overload defenses.
• Grafana k6 — Load Testing Websites — realistic traffic profiles, backend versus browser testing, and test scope.
• Grafana k6 — Automated Performance Testing — smoke, average-load, stress, spike, and soak test planning.
• web.dev — Web Vitals — LCP, INP, CLS, 75th-percentile thresholds, and field measurement.
• web.dev — Learn Performance — loading, code splitting, image loading, and client responsiveness.
• OpenTelemetry — Metrics — request latency, throughput, resource utilization, and telemetry cardinality.
• PostgreSQL — Using EXPLAIN — query planning and database bottleneck analysis when PostgreSQL is used.
• MDN — HTTP Cache-Control — browser and shared cache semantics, freshness, and private responses.

Applicability: Apply web-specific metrics only to applicable web experiences. Current commonly used Core Web Vitals 'good' thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, assessed at the 75th percentile of real-user page loads for mobile and desktop separately; verify current official guidance when reviewing. PostgreSQL, cloud-native autoscaling, CDN, and asynchronous queue checks apply only if the architecture uses them. Never perform high-volume tests against infrastructure or third-party services without authorization.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

• Test focus: throughput, latency percentiles, browser responsiveness, and resource budgets; include shared/cross-team controls where applicable.
• Cross-stack: k6 + Lighthouse.
• Python: Locust + pytest-benchmark + pytest; for pytest-based suites, run python -m pytest -q.
• TypeScript: Playwright + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
• JavaScript: autocannon + Lighthouse CI + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
• Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

• performance-optimization — Review profiling, budgets, and bottlenecks (addyosmani/agent-skills, 116,378 repo stars).
• web-perf — Audit web performance when deployed on the web (cloudflare/skills, 3,349 repo stars).
• python-performance-optimization — Examine Python service hotspots where applicable (wshobson/agents, 42,437 repo stars).

How to check: In a project-specific copy, have the agent audit the shared / cross-cutting scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.