The Low Hanging Fruit of Web Performance

There is so much to know about making websites fast. It’s rather incredible. Things like understanding servers and networks, how browsers parse things and make decisions, efficient coding choices, and file format nuances make being a performance expert a full-time career in itself.

But you don’t have to be an expert to care about web performance nor be an expert to start making changes to your websites to make them faster. Even total beginners to the web industry have the power to make significant performance increases to the sites they work on.

Perhaps you’ve heard this one?

If you save the length of an array first rather than calculating on each iteration of a for loop, it’s faster:

// this is faster
var l = arr.length;
for (var x = 0; x < l; x++) {
    dosmth = arr[x];

// than this
for (var x = 0; x < arr.length; x++) {
    dosmth = arr[x];

That’s exactly what I’m not talking about. Haha. Sorry.

I want to talk about low hanging fruit. Easy changes that have big impact on web performance.

I have some of my own ideas. As a front-end developer and someone who thinks the web is a pretty darn great thing, I’m into any idea that makes it better. A few years back I did a whole talk on 10 things you can do to make your site faster, all of which are pretty low-hanging fruit.

But more recently, I asked on Twitter, and lots of people had some ideas of their own.

Lemme squish it all together and make a list! Remember this isn’t a comprehensive list of performance-increasing tactics. The requisites to be on this list are that they are fairly easy to do and that have big performance returns.

1) Reduce Requests

This one is my favorite. Anytime I can rip something off of a page and not really sacrifice anything, it feels great. Are there some CSS files you can combine? Tracking scripts you can remove? Sharing buttons that could be just simple links?

Dave Rupert recommends keeping an inventory of all the stuff on your pages so you know why it’s there and what it’s purpose is.

You should also consider the concept of a performance budget. A performance budget might say: you have X requests for Y total file size and Z seconds of load time and nobody can do anything to exceed them. Make it part of the culture around your site!

2) Optimize Assets

Your images can probably be a lot smaller in file size than they already are, without losing any or much quality. Download an app like ImageOptim and drop images onto it before you use them on the web.

The same concept applies to all sorts of other file types. Rather than linking up the “raw” JavaScript that you write by hand, it should be run through a minifier to reduce its file size. This does stuff like remove whitespace and even fancy stuff like rewrite function names and calls to shorter versions. Same with CSS, it should be minified.
There are loads of ways to do this that any build process can handle. For one example, here’s me using CodeKit and making sure the output of my SCSS is compressed:

For SVG files, check out SVGOMG!

Google performance expert Das Surma says compressing/optimizing images is the lowest hanging fruit of all for web performance. For images and video specifically, I’d also recommend checking out services like Cloudinary or Imgix which specialize in optimizing and serving images in super performant ways.

3) Make sure you’re gzipping

As a test, open your Network tab in DevTools and pick a CSS file. Look under the Response Headers and see if the content-encoding is gzip.

If it’s not, there are massive savings you could be having by just making sure gzip encoding is turned on on your server. Your host should have information about this for you. Here on MediaTemple, on an Apache server, here’s some info for that. It’s about making sure mod_deflate is on, which does the gzipping.

You might even investigate Brotli, which can be ever better than Gzip, and I notice is supported here on MediaTemple through the Securi firewall.

4) Make sure you’re browser caching

See that second arrow in the screenshot above? That points to an expires date for that CSS file. Notice it expires in the year 2037. That means the browser will hang onto that file essentially forever and not need to re-download it when needed again. That’s a massive performance booster. Need to change the file? Change its name! style.css?v=16.4

Speaking of caching… the general concept of caching is a massive part of web performance low hanging fruit. Your web host can probably make recommendations here. For example, perhaps they can flip on nginx reverse caching for you. Or if you’re running something like a WordPress site, perhaps you can toss on a plugin like W3 Total Cache and reap the rewards from that.

5) Use a CDN

Like Tim Murtaugh says… set up a CDN.

Content Delivery Networks (CDNs) are for serving your flat files (like images, CSS, and JavaScript) from super fast servers that are specifically tuned for that job (for example, they are “cookieless” which saves some network data overhead). Plus they serve those files from servers that are geographically as close as possible to the user requesting that file. Big gains!

This is low hanging fruit as it’s generally a one-time setup and it’ll benefit you forever. Look into setting up Cloudflare for your site, or something like Stack Path or KeyCDN.

Media Temple offers a nifty a CDN and Web Application Firewall, all-in-one.

6) Lazy Load and Defer Loading of Things

