Ready, steady, SLOW!

So you’ve designed the perfect site. The code is simple and elegant. To call it responsive is an understatement—this thing is as flexible as a gymnast. You’ve carefully honed every detail, ready to impress your visitors regardless of which new toy or relic they’ve chosen to surf the interwebs on. There’s one thing you’ve probably left out though. I bet you did. And if you didn’t you’re awesome, go and treat yourself to an Oreo. It’s something we’re all guilty of neglecting—site speed.

Optimise for speed before you’re off your marks.

Site speed, or ‘page load time’ as Google refers to it, is pretty important. There’s even some speculation that faster sites get better search rankings. Site speed shouldn’t be an afterthought or a consideration because you need to reach users on the edge of the earth. You should pay attention to it because a faster internet is just, well, better. It’s efficient, space saving and it’s something we should be striving for.

From the outside looking in, we approach site building like a long list of tick boxes. HTML5 - tick, CSS3 - tick, jQuery 2 - tick? Down we go ticking off all the best practices and tools we know. Somewhere on that list should be the following:

Compress your assets

We’ll get the easy ones out of the way, something everyone can do. How many developers are strict enough to remember to compress all their image assets for every site change? In my experience it’s hard to remember to do this every time and yet it makes a massive difference to a visitors experience on any site. Especially when we’re having so much fun with big background images at the moment.

Who you calling fat?

A lot of the software we use to generate image assets output files much larger than necessary. Photoshop in particular loves larding them up. Throw your image archive in a handy tool like ImageOptim and watch as it chews the fat from your files spitting out visually identical images without the weighty file size. It’s better to compress your images before they even get to the server or find themselves in your version control.

Remove that like button

Because let’s face it. No-one likes you anyway!

Seriously though, share plugins are the number one known cause of obesity in page load times. Your browser makes a lot of additional connections to download all these thumb icons, plus ones and like counters. For each social network you add, you load additional JavaScript and CSS files, bloat, bloat and more bloat. Oh and all these social doo-dads love to track your visitors, so in doing so they can get blocked by common browser extensions such as Ghostery or Adblock.

My advice: just get rid of them. Those embed codes, the easy ones to copy and paste? Yeah, get rid of ‘em. Trust me, they’re doing your site more harm than good. If your content’s awesome, people will share it anyway.

A much neater alternative is to just use a static link and a self hosted image. You sacrifice the like count but let’s face it, 90% of the time it lingers around at 0 anyway. Now there’s no JavaScript load, no slow down because Facebook is having a bad day, and your social buttons will appear instantly!

Another alternative, if you really need to use the embed code for its functionality, is to dynamically load the JavaScript once the user clicks a call to action (see the share button at the bottom of this post as an example).

A great article by Stoyan Stefanov (a Facebook engineer) demonstrates all the various methods of implementing share buttons and their performance. If I’ve convinced you to make static links see this somewhat-dated but thorough list of custom share links for all the major social sites.

Design your site with speed in mind

Responsive design is hard. No really, it is. Because it not only requires more work, but requires you to build smarter sites; to plan better. If you’re doing it right, you’re also ensuring that your visitors aren’t downloading unnecessary assets, right? Tell me you’re not just showing and hiding with CSS. Are you? Oh dear you are aren’t you? That’s all well and good, but unfortunately you’re still downloading all the images.

The BLISS site is pretty rough around the edges but I believe we got some things right. We wanted to ensure the site looked and functioned well on mobile and tablet whilst delivering high quality images to those on desktop. The problem is that falling short of providing 3 separate templates for the site there’s just not a nice way to prevent hefty image assets from being downloaded by devices that don’t even see them. There is no way a mobile device needs to download a 1600x600 image when half the size will do.

Our solution might even be a bit of a hack, but I like it so I’ll share it anyway. We do a bit of a bait and switch. Allow the browser to download dummy files and then use JavaScript to get the real one.

All our responsive images are given the class ‘responsive’. We populate the src attribute with a dummy file—a 1px transparent gif. Then we add the real image path as a data attribute. 

Here’s an example of three image variations that all appear in the HTML. What they share in common is the fake image path.

<img class="responsive banner-large" data-original="" src="/sites/default/files/transparent.gif" width="1600" height="600" />

<img class="responsive banner-medium" data-original="" src="/sites/default/files/transparent.gif" width="1000" height="600" />

<img class="responsive banner-small" data-original="" src="/sites/default/files/transparent.gif" width="600" height="400" />


We still hide and show images using media queries. At any one time, two of these images will have their display property set to ‘none’. Then we use some JavaScript magic to ensure only the desired visible image is actually downloaded.

// Call this once on load and again every time the window is resized.
$('img.responsive:not(.loaded)').each(function(i, el) {
  var $el = $(el);
  if ($el.css('display') !== "none") {
    $el.attr('src', $'original'));


In our mobile CSS we only allow banner-small to appear. The other two are set to display: none and so are never shown and never downloaded, unless you’re a web designer and choose to fiddle with the window size to test how responsive it is. We all do that, don’t we?

NGINX (pronounced engine-x)

There used to be this thing called Apache. It was an attack helicopter. It was also a web server which ran the majority of the world’s websites. Well like all world champions it was eventually knocked out. Nginx climbed into the ring and stole the throne.

Nginx is fast and lightweight. There are a lot of example configurations online which will get you up and running but here are some of its golden features, all aimed at speed.

Spdy support!

Speee-deee? Yup, its the real web 2.0. No joke. Spdy has been pushed by Google to solve some issues with our current net and it’s the foundation for HTTP 2.0. We’ve all been making too many connections to download our web pages and Spdy fixes this by stuffing all the data into one connection. Sort of like a cable tidy.


If you’re running a PHP site or something using fastcgi you can enable Nginx’s microcache. This allows Nginx to act a little like a proxy cache system similar to Varnish, pushing its speed all the way to 88.

In case you’re not familiar with a proxy cache system, think of it as a middleman between the browser and your website. If visitor A requests the same page as visitor B within a short period of time and we’re confident the page content will be the same. Nginx won’t bother querying your server, it will just return what it gave visitor A! This takes some of the workload away from your slow PHP processes and moves them into ultra fast Nginx!


Stay static, absolutely static! Thanks to the distributed nature of the internet, other web services can jump in and lend a hand delivering your site to your visitors. With a high traffic site this support can make all the difference. When you keep the content of your site static, you’re helping these guys deliver more and more of the traffic on your behalf.

I know what you’re thinking. ‘Our site delivers a unique experience for every user. Their journey through the site is carefully crafted just for them’. Riiiiiight. How many homepages have you seen where the only adjustment is instead of saying Sign In it now says Sign Out and maybe your name next to an account link? You know you’re delivering a whole new page just for that user. Lets fix that with some more flexible copy and simple JavaScript so you can deliver everyone the same page.

Lets look at a simple copy change. We can keep the link to My Account permanently on the page, regardless of whether the user is logged in or not. You don’t even need to show a login link now if you don’t want. You see if the user’s already logged in, this link will take them to their account and if they’re not we can send them to the login form first.

Now say you want to remind me of my own name so it reads ‘Conor Clafferty’ on the top right of each page, well how about this? Upon successful login, you can put both the status of my login and my username in a cookie. Using a little JavaScript we can adjust the page slightly and insert my name from the cookie at the top. If we include my login status in the same cookie we can also show that logout button in there too. Simple and effective!

This list is in no way exhaustive, there are many more site speed suggestions to be found online. Put your site through Google’s Page Speed Insights or the Pingdom Website Speed Test to find even more ways to speed up your site.