Solution Pack: Performance-Critical Lead Funnel
Architecture summary
Decision: build a server-rendered or statically cached acquisition funnel with minimal critical JavaScript, strict third-party governance, consent-aware measurement, route-level Web Vitals budgets, experiment isolation, and fast rollback for variants.
System sketch
Key decisions
| Decision | Choice | Reason |
|---|---|---|
| Rendering | static/edge-cached shell with hydrated form island | fastest first useful state and low JavaScript |
| Measurement | first-party typed collector | privacy, control, and destination governance |
| Experiments | server or edge assignment where possible | avoids layout shift and client flicker |
| Third parties | deny-by-default on critical path | protects LCP, INP, privacy, and reliability |
| Form submission | server-validated mutation with idempotency | prevents duplicate leads and unsafe trust |
Performance budget
| Budget | Target evidence |
|---|---|
| LCP | field p75 by route, device, campaign |
| INP | p75 form interaction and CTA click |
| CLS | variant and font/image stability |
| JavaScript | critical route bundle cap |
| Third-party cost | transfer and main-thread budget per vendor |
Failure matrix
| Failure | UX | Control |
|---|---|---|
| lead API timeout | preserve form and retry | idempotency key and retry state |
| analytics blocked | lead workflow continues | first-party collector and delivery metric |
| experiment misconfigured | default variant | server-side flag rollback |
| attribution unavailable | dashboard shows uncertainty | no product flow dependency |
| script causes INP regression | disable vendor | script budget alert and kill switch |
ADR bundle
ADR 1: Static or edge-cached shell with form island
Context: the funnel is acquisition-critical and most visitors need content and a lead form, not a full app shell.
Decision: render the marketing content as static or edge-cached HTML and hydrate only the form, experiment exposure, and consent-aware measurement.
Consequences:
- excellent first useful state
- lower JavaScript and hydration cost
- requires careful cache variation for experiments and locale
- dynamic personalization must be isolated
Verification:
- p75 LCP by campaign and device
- JavaScript transfer budget
- CLS by variant
- cache hit ratio
ADR 2: First-party measurement gateway
Context: the funnel needs conversion analytics, attribution, experiments, and performance telemetry without uncontrolled vendor collection.
Decision: send typed events to a first-party collector, then route to destinations by consent, purpose, and policy.
Consequences:
- stronger privacy and schema control
- more platform implementation work
- easier vendor replacement
- better sensitive-field rejection
Verification:
- event schema validation failure rate
- events dropped by consent/policy
- sensitive-field rejection tests
- destination routing audit
ADR 3: Experiment assignment outside the critical client path
Context: client-side experiment flicker and late variant loading can harm LCP, CLS, and trust.
Decision: assign variants server-side or at the edge where possible. Client-side experiments are allowed only for low-risk, post-load enhancements.
Consequences:
- better visual stability
- more cache-key complexity
- requires experiment metadata in observability
Verification:
- CLS by variant
- cache key review
- rollback by variant flag
- conversion and Web Vitals segmented together
Review gates
| Gate | Required evidence |
|---|---|
| Performance | route budget, Web Vitals dashboard, trace for form interaction |
| Privacy | consent-aware loading and event schema review |
| Third-party | completed third-party register with kill switches |
| Experimentation | cache/variant safety review and rollback plan |
| Reliability | lead submit idempotency and retry behavior |
| Accessibility | form labels, errors, focus, and target-size review |
Rollout plan
- Launch baseline route with no experiments and no nonessential third parties.
- Verify Web Vitals and form completion.
- Add analytics through first-party collector.
- Add one experiment with server/edge assignment.
- Add attribution pilot only after privacy and browser-support review.
- Review performance and conversion together before expanding campaign traffic.
Strong reviewer concerns
- Do not let marketing tags bypass the first-party collector.
- Do not treat attribution numbers as exact truth.
- Do not ship variant assignment that creates layout shift.
- Do not measure only Lighthouse; field data by route/campaign/device is required.
Portfolio artifacts
- route budget table
- third-party register
- experiment rollout plan
- attribution uncertainty note
- lead form mutation ADR
- Web Vitals dashboard specification