Skip to navigation Skip to content
Yoda looking all disappointed because Luke sucks

That is why you fail

Three-minute read

I’ve been writing about my efforts to make my site load faster. Read Part 1 here.

But like that young Jedi so long ago, I was not always able to levitate the ship out of the swamp. Probably because I didn’t believe enough.

Either, way, here are some methods that I tried and ended up not using.

###What was a wash

  • Lazy loading or concatenating my javascript and didn’t make much of a difference. Likely because my concatenated scripts are only 18K.
  • Paying extra for CDN web hosting. My time to first byte varies widely, from as low as .2 seconds to sometimes more than .7 seconds. My non-CDN hosting on another account is just as fast or faster. Didn’t seem to be worth the extra money.
  • Responsive images with Picturefill 2. It reduces page weight for mobile devices, but didn’t speed load times appreciably. Creating images of multiple sizes of the various photo shapes for dozens of images was a huge pain, even with a Gulp task/ImageMagick doing most of the hard work. Absolutely a must have for any site, but it won’t make you faster.

###What didn’t work

  • Inline data URIs not only didn’t work, they really didn’t work. I tried inline data URIs for my hero images in an effort to cut HTTP calls for above-the-fold page content. In short: Browsers are optimized for common tasks such as grabbing images off a server and rendering them as fast as possible. Data URIs, not so much.
  • Image compression I used the double-size low-res JPEG technique for images. It cut my page weight but I needed to start with billboard-sized images and they still ended up looking overcompressed. Also, if you do this Google Page Speed Insights will falsely accuse of not optimizing and compressing your images.
  • Lazyloading images Picturefill 2 was still new enough when I built my site that this was always going to be a problem. I tried LazySizes which claims to be compatible, but its main effect was to kill my page load times. Your experience may be different, but I’d advise some testing first.
  • Asynchronous loading of concatenated scripts broke Tappy.js. I need to look into this further, but haven’t had time.
  • Minifiying HTML saved about 20K overall. But my CMS uses custom tags for content, and the minifier broke them.

###Takeaways

  • Modularize all the things The trend on every project I’ve tackled has been to make it more modular. SASS obviously makes this simpler with CSS files and partials. I’ve been using Codekit to modularize my pages but you can use Gulp, Grunt or other methods.
  • Experiment Speed gains seemed to be in the details for me and seemed to vary from other people’s. Every site is a little bit different.
  • Gulp and CodeKit FTW Or use Grunt, if that’s your bag. Either way task runners make an enormous difference.
  • Lazy load any blocking files that you can.
  • Yeah, and fonts too. A blank page waiting for a font to load is worse that flash of unstyled text.
  • Give up some image quality to reduce page weight.
  • Latency slows your page more than page weight, so your efforts should concentrate on optimizing for that.
  • Start render times are important that total load times (although these should be low, too) because that’s what the user sees.
  • There’s no magic bullet to speed a page. It’s cumulative and achieved by trimming tenths of a second here and there.