Thursday, April 26, 2012
Of Interest: Head.js @ headjs.com
Head.js is a neat concept.
In my foray into website design, I started out with HTML5 Boilerplate (more on that later). The "acceptable" ways to optimize page load times - not a huge issue for me right now, but I think it's best to develop good habits - include some strange things.
Strange as in "put all scripts right before the tag" and "minify everything" and "concatenate all external everything into single files". These are good things to do on production code, I guess, but they also have their own drawbacks. The main idea is to reduce HTTP requests and keep as much as possible cached for the end-user. If you have, say, [ Cycle ], and don't properly organize the code on your page, you can end up with some strange flashes of unstyled content (or FOUCs, for short). Those are no bueno and are killer for the end-user.
So you might consider loading all your scripts towards the top of your HTML file... but doing so (normally) stops anything else from loading. This extends what the user perceives as load time, and is thus unacceptable.
Enter head.js. The idea is that you can "load scripts in parallel but execute in order". Essentially, you can decrease load times by loading more than one script at a time while the page is loading, too - this decreases the "flashes" or wait times between pages and prevents scripts from "blocking" rendering processes.
It means that my already-slim handcrafted pages are slimmer and faster and better than before.
Or they will be once I finish implementing head.js across the board, anyway.
You can find head.js [ here ]. Neat stuff.
In my foray into website design, I started out with HTML5 Boilerplate (more on that later). The "acceptable" ways to optimize page load times - not a huge issue for me right now, but I think it's best to develop good habits - include some strange things.
Strange as in "put all scripts right before the tag" and "minify everything" and "concatenate all external everything into single files". These are good things to do on production code, I guess, but they also have their own drawbacks. The main idea is to reduce HTTP requests and keep as much as possible cached for the end-user. If you have, say, [ Cycle ], and don't properly organize the code on your page, you can end up with some strange flashes of unstyled content (or FOUCs, for short). Those are no bueno and are killer for the end-user.
So you might consider loading all your scripts towards the top of your HTML file... but doing so (normally) stops anything else from loading. This extends what the user perceives as load time, and is thus unacceptable.
Enter head.js. The idea is that you can "load scripts in parallel but execute in order". Essentially, you can decrease load times by loading more than one script at a time while the page is loading, too - this decreases the "flashes" or wait times between pages and prevents scripts from "blocking" rendering processes.
It means that my already-slim handcrafted pages are slimmer and faster and better than before.
Or they will be once I finish implementing head.js across the board, anyway.
You can find head.js [ here ]. Neat stuff.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment