High Performance JavaScript 2011

High Performance JavaScript
Nicholas C. Zakas| nczonline.net

Who's this guy?
Co-Creator csslint.net
Contributor,
Creator of YUI Test
Ex-tech lead
Yahoo!
Author
Lead Author
Contributor
Lead Author

@slicknet
(complaints: @brendaneich)

Does JavaScript performance matter?

All browsers now haveoptimizing JavaScript engines
Tracemonkey/
JaegarMonkey
(3.5+)
V8
(all)
Nitro
(4+)
Chakra
(9+)
Karakan
(10.5+)

http://ie.microsoft.com/testdrive/benchmarks/sunspider/default.html

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

Oh yeah, one more thing

It's still possible to write slow JavaScript

JavaScript performancedirectlyaffects user experience

The UI Threadaka Browser Event Loop

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
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
onclick
UI Update
time
UI Queue
UI Update

When Clicked
UI Thread
onclick
UI Update
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
JavaScript
UI Update
UI Update
time

Unresponsive UI
UI Thread
JavaScript
UI Update
UI Update
time

The longer JavaScript runs,the worse the user experience

The runaway script timer prevents JavaScript
from running for too long
Each browser imposes its own limit (except Opera)

Internet Explorer

Firefox

Safari

Chrome

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

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 50msmeasured on IE6 :)

Does JIT compiling help?

Interpreted JavaScript
UI Thread
Interpret
time

JITed JavaScript (1st Run)
UI Thread
Compile
Execute
time

JITed JavaScript (After 1st Run)
UI Thread
Execute
time

Loadtime TechniquesDon't let JavaScript interfere with page load performance

During page load, JavaScript takes more time on the UI thread

<!doctype html>
<html>
<head>
<title>Example</title>
</head>
<body>
<p>Hello world!</p>
<script src="foo.js"></script>
<p>See ya!</p>
</body>
</html>

Result
UI Thread
JavaScript
UI Update
UI Update
time

Result
UI Thread
foo.js
See ya!
Hello world!
time

Result
UI Thread
Download
See ya!
Hello world!
Parse
Run
time
The UI thread needs to wait for the script to
download, parse, and run before continuing

Result
UI Thread
Download
See ya!
Hello world!
Parse
Run
Variable
Constant
Download time takes the longest and is variable

Translation:The page doesn't render while JavaScript is downloading, parsing, or executing during page load

<!doctype html>
<html>
<head>
</head>
<body>
<p>Hello world!</p>
<script src="bar.js"></script>
<p>See ya!</p>
<script src="baz.js"></script>
<p>Uh oh!</p>
</body>
</html>

Result
UI Thread
JavaScript
UI Update
UI Update
JavaScript
JavaScript
time
The more scripts to download in between UI
updates, the longer the page takes to render

Technique #1: Put scripts at the bottom

<!doctype html>
<html>
<head>
</head>
<body>
<p>Hello world!</p>
<p>See ya!</p>
</body>
</html>

Put Scripts at Bottom
UI Thread
JavaScript
UI Update
UI Update
JavaScript
JavaScript
time
Even if there are multiple scripts, the page
renders quickly

Technique #2: Combine JavaScript files

<!doctype html>
<html>
<head>
</head>
<body>
<p>Hello world!</p>
<p>See ya!</p>
<script src="bar.js"></script>
<script src="baz.js"></script>
</body>
</html>

UI Thread
JavaScript
UI Update
JavaScript
JavaScript
time
Each script has overhead of downloading

UI Thread
JavaScript
UI Update
time
Combining all of the files limits the network
overhead and gets scripts onto the page faster

<!doctype html>
<html>
<head>
</head>
<body>
<p>Hello world!</p>
<p>See ya!</p>
<script src="foo-and-bar-and-baz.js"></script>
</body>
</html>

Technique #3: Load scripts dynamically

Basic Technique
var script = document.createElement("script"),
body;
script.type = "text/javascript";
script.src = "foo.js";
body.insertBefore(script, body.firstChild);
Dynamically loaded scripts are non-blocking

Downloads no longer block the UI thread

<!doctype html>
<html>
<head>
</head>
<body>
<p>Hello world!</p>
<p>See ya!</p>
</body>
</html>

Using HTML <script>
UI Thread
Download
See ya!
Hello world!
Parse
Run
time

<!doctype html>
<html>
<head>
</head>
<body>
<p>Hello world!</p>
<script>
var script = document.createElement("script"),
body = document.body;
script.type = "text/javascript";
script.src = "foo.js";
body.insertBefore(script, body.firstChild);
</script>
<p>See ya!</p>
</body>
</html>

Using Dynamic Scripts
UI Thread
See ya!
Hello world!
UI Update
Run
time
Download
Parse
Only code execution happens on the UI thread,
which means less blocking of UI updates

Usage
loadScript("foo.js", function(){
alert("Loaded!");
});

Timing Note:Script execution begins immediately after download and parse – timing of execution is not guaranteed

Technique #4: Defer scripts

<!doctype html>
<html>
<head>
</head>
<body>
<p>Hello world!</p>
<script defer src="foo.js"></script>
<p>See ya!</p>

</body>
</html>

Support for <script defer>
?
5.0
3.5
7.0
4.0

Deferred scripts begin to download immediately, but don't execute until all UI updates complete

Using <script defer>
UI Thread
See ya!
Hello world!
More UI
Run
More UI
time
Download
Parse
Similar to dynamic script nodes, but with a
guarantee that execution will happen last

