Blog Post

Excerpt – An Introduction to Website Performance: How to Outrun the Zombie Hordes

Reducing What’s Sent to the User

Gzip Resources

Most, if not all, servers can deliver content that is compressed into a smaller file size. Gzip is a compression algorithm that takes the files that are part of your website and smushes (technical term) them. It’s like sending a zombie horde through a gate. The horde can’t fit through the gate unless the zombies come together and remove the space between them. If we compress the horde into a line, it can go through the gate, and our HTML sharp shooters can take them out one at a time.

Gzip works at the byte level, meaning it tries to compress files no matter what type of data they are. You’ll see the biggest shrinkage on text-based files like HTML, CSS, and JavaScript files. It also works on image and media files, but not as well, since they already have their own forms of compression built in.

Gzip is enabled by default, though it’s worth checking with your host or server sysadmin. If Gzip is not enabled, call your host and load that arrow in your zombie-killing performance crossbow ASAP.

Reduce File Size

It may sound obvious, but get rid of anything that isn’t used. As projects and websites age, they accumulate dead weight (better than undead weight amiright?). This Includes CSS that no longer applies to anything, excessive HTML elements, or JavaScript we load on every page even though we never pushed that feature live.

Unused CSS can be hard to find, and it’s even harder to ensure that it’s no longer used, but there are tools out there to help. (One such free tool is, another is, and a search will pop up five or ten more.) Unused CSS just bloats your page and gives you nothing in return. Cut it out, and save some download time.

Excessive HTML is when you use two elements when you only needed one. While adding an element here or there won’t hurt your overall download speed, if you add extra elements throughout the page you’re working on, it can add up both in downloading time and page-processing time. Do your best to use only as much HTML as you need to accomplish your goals. (Note: This will also ease maintenance.)

The same is true for CSS and JavaScript. Only use as much as you need and no more. How much do you need? Whatever it takes to complete your project at its highest quality (and/or when the deadline comes).

Night of the Living Tip:

Many JavaScript linters (i.e., programs that process your JavaScript and indicate errors) will point out variables or functions that are defined but never used. These are great candidates for removal, but be careful that no other process or JavaScript files the linter wasn’t looking at are using the function or variable. For instance, if the function is initiated by user input, the linter may not see it being called.

There are plenty of times when we’ll load some of our own JavaScript (or more likely, that from a third party) and don’t end up using the feature we loaded it for, or the feature gets phased out and we accidentally leave the JavaScript in place (this can happen with CSS too, but it’s less common, and often smaller). This is particularly an issue in any content management system (CMS) that allows for plugins. Often, you’ll install a plugin to try it out, and it won’t work (or at least not the way you expect), so you’ll move on to a different plugin, forgetting to uninstall or deactivate the one you just abandoned. Going through and confirming every plugin and/or JavaScript file are actually used is a quick way to improve your performance.

A corollary to this is finding JavaScript that loads on every page, even though it only applies to a subset of pages. It’s like setting a guard at every building, when having a guard at the outer walls of your post-apocalyptic encampment would be enough (stealth and sneaking into places are not zombie strong suits). You should be able to reconfigure things so that the browser only loads the JavaScript needed for that page.