The idea of lazing loading is that you don’t request the asset (like an image or video) until it’s needed. Imagine you visit a blog post that has 6 images on it, but 5 of them are down the page pretty far, and you never bother to scroll down. Why request the other 5?

There are lots of techniques for lazing loading, so allow me to just link you to Jeremy Wagner’s article on Google Fundamentals which covers the concept.

The idea of deferring the loading of JavaScript is simple. There are fancy ways of doing this like code splitting, but perhaps the lowest hanging fruit is deferring the loading of a script by putting it at the bottom of the page, or literally using the defer attribute.

7) Use responsive images (or at least use reasonable sizes)

Zak Nicola says he’s hit “home runs” for local business clients by simply resizing images on their sites to reasonable sizes. They had massive 4k images being put into a 120x60px spot. Yikes. It’s more common that you’d like.

Using reasonably sized images is a quick win. Check out Dave Rupert’s 1.5x images thinking. That might be a good default for everything.

Doing a bit more, look at using responsive images, which is special HTML for your images that has the focused purpose of serving the best possible image for the situation.

<img src="small.jpg" 
  srcset="medium.jpg 1000w, large.jpg 2000w" alt="yah">
    media="(min-width: 1000px)">
    media="(min-width: 800px)">
  <img srcset="examples/images/art-medium.jpg"

Also, consider stuff like using muted autoplaying videos instead of GIFs.

8) Mind Your Fonts

Using custom web fonts can be just as much of a performance burden as the usual suspects: images and JavaScript.

Do you need them at all? If you can get away with not using any custom web fonts at all, or removing some/all of the ones you have, you’ll certainly see performance gains. Perhaps check out using a system font stack.

If you need to use them (I don’t blame you, typography is fun and gives a site a lot of life), then you’ve still got options for improving the performance of them. The lowest hanging fruit is to try out using CSS in your @font-face declarations for those custom fonts, in the form of font-display: optional; /* or swap */. With that, the custom fonts will never hold up the loading of the page, so you might experience FOUT (Flash of Unstyled Text) but never FOIT (Flash of Invisible Text). The “invisible” situation is the one that impacts web performance the most. Pages with no text are pretty useless.

As Brian P. Hogan says, that’s perceived performance as much as it is actual performance.

If you wanna get hot and heavy with the performance of loading fonts, dig into Zach Leatherman’s Guide to Font Loading Strategies.

9) Good Hosting / HTTP2 / PHP7

There is some performance low hanging fruit in your web hosting itself. If your site has slowness issues in the form of response time being slow, perhaps it’s time to upgrade to something more powerful than shared hosting. Throwing money at a speed problem doesn’t always work and isn’t always an option, but sometimes it’s the perfect solution. And it’s definitely low hanging fruit as the effort is minimal.

Speaking of hosting, your web host can probably help you upgrade or configure your hosting to take advantage of the best technologies available.

Ask your host about the possibility of taking advantage of HTTP/2, and if you’re running a classic CMS like WordPress or CraftCMS, getting on the very latest versions of PHP and MySQL which have had massive performance improvements in recent years.

10) Turbolinks

This Turbolinks stuff is a bit of a wild card in this list, but I like it because if it can possibly work for you, you get some increase performance with little work (again, low hanging fruit).

Have you heard of SPAs (Single Page Apps)? The whole idea there is that once the site loads, even as you click around, interact, and go to other pages of the site, the site never reloads. For example, you’re building a React site with React Router. URLs still change and all that, but the laborious process of a full page reload never happens. It’s all Ajax requests and re-rendering. Done right, very cool.

Turbolinks brings that kind of behavior to a site that wasn’t originally built that way. Rather than refresh the page, when you click a link it goes and fetches that page and re-renders what is needs to on the current page.



  • HenriHelvetica

    #1 the quickest request is the one never made. I also feel like #2 + #7 are essentially the same. The idea of responsive imgs is the concept of not sending wasteful bytes, which is really about optimizations ultimately. Imgs are a low hanging fruit simply because their handling is neglected so much, but it does take a pinch of work – possibly more than any of the other ones, but that’s where the CDN comes in. And since CDNs are best employed w/ your heaviest assets, 2, 5, and 7 are essentially related.
    Considering caching and compression are essentially like flicking a light switch, yes. It’s a low hanging fruit – though you might not see colossal benefits – unless this takes you below that threshold that gets you that 1 RTT. Loved this tweet, and recall bookmarking it. Thx Chris!

  • bombfrog

    What happened to Http2 meaning we didn’t have to mess about combining files into one massive css/script file?

  • Martin Flodin

    While his Twitter handle is @DasSurma his name is actually just Surma.

Related Articles