Source-Derived Review Playbooks

Why this chapter matters

Architecture knowledge only scales when teams can reuse it during real delivery. These playbooks convert the source-backed chapters into practical review prompts. Use them during RFCs, design reviews, pull-request risk reviews, launch readiness, and incident follow-up.

Each playbook is intentionally short. The goal is not to replace judgment; it is to force the right conversations before a decision becomes expensive.

For fuller team-ready artifacts, use the dedicated Architecture Review Packets section. Those packets expand these prompts into intake questions, required artifacts, decision matrices, red flags, approval criteria, reviewer comments, ADR prompts, and release readiness checklists.

Core mental model

A review playbook should answer four questions:

• What user outcome are we protecting?
• What architectural boundary can fail?
• What evidence proves the design is safe enough to ship?
• What rollback or degradation path exists if we are wrong?

Mobile Network Review

Use for mobile-heavy journeys, offline-capable flows, background sync, polling, realtime, and data-heavy routes.

Review prompts

• What is the target device and network profile?
• Which requests are critical for the first useful view?
• Which requests can be deferred, cached, batched, or removed?
• What happens when connectivity changes during a task?
• Does background work stop or downgrade when the tab is hidden?
• Are retries bounded and cancelable?
• Is user intent preserved during poor connectivity?

Evidence to require

• request waterfall on realistic mobile network
• p75 mobile LCP and INP by route
• duplicate request audit
• retry/timeout behavior
• offline or poor-network UX states

Edge Delivery Review

Use for CDN changes, NGINX/proxy changes, static asset strategy, cache policy, compression, redirects, and launch readiness.

Review prompts

• What is cached at browser, CDN, proxy, and origin layers?
• Are static assets immutable and safely retained across deploys?
• How is HTML cache freshness controlled?
• Are compression rules verified for text assets?
• What happens when an origin becomes unhealthy?
• Is cache purge scoped, authenticated, and logged?
• Can logs correlate request, route, cache state, upstream time, release, and status?

Evidence to require

• cache header examples for HTML, JS, CSS, fonts, images, and API responses
• edge cache hit ratio
• access log fields
• purge runbook
• canary or rollback path for delivery changes

Browser Security Review

Use for user-generated content, raw HTML, third-party scripts, auth/session changes, CORS changes, embedded experiences, and cross-origin communication.

Review prompts

• What attacker-controlled inputs reach the browser?
• Which DOM, URL, HTML, style, script, or storage sinks can they influence?
• Is CORS being used correctly and not as authorization?
• What CSRF defense protects state-changing requests?
• Can this page be framed or can it open unsafe external tabs?
• Which third-party scripts run, what data can they access, and who owns them?
• Are browser dependencies monitored and updateable?

Evidence to require

• sink inventory for raw HTML and dynamic DOM writes
• CSP or Trusted Types rollout state
• CORS rule owner and test cases
• cookie and CSRF policy
• third-party script register with kill switches
• dependency risk scorecard

Inclusive Component Review

Use for shared components, design-system additions, interaction primitives, and accessibility retrofits.

Review prompts

• What native element or role expresses the behavior?
• What is the keyboard model?
• Where does focus move on open, close, selection, error, and route change?
• What is the accessible name and state?
• Which changes need live-region announcements?
• How does it behave at zoom, reduced motion, touch, and screen-reader usage?
• Which behavior must product teams not override?

Evidence to require

• component recipe with semantics, keyboard, focus, name, and state
• Storybook or docs covering states
• keyboard test
• manual assistive technology notes for high-risk primitives
• duplicate component migration plan

React Rendering Performance Review

Use for slow interactions, route performance regressions, large client components, hydration-heavy pages, data grids, and shared state changes.

Review prompts

• What user action or route is slow?
• What state update triggers the expensive work?
• Is the bottleneck network, JavaScript load, hydration, render, layout, garbage collection, or third-party code?
• Is state placed too high in the tree?
• Does the route hydrate more UI than needs immediate interactivity?
• Are lazy or Suspense boundaries aligned with user-visible chunks?
• Is memoization based on profiling evidence?

Evidence to require

• React profile for the slow interaction
• browser performance trace
• route JavaScript and hydration budget
• p75 INP by route/device
• list size and virtualization decision
• before/after measurement tied to release

Cross-playbook launch checklist

