jquery conference san diego 2014 - web performance
DESCRIPTION
TRANSCRIPT
jQuery and Web Performance
Dave Methvin
President, jQuery Foundation
Lead Developer, jQuery Core
● Maintains jQuery code and docs
● Supports web developers and standards
● Participates in standards process
○ W3C web standards
○ ECMA 262 (JavaScript)
● Hosts conferences (like this one!)
jQuery Foundation
jQuery Core 1.11 and 2.1
• Shipped last month
• We didn't break a lot of things!
• "jQuery Served Your Way" ™
o Support for IE 6/7/8 (1.11) or not (2.1)
o Custom builds for smaller size
o Use with node, browserify, or inside apps
builtwith.com
jQuery Team - World Wide
http://contribute.jquery.org
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
CSS
HTMLContent caching
Keyboard
Touch
Screen paints
Layout calculationImage decoding
Focus management
Network requests
Web Developer's Reality
Browser JavaScript
Mouse
CSS
HTMLContent caching
Keyboard
Touch
Screen paints
Layout calculationImage decoding
Focus management
Network requests
Optional
How Do I Make My Page Fast?
1)Find slow stuff
2)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) Browser fetches index.html
2) Pre-fetcher scans HTML for resources (images, CSS,
scripts) and requests them immediately
3) Browser loads / runs JavaScript when encountered
during parsing (since scripts can write out new HTML!)
4) When HTML is fully loaded and parsed, browser calls
DOMContentLoaded handlers (jQuery .ready())
5) Browser does initial rendering of the page (finally the
user sees something!)
Now It May Seem Obvious, But...
• Resources not already in the HTML file can't
be prefetched, resulting in further delayso e.g. stuff injected by your JavaScript/jQuery
• JS frameworks or initial content rendered
from some client-side templates can make
the prefetcher useless
Manual Prefetching
Lets you tell the browser get a running start on
template content or deeper pages in the site.
<link rel="dns-prefetch" href="media.mysite.com">
<link rel="prefetch" href="/img/kitten.jpg">
YSlow
Google PageSpeed
modern.IE
webpagetest.org
Here Are Your Blocking Resources
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
"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/Height
●
●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
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?
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!
Twitter: @davemethvin
GitHub: @dmethvin
IRC (Freenode): DaveMethvin #jquery-dev
Email: [email protected]
$("#talk")
.find(".useful")
.append(contactInfo)
.end();