A quick rundown of website performance optimizations from Smashing Magazine

I'm a subscriber to the Smashing Magazine newsletter. Every once in a while when I receive one of their newsletters I'm presented with a nugget of information that is nothing short of pure gold. Their latest newsletter (August 26th, 2014) is one such email.

The following comes from their newsletter and are some optimization tips they present get your site to render quickly:

What's the best performance optimization strategy for a (responsive or non-responsive) website? Actually, it's pretty simple. You make sure that your WebPageSpeed's SpeedIndex is under 1000 and ensure that your main content is within the first 14Kb round-trip — and keep your critical rendering path as short as humanly possible. The latter usually means that you have a very clear understanding and agreement of what is critical for the page to start rendering and what is not so essential, and, consequently, could be deferred.

The next step would be to identify the JavaScript that can be deferred and load it asynchronously because otherwise it would block the construction of the DOM tree. You defer web fonts, too. This can be done by either storing them in localStorage (or potentially AppCache) or by using Web Font Loader if you don't have the WOFF files. You can also export critical CSS and embed it inline in HTML to fit within the 14Kb budget (for TCP Slow Start). This way you also avoid unnecessary HTTP requests. Also, you can load full CSS asynchronously once the page has started rendering or has fully loaded, e.g. on DomContentReadyor on Load event.

Well, that's pretty much it. And if your server-side configuration is solid, it's going to be very difficult to be very, very slow. Unless, of course, you don't optimize images. A little trick we've recently discovered is that PageSpeed Chrome extension provides a little handy tool to optimize images aggressively. Once you install the extension and run it for a given website, you'll find a tab called "Optimize Images". It doesn't just show a list of unoptimized files but also allows you to open and save perfectly optimized files without using any external tools. The compression is usually at least as good as in popular compression tools.

So that's basically the strategy we followed on Smashing Magazine, resulting inGoogle PageSpeed Score 97–99 — both on desktop and on mobile (although it varies depending on the advertising we display). Building a fast responsive site isn't that difficult as long as you are strict about what is and what isn't important on the page. For example, we defer loading of ads, tracking scripts, syntax highlighting, web fonts and other non-critical resources, all of which have helped us immensely speed up the entire site.

Nevertheless, some work still lies ahead of us. We are planning to move to new servers soon (server response time is just unacceptable with our current provider), and will defer the loading of Gravatars on article pages as well as move to SPDY shortly. An article explaining all of the mini-optimizations we've done over the last few months will be published on SmashingMag in early September.

Bottom line: if somebody tells you that responsive sites are fat, bloated, unusable and take too much time to develop, tell them that they're wrong. It's animplementation problem, not the technique itself. And with a proper strategy, it can be done right.

— Stay responsive!
Vitaly (@smashingmag)

I couldn't have said it any better. If you haven't subscribed to the Smashing Magazine newsletter please do so here, you won't be disappointed.

Leaving one front end framework for another

  

Earlier this year my colleagues and I worked on a digital plan for the marketing department in order narrow down our focus in getting the projects done in a uniform matter. Part of my contribution to the plan was determining what tools could be used in the creation of our micro sites, landing pages, and full websites. Being that a majority of my time is spent doing front end web design, picking a framework that was robust and made it easy to create responsive websites was a number one priority of mine. While there were a bunch of options to choose from, the two major frameworks that (pretty much) lead the pack were Twitter's Bootstrap and Zurb's Foundation. I wasn't too pleased with the uniformity I saw with sites built with Bootstrap so ultimately chose Foundation for our development.

Things were great for a long while and I was able to take our designers mockups and transform them into functioning sites with little problem thanks to Foundations various plugins and easy grid system. The downside which ultimately hurt development was that the lack of support for older versions of Internet Explorer (primarily IE 8 which a lot of our customers use). Although usage of IE 8 is dwindling (http://theie8countdown.com/) we still needed to support it and this resulted in me using hacks and extra markup to get things to function.......barely. Fast forward to a couple of months ago.

I personally decided to ditch Foundation for Bootstrap, both for personal projects and work related sites. The sheer fact that it supports IE 8 was a huge plus for me and overriding their inherit styles out of the box was much easier than in Foundation. I was also pretty happy that it supports both LESS and SASS for writing style sheets (Foundation only supports SASS) and that the ecosystem for themes is HUGE! Overall, I'm pretty happy with Bootstrap and I've realized that the previous uniformity I saw was only skin deep and didn't take advantage of what was really possible. I'm looking forward to seeing how Bootstrap evolves!