High Performance JavaScript - WebDirections USA 2010

High Performance JavaScript
Nicholas C. Zakas
Yahoo!, Inc.

The Web Industry Conference
September 21–25, 2010
Midtown Atlanta

Greetings, program

Principal Front End Contributor,
Engineer Creator of YUI Test

Author Lead Author Contributor Lead Author

Is he really going to use a Tron
theme throughout this
presentation?

Does JavaScript performance
matter?

After all, all browsers now have
optimizing JavaScript engines

Tracemonkey/ V8 Squirrelfish Chakra Karakan
JaegarMonkey (all) (4+) (9+) (10.5+)
(3.5+)

So our scripts are getting really,
really fast

Old computers ran slow applications
Small amounts of CPU power and memory

New computers are generally faster but
slow applications still exist
More CPU + more memory = less disciplined application development

It's still possible to write slow
JavaScript on the new, faster
JavaScript engines

JavaScript performance
directly
affects user experience

"Know the enemy and know yourself; in a hundred battles you
will never be in peril."

-Sun Tzu, The Art of War

The UI Thread
The brains of the operation

The browser UI thread is responsible for
both UI updates and JavaScript execution
Only one can happen at a time

Jobs for UI updates and JavaScript execution are
added to a UI queue if the UI thread is busy
Each job must wait in line for its turn to execute

<button id="btn" style="font-size: 30px; padding: 0.5em
1em">Click Me</button>

<script type="text/javascript">
window.onload = function(){
document.getElementById("btn").onclick = function(){
//do something
};
};
</script>

Before Click

UI Thread

time
UI Queue

When Clicked

UI Thread

time
UI Queue

UI Update

onclick

UI Update

When Clicked

UI Thread

UI Update

time
UI Queue

onclick
Draw down state
UI Update

When Clicked

UI Thread

UI Update onclick

time
UI Queue

UI Update

When Clicked

UI Thread

UI Update onclick UI Update

time
UI Queue

Draw up state

No UI updates while JavaScript is
executing

JavaScript May Cause UI Update

var div = document.createElement(“div”);
div.className = “tip”;
div.innerHTML = “You clicked me!”;
document.body.appendChild(div);
};
};
</script>

A UI update must use the latest
info available

Long-running JavaScript
=
Unresponsive UI

Responsive UI

UI Thread

UI Update JavaScript UI Update

time

Unresponsive UI

UI Thread

UI Update JavaScript UI Update

time

The longer JavaScript runs,
the worse the user experience

The browser vendors know this and
put limits on JavaScript via the
runaway script timer

Runaway Script Timer Limits
• Internet Explorer: 5 million statements
• Firefox: 10 seconds
• Safari: 5 seconds
• Chrome: Unknown, hooks into normal crash
control mechanism
• Opera: none

Interpreted JavaScript

UI Thread

Interpret

time

JITed JavaScript (1st Run)

UI Thread

Compile Execute

time

JITed JavaScript (After 1st Run)

UI Thread

Execute

time

How Long Is Too Long?
“0.1 second [100ms] is about the limit for
having the user feel that the system is reacting
instantaneously, meaning that no special
feedback is necessary except to display the
result.”
- Jakob Nielsen

Translation:
No single JavaScript job should
execute for more than 100ms to
ensure a responsive UI

Recommendation:
Limit JavaScript execution to no more
than 50ms

measured on IE6 :)

Techniques
Ways to ensure JavaScript doesn't run away

function processArray(items, process, callback){
for (var i=0,len=items.length; i < len; i++){
process(items[i]);
}
callback();
}

//create a new timer and delay by 500ms
setTimeout(function(){

//code to execute here

}, 500)

setTimeout() schedules a function to be
added to the UI queue after a delay

When Clicked

UI Thread

UI Update

time
UI Queue

onclick

UI Update

When Clicked

UI Thread


time
UI Queue

After 25ms

UI Thread


time
UI Queue

JavaScript

After 25ms

UI Thread

UI Update onclick UI Update JavaScript

time
UI Queue

After Another 25ms

UI Thread

UI Update onclick UI Update JavaScript

time
UI Queue

JavaScript

After Another 25ms

UI Thread

UI Update onclick UI Update JavaScript JavaScript

time
UI Queue

Web Workers
●
Asynchronous JavaScript execution
●
Execution happens outside of UI thread
●
Not on the UI thread = no UI delays
●
Data-driven API
●
Data is serialized when sending data into or
out of Worker
●
No access to DOM, BOM
●
Completely separate execution environment

//in page
var worker = new Worker("process.js");
worker.onmessage = function(event){
useData(event.data);
};
worker.postMessage(values);

//in process.js
self.onmessage = function(event){
var items = event.data;
for (var i=0,len=items.length; i < len; i++){
process(items[i]);
}
self.postMessage(items);
};

When Clicked

UI Thread

UI Update onclick

time

