Part 2 – The Assets
The average website’s total size has doubled in the last 2 years:
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.
were made to compress those, picking variable names like
, 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
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
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