Web Performance Framework
For retail-scale digital platforms. Engineering execution playbook.
Purpose: This framework covers three domains and removes ambiguity about what "done" means. Every item below is either a must-do (non-negotiable, auditable) or a metric (measured, alerted, owned). Seasonality is treated as a core economic variable with a dedicated playbook.
1. Three Domains
Performance at scale is three separate problems. They fail independently.
| Domain | What breaks | Who owns it |
|---|---|---|
| A. Client/Edge | Slow pages, bad mobile experience, CDN misses | Frontend/Web Platform |
| B. Application/Infra | Service latency, cascading failures under load | Platform/SRE |
| C. Data Platform | Stale inventory/pricing, slow search & recs, pipeline backpressure | Data Engineering |
Most orgs over-invest in A because it is visible. Domain C is usually the biggest hidden gap. Confirm which domain actually needs investment before committing budget to any one of them.
2. Must-Do Items (non-negotiable, auditable)
A. Client/Edge
- LCP < 2.5s at p75, mobile, on the top 20 revenue-generating page templates
- CDN cache hit ratio > 95% for static assets; miss-rate alerting in place
- JS payload budget enforced on first load; CI fails the build if exceeded
- Image pipeline mandatory: modern formats (AVIF/WebP), responsive
srcset, no unoptimized uploads reach prod - Third-party/tag governance: async-only loading, budgeted script count, quarterly audit
B. Application/Infrastructure
- Every service has a published SLO (latency and error rate) tied to a business-criticality tier (Tier 1 = checkout/search, Tier 3 = internal tools)
- Autoscaling policies load-tested at 3x peak quarterly, as a scheduled game day
- Circuit breakers and bulkheads on all cross-service and third-party calls
- Capacity plan refreshed 90 days before every known peak event
- Cost-per-transaction tracked per Tier 1 service; alert on 15%+ drift
C. Data Platform
- Search and recommendation latency SLO defined and monitored per index
- Inventory/pricing freshness SLA defined and monitored as a measured metric
- Every streaming pipeline has explicit backpressure handling; silent drops trigger a Sev alert
- Cache/feature-store warm-up runbook exists and is rehearsed before peak events
- Query cost governance on prod warehouses; unbounded scans require review before shipping
Rule: a box is checked only with evidence: a dashboard, a runbook, a test result.
3. Metrics & Measures
| Domain | Metric | Target (set your number) | Cadence |
|---|---|---|---|
| A | LCP / INP / CLS (Core Web Vitals) | p75 threshold | Real-user monitoring, continuous |
| A | CDN hit ratio | >95% | Continuous |
| A | JS/CSS payload | Budget per template | Per-deploy (CI gate) |
| B | Service latency (p50/p95/p99) | Per SLO tier | Continuous |
| B | Error rate | Under SLO threshold | Continuous |
| B | Cost per transaction | Baseline ±15% | Weekly |
| B | Peak-load test pass/fail | 3x current peak | Quarterly |
| C | Search/recs latency | Per index SLO | Continuous |
| C | Data freshness (inventory/price) | Per SLA | Continuous |
| C | Pipeline lag / backpressure events | Zero silent drops | Continuous |
| C | Warehouse query cost anomalies | Flag 2+ std dev | Daily |
Every metric needs an owner, a dashboard, and an alert threshold. A metric without an alert is trivia.
4. Seasonality: Economic Elasticity Playbook
Three levers, used together.
Compute elasticity. Autoscaling policies are pre-tested at peak, not first-used at peak. Scale-down triggers get the same rigor as scale-up triggers. Cost bleed after peak is the most common miss.
CDN/edge spend flexibility. A tiered caching strategy shifts more load to edge during peak. Burst pricing gets confirmed contractually before the season begins.
Vendor/contract terms. All usage-based third-party dependencies (search, personalization, payments, tag management) get audited annually for peak-tier pricing and rate limits. Renegotiation happens before the season, never during it.
The trap to name explicitly: teams solve for reaching peak and forget to solve for returning to baseline. Build the down-scale trigger with the same rigor as the up-scale trigger.
5. Maturity Model
Five levels, scored per domain. Score A, B, and C independently. Different levels across domains is the expected and useful outcome.
| Level | Name | Characteristics |
|---|---|---|
| 1 | Ad Hoc | No SLOs. Performance is a post-incident conversation. |
| 2 | Reactive | Metrics and dashboards exist. Action happens after alerts fire. |
| 3 | Managed | Must-dos above are checked and enforced. Capacity is planned ahead of peaks. |
| 4 | Proactive | Continuous load testing. Cost-per-transaction actively managed. Runbooks rehearsed. |
| 5 | Optimized | Autoscaling and backpressure self-correct. Humans handle exceptions only. |
Most orgs sit at level 2 to 3 in domain A, and level 1 to 2 in domain C. That gap is your prioritization signal.
6. Prioritization: Impact x Complexity
Score each must-do gap on two axes. Plot. Act in this order:
High Impact, Low Complexity -> DO FIRST (quick wins)
High Impact, High Complexity -> PLAN (roadmap items, get exec sponsorship)
Low Impact, Low Complexity -> DO IF IDLE (backlog filler)
Low Impact, High Complexity -> DECLINE (say no explicitly)
Typical first-quarter placements at retail scale:
- Do first: CDN hit-ratio tuning, JS budget CI gates, cost-per-transaction alerting
- Plan: cross-service circuit breakers, data freshness SLA instrumentation, quarterly peak game-days
- Decline for now: domain C autoscaling automation. High complexity and low near-term impact until domain B reaches level 3.
Open questions to pressure-test with your teams
- Do Tier 1 services have published SLOs today, or informal ones?
- Where is the single biggest unknown: domain A, B, or C? An unclear answer here is itself the level-1 signal for that domain.
- Who owns the decision to scale back down after peak? Confirm this is someone's explicit job today.