Upload
dmethvin
View
722
Download
0
Embed Size (px)
DESCRIPTION
jQueryTO
Citation preview
jQuery and Web Performance
Dave MethvinPresident, jQuery FoundationLead Developer, jQuery Core
March 5, 2014
April 8, 2014: So Long, Windows XP!
What that means...
● IE6 is dead (well maybe not in China)○ ie6countdown.com
● IE7 is supported on Windows Vista○ so realistically, it's dead
● IE8 is the new baseline for dinosaur apps○ it ain't pretty but it generally works
PERFORMANCE
"JavaScript / jQuery / browsers are a bad
developer environment!"
A poor workman blames his tools
How the Programmer Sees It
JavaScript Browser
Web Developer's Reality
Browser JavaScript
Mouse
CSSHTMLContent caching
KeyboardTouch
Screen paints
Layout calculation Image decoding
Focus management
Network requests
Web Developer's Reality
Browser JavaScript
Mouse
CSSHTMLContent caching
KeyboardTouch
Screen paints
Layout calculation Image decoding
Focus management
Network requests
Optional
How Do I Make My Page Fast?
How Do I Make My Page Fast?
1) Find slow stuff2) Make it not slow
What you can measure using tools today
How Do I Find the Slow Stuff?
What you can measure using tools today
What you should measure
How Do I Find the Slow Stuff?
JavaScript Loop Optimization
JavaScript Loop Optimization
Slowest looping style still only takes 140 microseconds to do 10 iterations of a loop
“Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”
--Donald Knuth
“Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”
--Donald Knuth
This Should Be You, 97% of the Time
● Client-side issues often can be solved by "peephole" optimizations and don't require massive architecture changes
● Many — most! — speedups can be done near the end of the project (or even after deployment, cough)
Finding and Fixing the 3 Percent
Page Load Performance
How the Browser Loads Pages
1) Pre-fetcher scans HTML for resources (images, CSS, scripts) and requests them immediately
2) Browser loads CSS and runs JavaScript during parsing
3) After </html>, browser calls DOMContentLoaded
4) Browser does initial rendering of the page
5) Finally the user sees something!
6) Other resources may load after this, e.g. images
Now It May Seem Obvious, But...
● Resources not in the HTML file can't be prefetched, resulting in further delays○ e.g. stuff injected by your JavaScript/jQuery
● Initial content rendered by JS from client-side templates can make the prefetcher useless (e.g., Backbone, Angular, Ember)○ "Browser call YOU"
Manual Prefetching
Lets the browser get a running start on templates or deeper pages in the site.
<link rel="dns-prefetch" href="media.mysite.com">
<link rel="prefetch" href="/img/kitten.jpg">
<link rel="prefetch" href="/page2.html">
YSlow
Google PageSpeed
modern.IE
webpagetest.org
Waterfall Diagram
Here Are Your Blocking Resources
Advertising!
You Have 16 Milliseconds … Begin
60 frames/second ~ 16 milliseconds/frame
● Long-running operations can make the page appear "janky" rather than smooth
● Really long-running operations can make the page appear unresponsive to the user
It Happens in 16 Milliseconds?
From High Performance Browser Networking by Ilya Grigorik (O'Reilly)
Adventures in Dirty Layout
:visible
:hidden
:visible and :hidden are ...
● jQuery custom selectors○ requires Sizzle, not native querySelectorAll
But that's not why they're slow!
"The Dot That Ate Performance"
console.time("init");
$("body").removeClass("activated");
$("p:visible").css("color", "blue");
console.timeEnd("init");
"Hey Browser Can I Bug You?"
30 ms
What If We Track Visibility?
console.time("init");
$("body").removeClass("activated");
$("p.visible").css("color", "blue");
console.timeEnd("init");
"Never Mind Browser, I Know This"
8 ms
Chrome's Yellow Triangle
IE11: Layout after offsetWidth
Class Names for Application State
● Simple rule:○ If it's not layout, don't use classes
● Why?○ The browser may recalculate styles
● What's the alternative?○ jQuery .data()○ JavaScript state
● Look out for :visible or :hidden● Minimize document-wide style/class
changes○ Use data- attrs or jQuery `.data()` if non-stylistic
● Get JavaScript out of the path○ CSS transitions○ CSS animations
Avoiding Forced Layout
Let CSS Be CSS
● Avoid JavaScript for presentation● Use CSS transitions● Use CSS animations● Use stylesheets, not style attributes
○ e.g., .addClass/.removeClass, not .css
Using Dev Tools Profilers
When JavaScript really is the problem (or seems to be), a
profiler can find the hot spots.
A Real Site: gimmickbook.com
● Stutters during infinite scroll● Seems to get worse as the page grows● Using the jQuery Masonry plugin
What's Wrong?
Faster!
Forced Layout/Reflow
Chrome's Event tab shows JavaScript has forced layouts
Chrome Profile ("Tree")
IE 11 Profile ("Call Tree")
What Does This Code Look Like?
Moral of the Story
Infinite scroll should not be used with full-page layout algorithms!
In this case, the plugin could be changed to only lay out the new items, since nothing above them changed.
You Have the Tools, Use Them!
I Don't Know This Guy, But...
$("#talk") .find(".useful") .append(contactInfo) .end();
Twitter: @davemethvinGitHub: @dmethvinIRC (Freenode): DaveMethvin #jquery-devEmail: [email protected]