What this is for
Some audits produce a long report and little change. A useful performance audit produces quick wins, clear priorities, and rules that keep the site fast after the work ends Source 9 .
This article describes what you should receive in week one of a focused performance audit.
What you should get at the end of week one
- A baseline of key metrics for agreed page types, including Core Web Vitals indicators and page weight Source 1 Source 2 .
- A prioritised list of issues, sorted by impact on journeys and conversion pages Source 11 .
- A short list of quick wins, with a clear plan to ship them early.
- A set of budgets and rules to prevent performance drift after future edits Source 9 .
- A clear set of recommendations, with trade offs explained in plain language.
Day by day. A typical first week
Day 1. Baseline and priorities
Start with the pages that matter. Entry pages and conversion pages, not a random URL list.
- Agree the page set. Homepage, key services, landing pages, forms, donate, checkout.
- Capture baselines for load feel, core metrics, page weight, and request count Source 1 Source 3 .
- Identify your biggest value journeys and where drop off matters most.
- Write down success criteria, such as improved form completion or reduced bounce rate.
Day 2. Find the biggest loading costs
Most slow sites have a shortlist of repeat offenders. Look for those first.
- Image and media review. Hero images, sliders, background video, embeds Source 5 .
- CSS review. Unused CSS, render blocking assets, critical layout styles Source 5 .
- JavaScript review. Bundle size, heavy libraries, long tasks, hydration cost Source 6 .
- Third-party review. Tags, chat widgets, A/B tools, cookie tooling, embeds Source 8 .
Day 3. Ship quick wins
A good audit does not wait for perfection. It ships simple changes that reduce weight and reduce main thread load.
- Compress and resize images. Serve modern formats where appropriate Source 5 .
- Add dimensions to images and embeds to reduce layout shift Source 7 .
- Remove unused scripts and delay non-essential scripts Source 8 .
- Reduce font weight variants and stabilise font loading behaviour Source 7 .
- Fix obvious render blocking CSS and JavaScript Source 5 .
Day 4. Check infrastructure and delivery
A fast front end still feels slow if delivery is weak. This day focuses on caching and response time.
- Check caching headers for static assets and HTML.
- Check CDN behaviour, cache hits, compression, and image delivery.
- Identify slow server response causes where relevant.
- Remove redirect chains and unnecessary hops Source 10 .
Day 5. Deliver the plan and lock in the gains
Week one should end with clarity. You should know what to do next and why, with rules that keep performance from drifting.
- A prioritised roadmap of fixes, grouped into quick wins, medium work, and structural changes.
- A set of budgets. Page weight, request count, third-party caps, image constraints Source 9 .
- A release checklist so changes do not ship without basic checks.
- A measurement plan that proves improvement and flags regressions Source 2 .
What good recommendations look like
Performance work involves trade offs. The recommendations should state those trade offs clearly.
- Each recommendation states the expected impact and the effort level.
- Each recommendation links to a user journey or a business goal Source 11 .
- Recommendations avoid vague advice, such as optimise images, without a concrete plan.
- Recommendations avoid adding new complexity, unless the value is clear.
What to ask for before you buy
- Which pages will be measured and why.
- Which tools and methods will be used, and what real user data is available Source 2 Source 3 Source 4 .
- Whether fixes are included, or only recommendations.
- How results will be reported. Before and after metrics and a clear summary Source 1 .
- Whether budgets and a release checklist are included Source 9 .
Next step
If you want fast results, start with the pages that make money and the pages that create leads. Ship the quick wins, then keep the site fast with budgets and a simple release checklist Source 9 Source 1 .
Sources
- [1] web.dev. Web Vitals. Back to article
- [2] Google. Chrome UX Report. Back to article
- [3] Google. Lighthouse performance scoring. Back to article
- Missing source entry for: webpagetest-core-web-vitals
- [5] web.dev. Largest Contentful Paint (LCP). Back to article
- [6] web.dev. Interaction to Next Paint (INP). Back to article
- [7] web.dev. Cumulative Layout Shift (CLS). Back to article
- [8] web.dev. Load Third-Party JavaScript. Back to article
- [9] web.dev. Performance budgets 101. Back to article
- [10] Google Search Central. 301 redirects. Back to article
- [11] web.dev. Why does speed matter?. Back to article