Lab Notes

Performance Wins: What I Do Before Every Launch

3 min read Performance · Quick Wins

Every website I build goes through the same pre-launch routine. It's not glamorous work—no one sees it happen—but it's the difference between a site that feels fast and one that feels sluggish.

Here's what I do before any site goes live, and why each step matters.

The Pre-Launch Checklist

Image Optimization

Images are usually the biggest files on any website. A single unoptimized photo can be 3-5MB. That's enough to make your page load feel like molasses.

Resize images to the actual dimensions they'll display (not 4000px wide for a 400px thumbnail)

Compress everything using modern formats like WebP where supported

Set up lazy loading so images below the fold don't load until needed

Use responsive images (srcset) to serve smaller files on mobile devices

The result? A 2MB image becomes 80KB without visible quality loss.

Code Minification

The code I write is readable—comments, proper indentation, descriptive names. That's great for maintenance but wasteful for delivery.

Before launch, I minify all CSS and JavaScript files. This removes whitespace, comments, and shortens variable names. A 50KB stylesheet might become 30KB. Multiply that across multiple files and you're saving real bandwidth.

Critical CSS Inlining

Here's a trick most designers skip: I identify the CSS needed for "above the fold" content and inline it directly in the HTML.

This means the browser can start rendering immediately without waiting for external stylesheets. The rest of the CSS loads asynchronously. The result is a faster First Contentful Paint—the moment users first see something on screen.

Font Loading Strategy

Custom fonts are great for branding but terrible for performance if handled wrong. A poorly loaded font can cause text to be invisible for seconds or flash awkwardly when it finally loads.

Use font-display: swap so text is visible immediately (in a fallback font)

Preload critical fonts in the document head

Subset fonts to include only the characters actually needed

Self-host fonts instead of relying on external services when possible

Browser Caching Setup

Returning visitors shouldn't have to re-download files that haven't changed. I configure proper cache headers so browsers store static assets locally.

CSS, JavaScript, and images get long cache times (often a year). When I do update something, the filename changes (cache busting), so browsers know to fetch the new version.

Reducing HTTP Requests

Every file your browser requests takes time—especially on mobile connections. I look for opportunities to reduce these requests: combining multiple CSS files into one, using SVG sprites or inline SVGs instead of multiple image files, inlining small CSS directly rather than as separate files, and removing unnecessary third-party scripts.

Fewer requests = faster loading, even if the total file size is similar.

Third-Party Script Audit

Analytics. Chat widgets. Social media embeds. Marketing pixels. Each one you add slows your site down and introduces code you don't control.

Before launch, I audit every third-party script: Is this actually being used? Can it load asynchronously or be deferred? Is there a lighter alternative? Does the benefit justify the performance cost?

Often, there are scripts added months ago that nobody remembers or uses. They go.

Mobile Performance Testing

Desktop performance doesn't tell the whole story. I test every site on real mobile devices and simulated slow connections.

What loads fine on fiber internet might crawl on 4G in a rural area. Since many of my clients serve East Tennessee communities, this matters a lot.

Core Web Vitals Check

Google's Core Web Vitals are specific metrics that affect both user experience and search rankings:

  • LCP (Largest Contentful Paint): How fast does the main content appear? Target: under 2.5 seconds
  • INP (Interaction to Next Paint): How quickly the page responds when someone taps or clicks. Target: 200 milliseconds or less. (This replaced the older FID metric in 2024.)
  • CLS (Cumulative Layout Shift): Does the page jump around while loading? Target: under 0.1

I test these metrics and optimize until they're all in the green.

The Payoff

All this work happens behind the scenes. You don't see it, but you feel it. The site just... works. It loads fast. It feels responsive. It doesn't frustrate you.

And Google notices too. Fast sites rank better. They have lower bounce rates. They convert more visitors into customers.