 |
| BEFORE |
 |
| AFTER |
With any diet there are a set of rules we must follow to reduce the bloat; below I lay these rules out and explain their significance in a page diet. Once we've reduced the bloat, we then need to change our daily habits so that we can put in changes that would allow us to maintain that healthy webstyle.
Page Rules for a heathy Diet
These rules are essentially a subset of the "standard" page performance rules (http://developer.yahoo.com/yslow/) that focus specifically on page size. I've also thrown in some rules that I try to follow and enforce on my team. To re-iterate these rules are designed with page size in mind only with their sole purpose being to reduce the total bytes being delivered for a first time hit (i.e. cold cache).
Gzip Components
Make Javascript/CSS External
Minify Javascript/CSS
Remove Duplicate Scripts
Reduce the number of DOM Elements
Compress images - ensure to use lossless compression
Avoid non-essential comments
Cleanup unused code
Now that I know the rules of my diet - what's next? Time to put them into place and get that page fat trimmed. The first step here is to review your sites pages and look for things that violate the rules.
Gzip Components
Gzip is the current standard here, however, the important thing is to ensure that compression is running on your websites HTML content. To check this you want to look at the response header from your website and check for: "Content-Encoding: gzip". If you are missing this, then make sure to enable it for your site. If you are receiving 3rd party HTML content make sure they are also enabling it.
Make Javascript/CSS External
One might ask how this will help in page bloat? Simple, if it's externalized then we can minify it, when it's internal to an HTML document it becomes harder to minify. Validated that you have removed inline CSS/JS and made it external by viewing the page source.
Minify Javascript/CSS
Minification helps by eliminating unnecessary white spaces, reducing variable sizes and etc.. in an effort to reduce and compress the total bytes of the JS/CSS file. For your website you need to review all JS/CSS files that are being requested and make sure that you have minified these resources prior to deploying them. For 3rd party content providers make sure they have supplied a minified version and that you are using that.
Remove Duplicate Scripts
This rules helps both with page bloat and with page execution speed. The idea is to remove duplicated script so that it won't execute multiple times, recall each execution of script pauses the rendering and therefore slows down the page. The main reason I include this for our website diet is that at the heart of the rule is to remove duplication - this can and should be taken beyond just script. With your favorite browser development tool, review your network tab, and look for duplicate script being called and clean it up. Next while in your favorite development tool open the page source and review the HTML to ensure duplicated data is removed from there as well.
Reduce the number of DOM elements
Does your page really need all those div's? Can it be reduced to a smaller DOM with some CSS to achieve the same end? If so, start reducing that DOM and make the changes and this will yield you a thinner document that transfers quicker and gets to that race winning onload state all the faster so that pretty javascript can properly accessorize it.
Compress Images
We love our images, they are the clothes that make our site look oh so good, however, if we don't pick the right size they can also make us look oh so baggy! Run the page speed or yslow analyzers and look for images that could be compressed; then load them up in your favorite lossless compressor and see if you can shrink that size 6 into a size 4 while still maintaining it's beauty.
Avoid non-essential comments
Is your markup littered with comments? If yes, then why? While it is always a great practice to comment your code for developers so that they can easily understand your work, just remember that in the case of HTML (the minify process strips it from JS/CSS) those comments will make it to your website and result in bloat. There are a few things we can do here: 1 - Remove non-essential comments or reduce the wordiness of the comments. 2 - Create a server side process that strips out the comments from the markup prior to it being gzipped.
Cleanup Unused Code
As your site continues to grow and evolve you'll often find that old code is replaced with new but never removed. Unused old stale code that sits in the source leaves several bad tastes in my mouth, one of which is page bloat. Just think of all those extra calories our site has to consume across the wire because we chose not to clean house on our JS, CSS and HTML files. Take a moment now and go visit your code to remove this at once - you'll be surprised how much you can shed here. I understand that in some cases this code isn't removed because it was built by someone else that no longer maintains, runs or is in any way associated to the site anymore. In these cases you might find it more difficult to find the hidden pounds, but I guarantee you it's there; you'll just need dig deep, trim and focus greatly on testing to make sure nothing broke.
Your new healthy webstyle
Now that we are on a diet, how do we go about ensuring that we maintain it and establish a healthy lifestyle? This is where we need to setup a routine that will allow us to adhere to our rules and be that inner voice that helps us stay on the path when we feel the temptation to eat desert and cheat on our diet. In short, we need to ensure we maintain a constant vigilance via proper monitoring and testing for both our development and live sites.
Monitoring Production
When I go on a diet I like to know how I'm doing so I measure key things, my weight and waist size. For a website diet we'll want to do the same thing by measuring items that affect page bloat - total bytes for the page, % of Gzipped components, % of images compressed, % of JS/CSS files minified. If you haven't enabled performance monitoring already, then you are behind the curve and should enable this immediately as it is the only way to show success and you may have already missed your opportunity to highlight your biggest successes. You can use any performance monitoring tool available (there are a few out there: webpagetest, showslow, keynote, etc...) - so long as it can capture the key items we are measuring here. Once you've started monitoring I'd suggest getting daily reports so that corrections can be made when we see bloat starting to occur. I would even suggest writing a script that can give you a simple pass/fail mark and potentially log a bug for action when you get a fail mark.
Continuous Integration in Development
While monitoring production can allow you to make course corrections if/when you begin to put on the pounds, it would be nice to avoid them all together. To do this, we need to implement our rules as tests that can run with the sites CI and give notifications for failures. We should be able to create simple tests that check our key metrics and force a build failure notification if they fail. My suggestion would be to set a target for each of the key values we are monitoring and if any build yields a value above a certain percentage of that key metric then fail it. Failures should result in bugs for the development team to correct. The following is a great article on adding CI for the front-end to your development process: http://calendar.perfplanet.com/2012/proactive-web-performance-optimization/
With your new diet in place you've started walking the path of a healthy webstyle it shouldn't be long before you see some success. Just remember to keep vigilant with the development team and the content teams to ensure nobody strays from the path we've outlined - good luck!
No comments:
Post a Comment