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: dave@jquery.com