Pages So Fast Your Customers Will Freak Part 2: The Assets

Part 2 – The Assets

The average website’s total size has doubled in the last 2 years: "Up and to the right graph of pagesize All this ‘stuff’ takes time to download, and users have been shown to dislike slow load times for webpages. Additionally, Google has started using page load times in their calculation of PageRank, meaning a slow site has more objective drawbacks now than ever before. Luckily Google has provided the internet with their excellent PageSpeed Insights tool. It shows you all of the current networking and application best practices that can be used to shrink your site’s download time. Over a series of posts, we’ll cover each category of recommendations made by the Big G, continuing here with how your text and binary files are prepared and delivered to the browser.

Minify resources

Javascript often contains comments, whitespace, and long variable names to help developers. Tools like Uglify.js were made to compress those, picking variable names like a, and putting all of your code onto one line. The functionality stays the same, it is just smaller to download. There are also smart minifiers for CSS and HTML that have domain-specific logic like combining redundant CSS selectors that make them more effective than basic text compression. A recent project used various Grunt Contrib plugins to reduce my javascript payload from 46 files/212kb into 1 90kb file. This was then gzipped into a 14k deliverable. That’s a reduction of 93%, saving our (mostly mobile) users a lot of download time.

Optimize images

Images usually account for the largest portion of a page’s total payload. ESPN‘s total payload is 1.2mb, and currently 545kb or about half of that is from images. Images of any format are usually optimized by whatever program produced them. In a lot of cases those programs aren’t optimizing for file size, but perhaps future ability to edit the file. This means that you can usually shrink the file size of images even more. Using sites like Yahoo!’s Smushit or Grunt’s Imagemin, you can expect to get compression ratios from 10-50% depending on the source image. These are usually lossless, and don’t incur any decompression penalty in the browser.

Optimize CSS Delivery

If a browser is waiting for CSS to download, it will not paint anything on to the page. This means that prioritizing delivery of your CSS is crucial to getting content in front of your user’s eyes. A new-to-me strategy that Google recommends for larger sites is to actually factor out your ‘critical’ CSS into its own file, and load that first. This will make sure that the page painting occurs as fast as possible. Then later on you can ‘backfill’ other styles that are either only used further down a page or triggered by a user’s behavior (hover states, animations, etc). At the very least, getting your CSS downloading as fast as possible (meaning near the top of your <head> element) will ensure that the browser won’t be waiting too long to paint your page’s content. Read more about these techniques here


Using some kind of build pipeline like the Rails Asset Pipeline or Grunt.js, you can take charge of your app’s assets and keep your users happy. Try out PageSpeed Insights on your own site, and see how you rank.

This is part 2 of 3 of the “Pages So Fast Your Customers Will Freak” series

Part 1: The Server Part 2: The Assets Part 3: The Rendering