The Website Speed Checklist I Run Before Calling a Site "Done"

"Optimize your images and enable caching" is the speed advice you'll find everywhere, and it's not wrong, it's just not where the real problems usually live anymore. Here's what I actually check, in order, before I call a build launch-ready.

Third-party scripts first, always

The single biggest speed killer I find on client sites isn't unoptimized images. It's the accumulation of third-party scripts: a chat widget here, an old analytics snippet there, a marketing pixel nobody remembers adding, a font loaded from three different services because three different people worked on the site over the years.

Each one adds a network request, blocks rendering, or both. I open the network tab and count every third-party domain being called. If I don't know why a script is there, it comes out until someone can tell me why it needs to stay.

Fonts are a bigger deal than people think

Custom web fonts loaded badly cause layout shift and delay text rendering. The fixes are boring but effective: self-host fonts when you can, use font-display: swap so text shows in a fallback font while the real one loads, and don't load six weights of a typeface when the site uses two.

Images: format and size, not just compression

Compression alone isn't the fix people think it is. The bigger win is serving the right format (WebP or AVIF instead of a huge PNG) and the right size for the actual display area, not a 4000px-wide hero image scaled down by CSS. Lazy-load anything below the fold. This alone often does more for Largest Contentful Paint than any plugin.

Server response time, before you blame the front end

A beautifully optimized front end sitting on a slow server or bloated database queries still feels slow. If Time to First Byte is high, no amount of front-end tuning fixes it. Check your hosting, check for N+1 database queries on dynamic pages, and check whether a caching layer (page cache, object cache, or a CDN) is actually configured, not just installed.

Render-blocking CSS and JavaScript

CSS and JS that block the initial render push back everything the user sees. Critical CSS inlined for above-the-fold content, everything else deferred or loaded async, is still one of the most effective and most skipped optimizations on real sites.

Test on a real connection, not your office WiFi

Your site feels fast on your desktop, on fiber, because you're not the person it's slow for. Test using Chrome DevTools' network throttling set to a mid-range mobile connection, or better, on an actual mid-range Android phone. That's closer to what a meaningful chunk of your visitors are actually using.

Measure the metrics that matter, not just a score

A single "90/100" PageSpeed score can hide a bad Largest Contentful Paint or a high Cumulative Layout Shift. Look at the actual Core Web Vitals: LCP, INP, and CLS. Those are the numbers tied to both user experience and, to a meaningful degree, search ranking.

The part everyone skips: re-check after every future change

Speed isn't a one-time fix. A marketing team adds a new tracking tag, a developer adds a new plugin, a new hero video gets uploaded at full resolution, and six months later the site that launched fast is slow again. Whoever owns the site needs a habit of re-testing after changes that touch scripts, images, or fonts, not just at launch.

Speed work is unglamorous. Nobody screenshots a fast Time to First Byte for their portfolio. But it's one of the few technical investments with a direct, measurable line to conversion rate, bounce rate, and search visibility. Do the boring checklist. It compounds.