Worker Thread UI Queue

UI Update

When Clicked

UI Thread


time

Worker Thread UI Queue

JavaScript

Worker Thread Complete

UI Thread


time
UI Queue

onmessage

Worker Thread Complete

UI Thread

UI Update onclick UI Update onmessage

time
UI Queue

Web Workers Support

3.5 4.0 4.0 10.6

Repaint and Reflow
Hidden performance costs of common operations

Long UI updates
=
Unresponsive UI

JavaScript can cause
long UI updates by triggering
repaint and reflow

A repaint occurs when a visual change doesn't
require recalculation of layout
Changes to visibility, colors (text/background), background images, etc.

Repaint

this.style.color = "#ff0";
};
};
</script> Repaint!

A reflow occurs when a visual change
requires a change in layout
Initial page load ▪ browser resize ▪ DOM structure change ▪ layout style change
layout information retrieved

Reflow

var div = document.createElement(“div”);
div.className = “tip”;
div.innerHTML = “You clicked me!”;
document.body.appendChild(div);
};
};
</script>
Reflow!

Repaints and reflows are queued
up as JavaScript executes
and then executed in order

Reflow

var list = document.getElementsByClassName("items")[0],
i, item;

for (i=0; i < 10; i++){
item = document.createElement("li");
item.innerHTML = "Item #" + i;
list.appendChild(item);
}

Reflow x 10!

Limiting repaints/reflows
improves overall performance

Technique #1
Perform DOM manipulations
off-document

Off-Document Operations
• Fast because there's no repaint/reflow
• Techniques:
– Remove element from the document, make
changes, insert back into document
– Set element's display to “none”, make
changes, set display back to default
– Build up DOM changes on a
DocumentFragment then apply all at once

DocumentFragment
• A document-like object
• Not visually represented
• Considered to be owned by the document from
which it was created
• When passed to appendChild(), appends all
of its children rather than itself

DocumentFragment

var list = document.getElementsByClassName("items")[0],
fragment = document.createDocumentFragment(),
i, item;

for (i=0; i < 10; i++){
item = document.createElement("li");
item.innerHTML = "Item #" + i;
fragment.appendChild(item);
}

list.appendChild(fragment);

1 Reflow

Technique #2
Group Style Changes

Repaint! Reflow!

element.style.color = "red";
element.style.height = "100px";
Reflow!
element.style.fontSize = "25px";
element.style.backgroundColor = "white";

Repaint!

Grouping Style Changes

.active {
color: red;
height: 100px;
fontSize: 25px;
background-color: white;
}

element.className = "active";

Reflow!

Grouping Style Changes

var item = document.getElementById("myItem");
item.style.cssText = "color:red;height:100px;" +
"font-size:25px;background-color: white");

Reflow!

Technique #3
Avoid Accidental Reflow

Accidental Reflow

element.width = "100px";

var width = element.offsetWidth;

Reflow!

What to do?
• Minimize access to layout information
– offsetTop, offsetLeft, offsetWidth, offsetHeight
– scrollTop, scrollLeft, scrollWidth, scrollHeight
– clientTop, clientLeft, clientWidth, clientHeight
– Most computed styles
• If a value is used more than once, store in
local variable

Does hardware acceleration
help?

Traditional Rendering

UI Thread

Compositing Drawing

time

Hardware Acceleration

UI Thread
Prep Wait

time
Rendering info Signal complete

Compositing Drawing

GPU

Avoid Slow JavaScript
• Don't allow JavaScript to execute for more
than 50ms
• Break up long JavaScript processes using:
– Timers
– Web Workers

Avoid Long UI Updates
• Be careful of repaint and reflow
• Perform complex DOM operations off-
document
– Remove elements and re-add them
– Use DocumentFragment objects
• Group style changes together
• Avoid accidental reflow

Etcetera
• My blog:
www.nczonline.net
• My email:
nzakas@yahoo-inc.com
• Twitter:
@slicknet
• These Slides:
http://slideshare.net/nzakas/presentations/
• Rate Me:
http://spkr8.com/t/4511

Creative Commons Images Used
• http://www.flickr.com/photos/hippie/2406411610/
• http://www.flickr.com/photos/55733754@N00/3325000738/
• http://www.flickr.com/photos/eurleif/255241547/
• http://www.flickr.com/photos/off_the_wall/3444915939/
• http://www.flickr.com/photos/wwarby/3296379139/
• http://www.flickr.com/photos/derekgavey/4358797365/
• http://www.flickr.com/photos/mulad/286641998/
• http://www.flickr.com/photos/torley/2361164281/
• http://www.flickr.com/photos/ottoman42/455242/

High Performance JavaScript - WebDirections USA 2010

More Related Content

What's hot

Viewers also liked

Similar to High Performance JavaScript - WebDirections USA 2010

More from Nicholas Zakas

Recently uploaded

High Performance JavaScript - WebDirections USA 2010