Timing Note:Although scripts always execute after UI updates complete, the order of multiple <script defer> scripts is not guaranteed across browsers

Technique #5: Asynchronous scripts

<!doctype html>
<html>
<head>
</head>
<body>
<p>Hello world!</p>
<script async src="foo.js"></script>
<p>See ya!</p>

</body>
</html>

Support for <script async>
?
5.0
3.6
7.0
10

Asynchronous scripts behave a lot like dynamic scripts

Using <script async>
UI Thread
See ya!
Hello world!
UI Update
Run
time
Download
Parse
Download begins immediately and execution is
slotted in at first available spot

Note:Order of execution is explicitly not preserved for asynchronous scripts

Runtime TechniquesWays 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();
}

Technique #1: Timers

//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
time
UI Queue
UI Update
onclick
UI Update

When Clicked
UI Thread
UI Update
time
UI Queue
onclick
UI Update

When Clicked
UI Thread
onclick
UI Update
time
UI Queue
UI Update

When Clicked
UI Thread
UI Update
UI Update
onclick
time
UI Queue

After 25ms
UI Thread
UI Update
UI Update
onclick
time
UI Queue
JavaScript

After 25ms
UI Thread
JavaScript
UI Update
UI Update
onclick
time
UI Queue

After Another 25ms
UI Thread
JavaScript
UI Update
UI Update
onclick
time
UI Queue
JavaScript

After Another 25ms
UI Thread
JavaScript
JavaScript
UI Update
UI Update
onclick
time
UI Queue

Technique #2: Script Yielding
NEW!

//delay a function until after UI updates are done
setImmediate(function(){
//code to execute here
});
setImmediate() adds code to the UI queue after pending UI updates are finished

Support for Script Yielding
?
?
?
?
10
msSetIntermediate()

functionyieldingProcessArray(items, process, callback){
//create a clone of the originalvartodo = items.concat();
setImmediate(function(){
var start = +new Date();
do {
process(todo.shift());
} while (todo.length > 0 &&
(+new Date() - start < 50));
if (todo.length > 0){
setImmediate(arguments.callee);
} else {
callback(items);
}
});
}

When Clicked
UI Thread
time
UI Queue
UI Update
onclick
UI Update

When Clicked
UI Thread
UI Update
time
UI Queue
onclick
UI Update

When Clicked
UI Thread
onclick
UI Update
time
UI Queue
UI Update

When Clicked
UI Thread
UI Update
UI Update
onclick
time
UI Queue

After Last UI Update
UI Thread
UI Update
UI Update
onclick
time
UI Queue
JavaScript

After Last UI Update
UI Thread
JavaScript
UI Update
UI Update
onclick
time
UI Queue

No Other UI Updates
UI Thread
JavaScript
UI Update
UI Update
onclick
time
UI Queue
JavaScript

No Other UI Updates
UI Thread
JavaScript
JavaScript
UI Update
UI Update
onclick
time
UI Queue

Technique #3: Web Workers

Support for Web Workers
10.6
4.0
3.5
4.0
10

Web Workers
Asynchronous JavaScript execution
Execution happens outside the UI thread
Doesn’t block UI updates
Data-Driven API
Data is serialized going into and out of the worker
No access to DOM or BOM
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
time
UI Queue
UI Update
onclick
UI Update

When Clicked
UI Thread
UI Update
time
UI Queue
onclick
UI Update

When Clicked
UI Thread
onclick
UI Update
time
UI Queue
UI Update

When Clicked
UI Thread
onclick
UI Update
time
UI Queue
Worker Thread
UI Update

When Clicked
UI Thread
UI Update
UI Update
onclick
time
UI Queue
Worker Thread
JavaScript

Worker Thread Complete
UI Thread
UI Update
UI Update
onclick
time
UI Queue
onmessage

Worker Thread Complete
UI Thread
onmessage
UI Update
UI Update
onclick
time
UI Queue

Repaint and ReflowHidden performance costs of common operations

Long UI updates=Unresponsive UI

Unresponsive UI
UI Thread
JavaScript
UI Update
UI Update
time

JavaScript can cause long UI updates by triggeringrepaint 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 reflowoccurs 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 executesand 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 #1Perform 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 #2Group Style Changes

Repaint!
Reflow!
element.style.color = "red";
element.style.height = "100px";
element.style.fontSize = "25px";
element.style.backgroundColor = "white";
Reflow!
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 #3Avoid Accidental Reflow

Accidental Reflow
element.style.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

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

Responsive UI
UI Thread
JavaScript
UI Update
UI Update
time

Unresponsive UI
UI Thread
JavaScript
UI Update
UI Update
time

Avoid Slow Loading JavaScript
Dynamically created scripts
Deferred scripts
Asynchronous scripts

Avoid Slow JavaScript
Don't allow JavaScript to execute for more than 50ms
Break up long JavaScript processes using:
Timers
Script Yielding (future)
Web Workers

Etcetera
My blog: www.nczonline.net
Twitter: @slicknet
These Slides: slideshare.net/nzakas
Hire us: projects@stubbornella.org

Questions?

Creative Commons Images Used
http://www.flickr.com/photos/lrargerich/3115367361/
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/
http://www.flickr.com/photos/goincase/3843348908/

http://twitter.com	2
http://a0.twimg.com	2
https://twimg0-a.akamaihd.net	2
http://b.hatena.ne.jp	1

High Performance JavaScript 2011

by Nicholas Zakas on Jun 26, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 7

Statistics

High Performance JavaScript 2011 — Presentation Transcript