How We Cut Load Time in Half On a Content-Heavy Site

The site was slow. Everyone knew it. The browser would hang for a beat before the hero image showed up. Interior pages took their time loading. On mobile, over spotty cell service, people were giving up before the first paragraph rendered. We’d heard about it in meetings. We’d heard about it in emails. We’d heard about it from a sponsor who ran the site through PageSpeed Insights and sent us the screenshot with a single word in the subject line.

So we fixed it. Here’s what we changed, in order, and what actually moved the needle.

Where we started

Before we touched anything, we measured. If you don’t measure first, you don’t know whether what you changed actually helped. We ran the site through PageSpeed Insights, WebPageTest, and Lighthouse, and we recorded the numbers in a shared doc. Three runs each. Averaged. Mobile and desktop.

The starting numbers weren’t great. First Contentful Paint around 3.4 seconds on mobile. Largest Contentful Paint north of 6 seconds. Total page weight averaging 4.2 MB per page. Lighthouse performance score in the mid-forties.

The good news is that none of this was surprising. We knew where to look.

What we changed, in order of impact

Images were the biggest problem by a wide margin. The site was heavy on photography by design, but the images were being served at full resolution regardless of what size the user’s browser actually needed. A hero photo intended to display at 1600 pixels wide was being delivered to phones at 4800 pixels wide. We rebuilt the image pipeline to serve properly sized versions based on viewport, converted everything to WebP with JPEG fallbacks, and added lazy loading for anything below the fold. This one change alone dropped average page weight from 4.2 MB to 1.4 MB. Everything else we did combined didn’t come close.

Third-party scripts were the second-biggest problem. The site had accumulated a dozen tracking and analytics scripts over the years. Every one of them was being loaded in the head, blocking render. We audited the full list, got sign-off from the client on which ones were actually being used, dropped four of them entirely, and moved the rest to load asynchronously after the page was interactive. Nothing visible changed. The site just got faster.

The database was slow in a few specific places. One widget was running an uncached query on every page load that was pulling in six months of records to generate a sidebar list. We added a transient cache that refreshed every fifteen minutes. The sidebar still shows the same data. The query runs 96 times less often.

Fonts were a smaller win but worth it. We were loading five weights of two typefaces, which is way more than the site actually used. We cut it to two weights of each and added font-display: swap so the browser doesn’t block render waiting for the font files to download. The flash of unstyled text is slightly more noticeable now, which some designers hate, but we’d rather have readable text in 400 milliseconds than blank space for 1200.

Server-side caching. The site is on managed WordPress hosting with decent caching built in, but we weren’t using it to its full potential. We tuned the cache rules, moved more of the dynamic bits to the edge, and set longer expiration times on anything that wasn’t going to change often. This one was mostly configuration, not code.

Where we ended up

Final numbers after the dust settled: First Contentful Paint under 1 second. Largest Contentful Paint around 2.4 seconds. Total page weight averaging 1.1 MB. Lighthouse performance score in the mid-eighties, usually ninety-plus on good runs.

The sponsor sent the before-and-after screenshot to us this time. The subject line was a single thumbs-up emoji.

What we learned

Three things are worth taking away from this.

One: measure first, measure after, measure often. You cannot optimize what you cannot see. Every change we made, we validated. Some changes we thought would help didn’t. Some changes we thought were small turned out to be huge. The numbers tell you the truth.

Two: image optimization is almost always the biggest lever. Nine times out of ten, when a site is slow, images are the reason. The fancy performance tricks around deferring JavaScript and tree-shaking CSS are real, but if your images are 4 MB each, none of that matters.

Three: fast is a feature. This particular site was for people trying to find out about events happening across a region. A lot of those people were on their phones, in rural areas, on slow connections, trying to decide whether to drive to the thing. If the site didn’t load in time, they gave up and went to do something else. Fast is not a nice-to-have. It’s the whole point.

The site is still fast. We check the numbers monthly. We’d rather catch creep early than fix it in a crisis.