12 — 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: Frontend-specific. This file is one part of the 12_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.

Client performance#

• PERF-038 Measure Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) for eligible web experiences.

• PERF-043 Identify the actual LCP element and reduce bottlenecks in its discovery, fetch priority, and rendering.

• PERF-044 Reduce unnecessary JavaScript execution, long main-thread tasks, and expensive event handlers affecting responsiveness.

• PERF-046 Use efficient image formats, responsive sources, explicit dimensions, and appropriate compression for target devices.

• PERF-048 Optimize font loading, subsets, fallbacks, and layout behavior to avoid unnecessary blocking or visual shifts.

• PERF-049 Reserve space for images, ads, embedded media, and asynchronous UI to limit unexpected layout shifts.

• PERF-037 Identify representative page templates and critical interactions for field and laboratory measurements.

• PERF-039 Assess Core Web Vitals at the 75th percentile separately for mobile and desktop, using current recommended thresholds or explicit project targets.

• PERF-040 Distinguish real-user field measurements from controlled laboratory results and investigate important disagreements.

• PERF-045 Apply route- or feature-level code splitting when it measurably reduces critical startup work.

• PERF-047 Defer below-the-fold media and third-party resources where doing so does not delay critical content.

• PERF-050 Measure hydration and client-rendering cost for relevant server-rendered or hybrid pages.

• PERF-051 Inspect network waterfalls to remove redundant requests and unnecessary render-blocking dependencies.

• PERF-052 Verify that changes improving metrics do not remove required accessibility, usability, or essential functionality.

Frontend Checks#

• PERF-088 Measure field LCP, INP, and CLS for key routes, segmented by device class and relevant user cohorts.
• PERF-089 Compare lab performance under defined network and CPU throttling with observed real-user results.
• PERF-090 Ensure the primary content and key action are visible without waiting for avoidable noncritical scripts.
• PERF-091 Check that critical images, fonts, styles, and scripts are prioritized correctly during initial loading.
• PERF-092 Use responsive images, modern formats, compression, and appropriate dimensions for content images.
• PERF-093 Lazy-load below-the-fold assets where appropriate without lazy-loading essential above-the-fold content.
• PERF-094 Limit initial JavaScript and remove unused packages or code that delays interaction.
• PERF-095 Break up expensive main-thread work and optimize input, event handlers, and rendering paths affecting INP.
• PERF-096 Avoid redundant hydration, cascading state updates, and large synchronous calculations in common interactions.
• PERF-097 Reserve layout dimensions for delayed content and test dynamic banners, overlays, and font swaps for CLS.
• PERF-098 Optimize CSS delivery and avoid unnecessary render-blocking work on important page templates.
• PERF-099 Configure browser and CDN caching for fingerprinted immutable assets while keeping HTML and user-specific data appropriately fresh.
• PERF-100 Verify service-worker caches and offline support do not leave users on incompatible or stale application versions.
• PERF-101 Test on representative low-end mobile devices and constrained networks, not solely high-end desktop hardware.
• PERF-102 Profile long lists, virtualized grids, charts, and heavy components for scrolling and input responsiveness.
• PERF-103 Measure the performance impact of analytics, advertising, consent, embeds, and other third-party scripts.
• PERF-104 Provide comprehensible progress and recovery states for slow API calls without disguising failures or blocking accessible interactions.
• PERF-105 Check that performance optimizations preserve focus behavior, keyboard interaction, labels, and reduced-motion requirements.
• PERF-106 Monitor browser runtime errors and release-specific performance regressions after deployment.

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 browser and client behavior 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 frontend 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.