Four things that made my Eleventy website faster without removing the fun

My website wasn’t slow. At least, it didn’t feel slow. But after moving it to Netlify and taking a closer look at the numbers, I realised I was asking browsers to do more work than they needed to, and I was serving far more data than I thought.

None of it was catastrophic, but it all added up. Animated SVGs, oversized RSS feeds, thousands of images, and a few other inefficiencies were quietly increasing bandwidth and making every page heavier than it needed to be.

Over the past few weeks, I’ve been tackling those problems one by one. None of the changes has transformed the site on its own, but together they’ve made it noticeably leaner and hopefully cheaper to host. Here are the four improvements that have made the biggest difference.

1) I stopped serving a 4.5MB RSS feed

The first surprise came from Netlify’s bandwidth reports. One file kept appearing at the top of the list: my RSS feed. Because I’d embedded the full rendered HTML for every article, the feed had quietly grown to nearly 4.5MB. Most of the traffic wasn’t coming from people either. It was crawlers, feed readers, and automated tools downloading the same huge document over and over again.

The fix was embarrassingly simple. Instead of publishing the full contents of every article, I switched to summaries and limited the feed to the latest 25 posts. The feed shrank from megabytes to a few kilobytes, reducing bandwidth by well over 99% without making the feed any less useful.

Read Tracking down a nasty Netlify bandwidth burner

2) I switched thousands of images from WebP to AVIF

Like most people, I’d gradually adopted WebP because it offered much smaller files than JPEG and PNG. Then I started experimenting with AVIF. Across most of my photography and illustrations, the savings were remarkable. Some images became more than 90% smaller while looking virtually identical. Across the whole site, the reduction averaged around 65%.

It wasn’t all good news, though. Some images actually became larger. Those turned out to be graphics with transparency, sharp edges, and text where WebP was already doing an excellent job.

That was a useful reminder that there isn’t a single “best” image format. Different images compress differently, so it’s worth measuring instead of assuming.

Read Switching my website images from WebP to AVIF

I stopped loading animated SVGs up front

I love using animated illustrations throughout my site. They add atmosphere and personality that static graphics can’t. Unfortunately, they also make pages much heavier, as an animated SVG isn’t just an image. It includes inline SVG markup, CSS, and JavaScript, all of which become part of the initial HTML document.

Instead of shipping all of that immediately, I now begin with a lightweight static AVIF image. Once the page has rendered, larger screens quietly fetch an HTML fragment containing the animated SVG and swap it into place. Small screens never download the animation because they’ll never display it anyway.

The pages feel faster, the browser has less work to do during the initial render, and I haven’t had to sacrifice any of the character those illustrations bring.

Read Swapping a lightweight image for an animated SVG

4) I started questioning everything I send to the browser

The biggest improvement wasn’t a particular optimisation. It was changing the way I think. Instead of asking, “How can I make this smaller?” I’ve started asking, “Does the browser really need this right now?” Sometimes the answer is yes. Quite often, it isn’t. None of those changes is especially glamorous, but together they’ve made a noticeable difference.

Performance isn’t ever really finished

One thing I’ve learned is that performance isn’t something you optimise once. Every new animation, article, feature, or illustration has the potential to make a site a little heavier than it needs to be. That’s especially true when, like me, you enjoy building websites with plenty of personality. I’m not trying to chase perfect Lighthouse scores. I’m trying to make sure every byte is worth the price.

I’m sure I’ll keep finding more ways to improve performance. But these four changes have already made a noticeable difference, and they’ve done it without taking any of the fun out of my website.