• User-facing risk is stated in product language.
• Runtime boundary is documented.
• Owner exists for the surface and exceptions.
• Pre-release evidence exists.
• Production signal exists.
• Rollback or degradation behavior is documented.
• Follow-up debt has owner and expiration date.

Decision record templates

Mobile network ADR

Use when a feature adds polling, realtime, offline behavior, background sync, or mobile-heavy media.

Field	Prompt
Context	Which user journey and mobile cohort are affected?
Decision	What network strategy is chosen: manual refresh, polling, push, SSE, WebSocket, prefetch, offline queue?
Freshness	How fresh must the data be and what harm comes from staleness?
Battery/data	What background request and byte budget applies?
Failure	What happens on timeout, offline, retry exhaustion, and app resume?
Verification	What lab and RUM evidence proves the strategy works?
Kill switch	How is the strategy disabled or downgraded?

Edge delivery ADR

Use when changing cache headers, CDN rules, proxy behavior, redirects, compression, or deploy strategy.

Field	Prompt
Context	Which routes/resources are affected and who owns them?
Decision	What is the cache/proxy/compression/load-balancing behavior?
Freshness	What stale behavior is acceptable?
Safety	How are private, tenant, locale, and experiment boundaries protected?
Deploy	What ordering prevents HTML/asset mismatch?
Observability	Which logs and metrics prove behavior?
Rollback	How do we purge, revert, or drain safely?

Browser security ADR

Use when adding raw content rendering, CORS, cross-origin messaging, embeds, auth/session changes, or third-party scripts.

Field	Prompt
Context	What new trust boundary or attacker-controlled input exists?
Decision	What policy, wrapper, header, or isolation mechanism is used?
Sources/sinks	Which inputs can reach which browser capabilities?
Server authority	Where is authorization enforced?
Browser policy	What CSP, Trusted Types, frame, opener, CORS, or cookie rules apply?
Monitoring	Which violations, errors, and owner signals are tracked?
Incident path	How is the risky path disabled quickly?

Inclusive component ADR

Use when adding or changing a shared primitive.

Field	Prompt
Purpose	What user task does this component support?
Pattern	Native element, ARIA pattern, or custom behavior?
Keyboard	What is the exact keyboard model?
Focus	Entry, movement, trap if any, and return behavior?
Names/states	Accessible names, roles, properties, and error/loading states?
Overrides	Which behavior must consumers not change?
Verification	Which automated and manual checks are required?

React performance ADR

Use when optimizing a measured React route or interaction.

Field	Prompt
Symptom	Which user-visible metric or action is slow?
Evidence	RUM, browser trace, React profile, bundle analysis?
Cause	Load, hydration, render fan-out, layout, list pressure, third-party, memory?
Decision	State boundary, route split, virtualization, server/client move, memoization, dependency removal?
Tradeoff	What complexity, loading state, or maintainability cost is added?
Verification	Before/after lab trace and production cohort metric?
Guardrail	What prevents recurrence?

Acceptance criteria examples

Use these as concrete review gates:

Change type	Minimum acceptance criteria
New polling feature	interval justified, visibility-aware, bounded retries, background request metric, kill switch
New CDN cache rule	cache key documented, private data protected, purge scope defined, hit ratio monitored
Raw HTML rendering	sanitizer wrapper, sink lint rule, CSP/Trusted Types plan, malicious fixture tests
Shared dialog	labelled title, focus entry/trap/return, Escape policy, keyboard and screen reader check
Data grid optimization	trace identifies cause, virtualization/pagination decision, p75 INP check, before/after profile

Incident follow-up prompts

After a production issue, ask:

• Which architectural assumption was false?
• Which review question would have exposed it?
• Which metric should have alerted earlier?
• Which default should change so teams do not repeat the mistake?
• Which exception needs an expiration date?
• Which artifact should be updated: ADR template, checklist, component recipe, runbook, lint rule, dashboard?

The best postmortem output is not a longer checklist. It is a sharper default.

Source Lens

These playbooks summarize the new source-backed chapters derived from:

• High Performance Browser Networking
• Mastering NGINX for Site Reliability
• Web Application Security, 2nd Edition
• Web Security for Developers
• Grokking Web Application Security
• Inclusive Components
• Web Performance Fundamentals
• Web Performance Engineering in the Age of AI