Website Speed Optimisation Checklist

Ordered by impact. Everything above a line typically matters more than everything below it.

0. Measure first

• [ ] Check Search Console Core Web Vitals — field data, real visitors
• [ ] Note which metric fails and on which page group
• [ ] Run a lab test on a mid-range mobile profile, throttled
• [ ] Record the numbers so you can prove the change later
• [ ] Identify the LCP element specifically

Skipping this is how people spend a day minifying CSS on a site whose problem is a 3MB hero image.

1. Images

• [ ] Served at rendered size, not upload size
• [ ] AVIF or WebP with fallback
• [ ] Compressed — around 80% quality for photographs
• [ ] width and height set on every image
• [ ] srcset so mobile gets a mobile-sized file
• [ ] Lazy-loading below the fold
• [ ] Hero image NOT lazy-loaded
• [ ] No PNG photographs
• [ ] SVG for logos, icons and diagrams

2. Payload

• [ ] Plugin audit — what loads, and where
• [ ] Scripts and styles loaded per template, not globally
• [ ] Unused CSS not shipped site-wide
• [ ] Fonts limited in family and weight
• [ ] Critical font preloaded, font-display: swap
• [ ] No full icon font loaded for four icons

3. Main thread

• [ ] Third-party scripts audited — chat, analytics, tag manager, consent
• [ ] Non-critical JavaScript deferred
• [ ] Chat widget initialising on interaction rather than on load
• [ ] Long tasks broken up
• [ ] DOM size reasonable

4. Server

• [ ] Page caching active — verify with response headers, do not assume
• [ ] Object caching where the host supports it
• [ ] Browser cache headers set with sensible expiry
• [ ] CDN for static assets if the audience is distributed
• [ ] TTFB under ~600ms
• [ ] Hosting proportionate to the site

5. Layout stability

• [ ] Dimensions on images, video and embeds
• [ ] Space reserved for anything injected after load
• [ ] Cookie banner overlaid, not inserted above content
• [ ] Animations use transform and opacity, not height or top
• [ ] Tested by scrolling the whole page, not just loading it

6. Verify

• [ ] Re-measure in identical conditions
• [ ] One change at a time, so effects are attributable
• [ ] Check field data again after four weeks — it is a 28-day window
• [ ] Test the full journey, not only the homepage

Not worth your time

• Chasing a 100 lab score
• Aggressive minification — small gain, regular breakage
• Removing jQuery
• A second caching plugin
• Any "optimisation" you cannot measure

The goal is a site that is fast for real people on real phones. The score is a proxy, and past a point it stops correlating with the thing you actually care about.

If you would rather this was done properly, it is part of the maintenance service on an ongoing basis and the WordPress development service during a build.