Skip to content
Home About Services Portfolio Blog Contact Get Started
Web Development

Website Speed Optimization: The Checklist We Actually Use

Written by

MTD Technologies

Published
Read Time 6 min
Flat vector illustration of a browser window with a speedometer gauge racing toward the fast...

When a client tells us their site feels slow, we do not start by guessing. We run this website speed optimization checklist on every project — brochure sites, WooCommerce stores, headless builds. It begins with measurement, works through the fixes in order of impact, and ends with a site that passes Core Web Vitals on real user data rather than just in a lab test. Here it is, exactly as we use it.

Measure first — never optimise blind

Before a single change, we get a baseline from three places. PageSpeed Insights gives you lab data (Lighthouse) plus field data from the Chrome User Experience Report — the field data is what Google actually ranks on, so it carries the most weight. Search Console’s Core Web Vitals report shows which URL groups pass or fail across your whole site. And a WebPageTest or GTmetrix waterfall shows exactly which files cost the most time, in order. Skip the waterfall and you are fixing by hunch. As a recent 2026 guide to Core Web Vitals on DEV puts it, lab scores are for debugging — the field is what Google’s ranking systems actually see.

The three metrics that matter in 2026

There are only three Core Web Vitals now, and they cover loading, responsiveness and visual stability. LCP (Largest Contentful Paint) measures how fast the main content — usually the hero image or headline — appears; good is under 2.5 seconds. INP (Interaction to Next Paint) measures how quickly the page responds to clicks, taps and keypresses across the entire visit; good is under 200 milliseconds. CLS (Cumulative Layout Shift) measures how much the page jumps around while loading; good is under 0.1. All three are judged at the 75th percentile of real visits.

One detail that instantly dates a guide: INP replaced First Input Delay (FID) as the responsiveness metric in March 2024. INP watches every interaction on the page, not just the first click, which makes it stricter and harder to game. And keep expectations honest — SubscribePR’s analysis of what Google actually says notes that vitals act as a tie-breaker between pages of similar relevance. Passing them moves you from “penalised relative to a passing competitor” to neutral. Great content still outranks a fast thin page.

Developer following a speed optimization checklist, compressing images and tuning a server

Your website speed optimization checklist, in impact order

Here is the order we work through. It is sorted by typical impact, but your waterfall always gets the final vote — if one file eats 40% of load time, fix that first regardless of where it sits in this list.

  1. Fix the images. The single most common failure we find: a 4MB hero image loading as a CSS background. Resize images to their display size, serve WebP or AVIF, set explicit width and height so the browser reserves space, lazy-load everything below the fold, and give the LCP hero fetchpriority=”high”. This one step often moves the needle more than everything else combined.
  2. Cut and defer JavaScript. INP dies in JavaScript. Break up any task that blocks the main thread for more than 50ms, defer everything that does not need to run before first paint, and audit third-party scripts ruthlessly — chat widgets, heatmaps and tag managers are the usual suspects. If you would not notice its absence for a week, remove it.
  3. Sort the fonts. Custom web fonts block text rendering when loaded badly. Use font-display:swap, preload only the weights you actually use, and consider a system font stack for body text — nobody ever complained that a site loaded too fast in system fonts.
  4. Fix the server response. No amount of front-end tuning helps if the server takes over a second to answer. Check Time to First Byte first: enable server-side page caching, add object caching for database-heavy sites, and put static assets behind a CDN. Cheap shared hosting is a common silent killer of business sites.
  5. Unblock rendering CSS. One 300KB stylesheet that loads synchronously blocks everything. Remove unused CSS, inline the critical above-the-fold styles, and load the rest asynchronously. WordPress themes and page builders are the worst offenders here.
  6. Stop layout shift. Reserve space for images, embeds and ad slots so content never jumps. Cookie banners that shove the page down, lazy images with no dimensions, and fonts that swap late are the usual CLS culprits. A CLS of zero is genuinely achievable on most business sites.
  7. WordPress-specific cleanup. Audit active plugins — every plugin adds code to the page, and fifteen active plugins is a red flag. Move wp-cron to a real server cron, clean up autoloaded options in the database, and be suspicious of any plugin installed for a feature you could have coded in ten lines. Purpose-built code from our custom WordPress plugin development work is always leaner than a Swiss-army plugin doing five jobs badly.
Comparison of a slow heavy website with a snail versus a fast rocket-powered website

Fix by waterfall, not by habit

Honest confession: the checklist order is the typical case, but the waterfall overrules it every time. We once spent an afternoon trimming JavaScript on a client site only to discover the real problem was a single 8MB video background on the homepage. Micro-optimisations — preconnect hints, resource ordering tweaks — are the last five percent. The big wins are almost always oversized media, plugin and theme stacking, and slow hosting. Fix those first and the metrics usually follow.

Frequently asked questions

How fast should my business website load?

Aim for LCP under 2.5 seconds, INP under 200ms and CLS under 0.1 for at least 75% of real visits. You do not need a perfect 100 in every test — passing all three vitals in field data is the practical goal for a business site.

Does website speed affect Google rankings?

Yes, but modestly. Core Web Vitals act as a tie-breaker between pages with similar content and backlinks — passing them moves you from “penalised relative to a passing competitor” to neutral. Great content still outranks a fast thin page.

What is the biggest cause of a slow website?

In our audits, it is usually oversized images and heavy JavaScript — a multi-megabyte hero image, third-party scripts loading on every page, or a plugin stack that has grown without review. Hosting quality comes a close second.

Can I speed up WordPress without rebuilding it?

In most cases, yes. A plugin audit, image conversion to WebP, caching and font optimisation fix the majority of WordPress sites. A rebuild only makes sense when the theme or plugin stack is fundamentally broken — something we would confirm with an audit before suggesting.

A fast site is a compound investment: better rankings, lower bounce rates and more enquiries from the same traffic. If your site has grown slow and you want this checklist applied properly, contact us — the kind of performance audit we run as part of our web development services, and the biggest wins usually show up in the first hour.