Websites are often sped up in the wrong order: someone installs an optimisation plugin, enables every switch and then looks for why the form no longer works. The right order is measurement, a hypothesis, one change, a function check and new measurement.
In an older version I also described approaches I no longer recommend, such as proxying other people’s scripts locally or general AMP and PWA deployment. They brought partial laboratory improvements but added outdated-code risk, broken updates and more complicated maintenance. A modern website should be fast in its main version.
What to measure today
For Core Web Vitals, Google uses three stable metrics:
- LCP: loading the main content; a good value is up to 2.5 seconds.
- INP: response to interactions; a good value is below 200 milliseconds.
- CLS: unexpected layout shifts; a good value is at most 0.1.
The thresholds apply to the 75th percentile and are summarised in the official Core Web Vitals for Google Search overview. Results from real visitors in Search Console or CrUX take priority over one laboratory test on my laptop.
Laboratory tools still matter: they show the waterfall, main thread, unused code and concrete repair candidates. Field data says that a problem exists; the laboratory helps explain why.
First define the problem’s scope
- Compare mobile and desktop.
- Separate templates: home page, article, service, listing, form and online shop.
- Check fast and slow countries, devices and traffic sources.
- Find URL groups with poor field data.
- Capture a repeatable laboratory trace for a representative page.
One fast home page does not mean a fast website. One slow visit on an old phone does not mean the whole system must be rewritten.
Interventions with the most common impact
1. Server and HTML
Measure time to first byte and split it into DNS, connection, server wait and redirects. Long waits can come from hosting, the database, an uncached page, a slow API or redirect chains. Enable suitable page cache for public content and object cache where it makes sense. Properly exclude logged-in users, carts and personalisation from cache.
2. Main image
LCP is often the hero image. Deliver a size matching its display, use srcset, compression and modern WebP or AVIF with a sensible fallback. Do not lazy-load the main image; lazy-load images below the first viewport. Set image width and height so the browser reserves space and CLS stays low.
3. CSS and fonts
Remove unused styles carefully and keep critical CSS small. Limit fonts to required weights and character sets, cache local files for a long time and preload only a genuinely early font. Preloading ten fonts merely creates another queue.
4. JavaScript and interaction
Split large bundles, defer non-critical code and load third parties only when needed and consent permits. async and defer are not magic; test script order and dependencies. Break up long main-thread tasks and do not make a click wait for analytics.
5. Third parties
Chats, heatmaps, advertising pixels, videos and A/B tools add network requests and processor work. Every script needs an owner and a business reason. Do not load it synchronously in the header just because the installation guide is shortest. Analytics can be managed through Google Tag Manager, but the container itself cannot rescue performance.
WordPress: fewer layers, more control
WordPress documentation recommends addressing performance through hosting, plugin quantity and quality, images, cache and a delivery network. Read its optimisation overview and separate explanation of cache.
- Update WordPress, PHP, the theme and plugins on staging first.
- Remove unused plugins and overlapping cache or minification tools.
- Profile database queries and slow external calls.
- Plan database maintenance, but do not blindly delete revisions or metadata.
- After each optimisation, test forms, search, login and the purchase flow.
I discuss sensible add-on selection in the best WordPress plugins.
What not to do
- Do not download other people’s analytics or advertising scripts to your server just for a score; you may lose security and functional updates.
- Do not set a year-long cache for a changing file without versioning its name.
- Do not remove CSS or JavaScript from an automated report without testing every template.
- Do not judge success only by Lighthouse. Google explicitly says good Core Web Vitals alone do not guarantee high rankings or a great user experience.
- Do not speed up a website by hiding content or a function the customer needs.
A four-week plan
- Week 1: field-data baseline, laboratory measurements and template list.
- Week 2: server, cache, redirects and the largest LCP resources.
- Week 3: images, fonts, CSS, JavaScript and third parties.
- Week 4: regression test, new measurements, monitoring and documentation.
For each change record the date, URL, metric before and after, functional impact and rollback option. Also track conversion rate, form completion and errors; a faster page that sells less is not a finished optimisation.
Start by checking the website’s technical foundations and analytics in a technical audit and GA4. If you need to prioritise repairs by impact and cost, contact me via contact.