13. <html>
<head>
<script>
__START__ = new Date;
</script>
$.ready(function() {
var time = new Date - __START__;
_gaq.push(
'_trackEvent',
'performance', 'dom_ready', '',
time, true
);
}
20. // Immediate init
$.ready(function() {
function init() {
// Do lots of stuff with #form
}
init();
});
// Delayed init
$.ready(function() {
function init() {
// Do lots of stuff with #form
}
$('#form').one('mouseenter', init);
});
34. THANK YOU
menno.vanslooten@gmail.com
@mennovanslooten
Thanks to Aan Zee (http://www.aanzee.nl) and the jQuery Foundation
Hinweis der Redaktion
\n
The only obstacle between you and a couple of cold beers\nI know it&#x2019;s been a long day of complex material\nDon&#x2019;t worry, timed to about 25 minutes. As mentally challenging as Dora the Explorer\nBefore I get started I&#x2019;d like to get to know you a little better\nBy show of hands, who here has ever received this simple request\n
So many of you have heard this. The rest will down the line. \nSuch a simple question but so hard to answer correctly\nThrough this presentation I&#x2019;d like to give you some tools to deal with it\nIdeas about how to approach the problem\nAnd some tips to help you identify the issues\nFirst, imagine this scenario\n
\nJust asking for better performance is silly. Engineers are not magicians.\nAcceleration, top speed, handling in corners\nYou could call these the pillars of a race car&#x2019;s performance\n
In my experience, these are the three attributes that define a web page&#x2019;s performance\nI will briefly go over each of them\n
Now, I realize you want to get right down to business. \nStart fixing stuff, start improving code.\nDon&#x2019;t.\nThere&#x2019;s a couple of really important things that need to be taken care of\nFirst you need to establish a base line\n
Measurable: you can express it in a number. time or operations\nRepeatable: these numbers don&#x2019;t vary wildly between tests\nif your performance varies a lot, you don't have performance issues, you have a bug.\nStable: It&#x2019;s safe to make changes because of automated testing\nAnd then: gather data on as many different platforms as possible\nThis data is your baseline.\n
Don&#x2019;t climb the tree for a coconut when there&#x2019;s a banana right in front of you.\nUnless you really like coconuts.\nOr climbing.\n
Simply said: how long does it take to look good?\n\n
I know this is a cop-out but there's just too much good stuff in there.\nIt really is required reading.\nI do have some stuff to add\n
Yahoo&#x2019;s YSlow, or Google&#x2019;s PageSpeed are tools that analyze your web page.\nVery useful tools in determining the low hanging fruit I was talking about earlier.\nBe careful though, because they also point out coconuts. \nBefore you know it you&#x2019;re climbing a tree.\n\n
Brace yourself. Code is coming.\n
Google will save all the events and average the data.\nSee how long your average user takes.\nInclude this in your baseline.\n
Simply said: 256-color PNG's with Alpha channel.\nDepending on how crazy your graphic designer is this can save 100s of KB\n
Mostly dependent on what scripts are loaded and run\nFor jQuery projects, much of this will be in a $.ready() handler.\n
For this sequel they really pulled out an all-star cast and it's just as gripping as the first one.\nI hear he's working on "Faster Web sites Strike Back"\n\n\n
\n
\n
Initialize on first click\nCheck out Doug&#x2019;s presentation tomorrow on contextual jquery\n
\n
\n
In my experience the hardest to do right\nThe hardest to get significant results\nI can think of only one low-hanging fruit: repeating events\n
Some events fire once in a while, like click events, or even mouse hover\nOthers fire a lot like a keydown event in an input\nOthers still, fire all the time\nThe last 2 categories benefit a lot from either throttling or debouncing\nThrottling: once every x milliseconds, useful for drag or resizing\nDebouncing: once before/after a series, useful for keyboard\n\n
\n
\n
\n
Responsiveness is quite easy to fake\nAll you have to do is give immediate visual feedback before doing something heavy\nSpinners, progress bars, animations, anything to show that something is happening.\n\n
These 3 pillars are all different aspects of a web page&#x2019;s performance but there is one thing that binds them:\nThey are from the user&#x2019;s perspective\nBut there are other perspectives, like the business perspective. \nThere could be money involved\n
Improving performance is a time-consuming iterative process\nLot&#x2019;s of trial and error and testing and comparing\nThere is a lot to lose and little to gain. \nThe most important gain is user happiness\nBut there are other ways to improve that,\nPerformance optimizations are relatively invisible\n
I&#x2019;ve seen performance improvements that took one man 2 days to write\nand caused bugs that took weeks to fix in total\nunit tests will only catch so much. \nand don&#x2019;t forget about maintainability. the better it performs the least flexible it probably is.\nI realize this may all sound blasphemous. Didn&#x2019;t I just recommend books by famous yahoo & google devs?\nI did, and I stand by that.\n\n\n
They are the cream of the crop devs\nworking on projects where every ms and every kb is multiplied by millions and millions of users\nNo wonder they care so much about it\nMe? I'm more this guy\n
\nDoesn&#x2019;t mean I can&#x2019;t learn from them. Just need to weigh costs and benefits of their recommendations\nThe race car&#x2019;s goal is not to drive fast but to win races.\nOur websites have goals as well. Provide info, user perform task, sometimes not clear.\nWebsite&#x2019;s performance measured in how well it achieves those goals\nIt's about our performance, how well are we doing our job.\nAre we building web sites the world needs. Or are we just making them fast?\n
