The problem this solves
Speed work suffers from a targeting problem before it suffers from anything else. Teams either optimize the homepage because it is the homepage, or chase a site-wide score because a tool assigned one, and both approaches ignore the arithmetic: a rendering issue on a page with heavy traffic costs more user experience per week than the same issue on fifty quiet pages combined. The pages doing the actual work of the site are rarely the pages getting the performance attention.
Then there is the findings-to-fixes gap in its purest form. Performance audits produce waterfalls, scores, and screenshots that engineers must translate into tickets before anything improves, and the translation is where momentum dies. A finding without a reproduction path, an affected-page list, and a reason to prioritize it is homework wearing a deadline's clothes. Weeks later the audit document is stale and the fixes it implied were never born as work items at all.
The pass that changes something is narrow and finished: the five pages where traffic actually concentrates, audited for speed and rendering, every fix ranked by traffic-weighted impact so the ordering argues for itself, and each fix filed directly as a task with reproduction notes attached. The backlog receives work items rather than a document, which is the difference between findings and fixes.
How the mission runs
- Identify where traffic concentrates. GA4 identifies the five pages carrying the most traffic over the analysis window, which become the audit's entire scope. The deliberate narrowness is the strategy: depth on the pages doing the site's real work beats breadth across pages few visitors ever see.
- Audit each page for speed and rendering. Site Audit works each of the five pages: load performance, render-blocking resources, layout shift, oversized assets, and template-level issues that will recur wherever the template is used. Findings are recorded with the specific page, the observed behavior, and the evidence behind each.
- Rank fixes by traffic-weighted impact. Each fix is scored by the improvement it offers multiplied by the traffic exposed to it, so a modest fix on the busiest page can outrank a dramatic fix on the fifth. The ranking makes prioritization arguments unnecessary, because the ordering carries its own arithmetic.
- File each fix as an Asana task. Every fix becomes an Asana task carrying what an engineer needs to start: the affected page, the observed behavior, reproduction notes, the expected improvement, and its rank. The audit enters the backlog as work rather than as a document waiting for translation.
- Summarize the pass. A closing summary states what was audited, what was found, how the ranking fell out, and which template-level findings will pay off beyond the five audited pages. It is the context a lead needs to slot the tasks into a sprint without reading every ticket first.
The prompt
This is the exact objective the agent receives. Swap the obvious placeholders for your own domain, segment or channel and run it as-is from the console, Slack, or the API.
What comes back
A set of Asana tasks, one per fix, each carrying the affected page, observed behavior, reproduction notes, and expected improvement, ranked by traffic-weighted impact so the work order is self-evident. Plus a summary connecting the tasks to the audit behind them, with template-level findings flagged for their leverage beyond the five pages. The speed work arrives in the backlog born as work items, with every finding traceable to the audit call that produced it.
Make it yours
- Re-run it after the top-ranked fixes ship, holding the page set constant, so the follow-up audit doubles as verification that the tasks actually moved the numbers.
- Swap the selection criterion to the five highest-converting pages when revenue concentration matters more to your team than raw traffic volume does.
- Extend to the top template per section instead of the top five pages when your traffic spreads across many similar pages sharing a few layouts.
Frequently asked questions
Why only five pages?
Because traffic concentration makes the arithmetic decisive: the busiest pages expose the most visitors to every flaw they carry. A narrow, finished pass that ships ranked tasks beats a broad audit that ships a document, and template-level findings from the five typically improve many more pages anyway.
What makes the tasks actually workable?
Each one is filed with what an engineer needs on day one: the page, the observed behavior, reproduction notes, and the expected gain. The traffic-weighted rank answers the prioritization question before it is asked, and every claim in a task traces back to the audit evidence behind it.
How often should the pass run?
Quarterly suits most sites, since performance regresses through ordinary shipping rather than dramatic events. Teams in heavy release cycles run it monthly on the same page set, using the run-over-run comparison as a regression alarm that arrives pre-triaged into tasks.