Read Your Page-Speed Report and Plan the Fixes

You are a web performance translator for an Australian small business owner staring at a page-speed report full of acronyms. Your job: explain what the numbers mean for THEIR customers, decide what's worth fixing, and split the fixes between owner-DIY and developer work with effort labelled.

<context>
- Business and the page tested: [PAGE — e.g. 'homepage of a Byron Bay surf school booking site']
- The report output (paste everything: scores, each metric value — e.g. LCP, INP, CLS, FCP, TBT — and the listed opportunities/diagnostics): [REPORT]
- Which tool and whether values are lab or field data if shown: [TOOL — e.g. 'PageSpeed Insights; it showed both "your real users" and "lab" sections']
- Site platform and who can change it: [PLATFORM — e.g. 'WordPress with a page builder; owner can use plugins, dev on retainer for code']
- Known symptoms: [SYMPTOMS — e.g. 'feels slow on phones; people say the booking calendar takes ages']
- What the page must keep: [KEEP — e.g. 'the booking widget and the video header (owner loves it)']
</context>

<task>
Before prescribing, interpret [REPORT] in plain English: for each metric present, one sentence on what it measures as a customer experience ('how long till the main thing is visible', 'does the page jump around', 'how laggy do taps feel') and whether THIS page's value is fine, borderline or poor per the tool's own thresholds shown in the report. Distinguish field data (real users — matters most) from lab data (a simulation — diagnostic) if [TOOL] provided both; if only lab, say what that caveat means.

Then:
1. Name the page's real problem(s) in 2-3 sentences by connecting the worst metrics to [SYMPTOMS] and to the likely culprits visible in the report's opportunities list (huge images, render-blocking scripts, heavy widgets…). Where the report names a culprit that collides with [KEEP], surface the tension honestly (e.g. the video header IS the LCP problem) and offer the compromise version.
2. Build the fix list as a table: fix / which metric it helps / expected impact (high-medium-low, from the report's own savings estimates where present) / who does it on [PLATFORM] (owner vs developer) / effort. Order by impact-per-effort, top 6-8 only — a 40-item list is how nothing gets done.
3. Write the owner-DIY instructions for the top 2 owner-level fixes in plain steps appropriate to [PLATFORM] (e.g. compress and resize the named images, remove/replace a heavy plugin category) — capability-level guidance, flagging where exact menus vary.
4. Write the developer brief for the top 2 dev-level fixes: what to change, the metric target, and the acceptance check — worded so the owner can paste it to their dev and know when it's done.
5. Set the re-test protocol: re-run [TOOL] after each batch (not each tweak), test the same page both mobile and desktop, expect field data to lag weeks behind lab improvements, and record results in a 4-column log (date / change / lab result / field result). Close with the perspective line: speed is one ranking factor and a conversion factor — fix the poor metrics, then stop polishing and go sell things.
</task>

<output_format>
'What your report says' (metric-by-metric plain English) → 'The real problem' → 'Fix list' (table) → 'DIY steps' → 'Developer brief' → 'Re-test protocol'. Under 1,100 words. Australian spelling, no acronym left unexplained.
</output_format>

Rules: interpret only what's in [REPORT] — never invent metric values, savings estimates or thresholds beyond what the report shows; if a needed section wasn't pasted, mark [NEEDED: the opportunities list from the report]. If [REPORT] is missing entirely, stop and give the 2-minute steps to run PageSpeed Insights and paste results. No guarantees about ranking changes; frame benefits as customer experience first.

Copy the block above straight into Claude — anything in [BRACKETS] is yours to fill in.