Build Log: Making a Slow Site Fast

A local news site took six seconds to load. Readers left before the headline appeared. The editor who called me, a soft-spoken woman named Dana Whitlock who runs the Cedar Valley Courier out of a converted storefront in Fort Collins, Colorado, put it plainly: “People tap our links in their social feeds, stare at a white screen, and go back to scrolling. We are writing stories nobody gets to read.” She did not want a redesign. She did not have the budget for a rewrite. She wanted the site she already had, only fast.

We got it under a second in two weeks. No new framework, no new hosting company, no clever trick that would break the next time someone updated a plugin. This is the build log of how it happened, what I measured, what I changed, and the short checklist I now hand to every client who says their site “feels slow.”

Measure first

The temptation with a slow site is to start fixing things right away. Install a caching plugin, turn on every optimization toggle, and hope. I have learned the hard way that this usually moves the problem around instead of solving it. So the first two days were nothing but measurement.

I tested the homepage, a typical article page and the section fronts on a mid-range phone over a throttled connection, because that is how most of the Courier’s readers actually arrive. Desktop numbers on office fiber tell you almost nothing about a reader standing in a grocery line. I recorded three things for each page: how long until the first text appeared, how long until the largest element finished drawing, and how many total bytes the browser had to download.

The results were almost funny once I saw them laid out. The biggest problem was three huge images on every page. The masthead logo was a 2,400-pixel-wide PNG weighing a little over 1.8 megabytes. A decorative background photo of the Rocky Mountains, sitting behind the header, was another 2.1 megabytes. And a sidebar ad for the paper’s own subscription drive was a full-resolution photo straight off a camera, scaled down with CSS to about the size of a business card. Together those three files were more than five megabytes, and they loaded before a single word of news.

The rest of the weight came from scripts. The site loaded four separate analytics tools, two of which nobody on staff had logged into in years, plus a social sharing widget, a slideshow library used on exactly one old page, and a font file containing every weight of a typeface the theme only used in regular and bold.

Fast is a form of respect for your users.

Leo

I say that line to clients a lot, and I mean it. A reader on a weak signal who waits six seconds is paying for your choices with their time and their data plan. Measurement is how you find out exactly what you are charging them.

Fix the images

Images were the cheapest win, so they came first. I did not delete anything the editor cared about. I simply made every picture the right size for the place it appears.

• The masthead logo became an SVG. It went from 1.8 megabytes to 9 kilobytes and looks sharper on high-density screens than the old PNG ever did.
• The mountain background was resized to the largest width it is ever displayed at, exported as a modern compressed format with a JPEG fallback, and dropped to about 140 kilobytes.
• The subscription ad was cropped and resized to its real display size. It now weighs 38 kilobytes.
• Article photos got responsive sizes, so a phone downloads a phone-sized image instead of the desktop original.

That alone cut the homepage from just over six megabytes to under one. The first text started showing up in roughly two and a half seconds instead of six. Dana sent me a one-word message that afternoon: “Whoa.”

The bigger lesson here is that nobody on the Courier staff had done anything wrong. A volunteer uploaded a logo years ago. A photographer donated a beautiful landscape. Content management systems will happily accept a 6,000-pixel photo and display it in a 300-pixel box. The tools make it easy to be slow without noticing. That is why measuring matters more than blaming.

Then cache

With the images fixed, the remaining delay was mostly the server. Every single visit triggered the full process of building the page from scratch: querying the database for the latest stories, assembling the menus, running every plugin. For a news site where the homepage changes maybe a dozen times a day, that is a lot of repeated work.

Server caching and lazy images did the rest. I set up page caching so that the finished HTML for each page is stored and handed straight to readers, then cleared automatically whenever an editor publishes or updates a story. The homepage went from taking around 900 milliseconds to generate to about 40. I also added lazy loading for images below the fold, so photos further down the page only download when a reader actually scrolls toward them.

One detail I am a little proud of: the cache warms itself. Right after a story is published, a small scheduled task requests the homepage and the relevant section page, so the first real reader never gets the slow, uncached version. It is a few lines of code, and it means the editor’s own refresh to check her work is instant too.

Cleaning up scripts

Last came the scripts. I sat down with Dana and her web volunteer, Marcus Ortega, and went through every third-party tool line by line. We kept one analytics tool, removed the other three, replaced the sharing widget with plain links that need no JavaScript at all, and loaded the slideshow library only on the one page that used it. The font file was trimmed to the two weights the theme actually uses. Total script weight dropped by about 70 percent.

The results

After two weeks, the article pages fully loaded in about 0.8 seconds on the same throttled phone test, and the homepage in about 0.9. The site looks identical to readers. Same masthead, same mountains, same fonts. It just shows up.

The editor shared some numbers from her own analytics a month later. The share of visitors who left without seeing a second page dropped noticeably, and average time on site went up. I am careful not to claim all of that came from speed, since the newsroom also had a busy month of local election coverage. But the trend lined up with the launch date, and the staff stopped getting emails from readers asking whether the site was “down again.”

Key takeaway: most slow sites are not slow because of their framework or their host. They are slow because of a handful of oversized files and forgotten scripts that nobody measured.

The checklist

Here is the short list I now give every client, in the order I work through it. None of it requires a rewrite, and all of it can be checked again every few months.

• Compress images
• Lazy-load below the fold
• Cache pages
• Remove unused scripts

Behind each line is a little more nuance. Compressing images means resizing them to their real display size first, then compressing. Lazy loading should never apply to the top image a reader sees first, or you will make that image slower. Caching needs a clear rule for when the cache empties, or editors will publish a correction and wonder why nobody sees it. And removing scripts means asking the people who added them whether they still need them, rather than ripping things out in silence.

The Courier still runs on the same theme and the same modest hosting plan. Dana now checks the homepage weight once a month with a free browser tool, and Marcus has a rule that no image over 300 kilobytes goes up without a second look. Speed, it turns out, is less a project than a habit. If your site feels slow, start with a stopwatch, not a shopping cart.