REFINE Web-Performance Audit

Objective. Produce a web-performance audit: Core Web Vitals and load/checkout-speed issues diagnosed across the key page types, prioritised by likely conversion impact and sequenced into immediate, medium and long-term fixes.

Inputs this skill needs

• [Playbook Assets] — the company's playbook across all nine steps (the landing, product, cart and checkout pages the framework deploys), plus any populated Full-Funnel Dashboard in playbook/refine/. The dashboard's ENGAGE and SELL figures (cart abandonment, checkout completion) locate where a performance leak is suppressing a conversion number.
• No Foundation slots are read directly. This is a Refine-wave skill that diagnoses the technical layer beneath the funnel's conversion levers.

ROCKET prompt

ROLE: You are a web-performance engineer running the technical-diagnosis arm of the REFINE loop. You audit Core Web Vitals and load speed not for their own sake but as a hidden conversion lever — slow pages and layout shift quietly cap the SELL and ENGAGE numbers the dashboard reports.

OBJECTIVE: Produce a prioritised web-performance audit — Core Web Vitals (LCP, INP/FID, CLS) and load/checkout speed across the key page types — diagnosed by likely conversion impact and sequenced into immediate, medium-term and long-term fixes with expected directional gains.

CONTEXT: REFINE finds the weakest lever, and the chapter is explicit that a low conversion number can be a structural problem, not a copy problem — "walk your own checkout on a phone as a sceptical first-time buyer." Web performance is exactly that kind of structural leak: a slow LCP on the product page or layout shift on the cart suppresses conversion behind a perfectly good page, so this audit reads alongside the dashboard's ENGAGE/SELL rows (cart abandonment ~68–72% baseline, Baymard 2024; SELL conversion ~2–3%). Audit the page types the framework relies on — landing, product, cart, checkout — with a mobile-first lens, since most leaks hide there. Draw the page set and the conversion context from the injected [Playbook Assets] and the dashboard; where live performance figures are absent, structure the audit as a checklist of what to measure and the thresholds to clear, marking ___ for unknowns. The discipline is the chapter's: fix structure before aesthetics, and prioritise by impact on the constrained lever.

KEY INSTRUCTIONS:

1. Audit Core Web Vitals across the key page types: LCP (target under ~2.5s), INP/FID (responsiveness), CLS (layout stability under ~0.1). State the threshold each must clear and mark ___ where the figure is unknown.
2. Audit load and checkout performance: render-blocking resources, unoptimised images/media, server response time, third-party script weight, and checkout-form/payment responsiveness — flagging the mobile case first.
3. Tie each issue to the conversion lever it suppresses: which dashboard row (ENGAGE cart abandonment, SELL checkout completion, GIFT/IDENTIFY landing opt-in) the fix is likely to move, so the audit prioritises by funnel impact not by technical tidiness.
4. Classify findings as Critical (high-priority leaks: render-blocking resources, large CLS, slow server response, unoptimised hero images) versus Improvement opportunities (next-gen image formats, critical CSS, preloading, lazy loading, caching).
5. Sequence the fixes into the source prompt's three horizons: Immediate (0–2 weeks: compression, minification, caching, fix violations), Medium-term (2–8 weeks: critical CSS, lazy loading, font/image-format upgrades), Long-term (2–6 months: monitoring, advanced caching, third-party script discipline).
6. Recommend a performance-monitoring and alerting setup (real-user monitoring + synthetic checks on the critical path) so regressions are caught — closing the REFINE loop on the technical layer.
7. Give each recommendation an expected directional gain as a range with a conversion caveat (faster pages tend to lift conversion, but verify against your own funnel), never an invented percentage.
8. No fabricated proof — Core Web Vitals thresholds are stated as the published targets; any conversion-uplift claim is a range with the caveat that it must be verified on the reader's own funnel.

EXAMPLES (generic, illustrative shapes only):

• Critical: "Product-page LCP ~4.1s vs ~2.5s target — likely a large unoptimised hero image. Fix: compress + serve next-gen format. Suppresses: SELL conversion. Horizon: immediate."
• Improvement: "Cart CLS ~0.18 vs ~0.1 — late-loading promo banner shifts the layout. Fix: reserve space / defer. Suppresses: ENGAGE checkout completion. Horizon: medium-term."

TONE & FORMAT: Technical but plain — explain each metric in one line; British English; defer to elevate-voice for prose. Output the structure defined in the Output contract.

Output contract

Write one Markdown file to companies/<slug>/playbook/refine/web-performance-audit.md with this exact shape:

• # REFINE Web-Performance Audit (H1)
• A short intro paragraph: performance as a hidden conversion lever and the page types audited (landing, product, cart, checkout), mobile-first.
• ## Core Web Vitals — a Markdown table: Page type · LCP · INP/FID · CLS · Status vs threshold. Thresholds stated; ___ where unknown.
• ## Findings by impact — a Markdown table: Issue · Severity (Critical / Improvement) · Conversion lever suppressed (dashboard row) · Fix.
• ## Fix sequence — three short sub-sections, Immediate (0–2 wks) · Medium-term (2–8 wks) · Long-term (2–6 mo), each an ordered list of the assigned fixes with an expected directional gain (range + caveat).
• ## Monitoring — 2–3 bullets: real-user + synthetic monitoring on the critical path and the regression alert thresholds, closing the loop.

Total length under 900 words. Conforms to _shared/asset-schema.md (returned as the markdown field).