Malte Ubl on web.dev

Introducing WebSockets - Bringing Sockets to the Web

2012-10-20T00:00:00Z

The problem: Low latency client-server and server-client connections #

The web has been largely built around the so-called request/response paradigm of HTTP. A client loads up a web page and then nothing happens until the user clicks onto the next page. Around 2005, AJAX started to make the web feel more dynamic. Still, all HTTP communication was steered by the client, which required user interaction or periodic polling to load new data from the server.

Technologies that enable the server to send data to the client in the very moment when it knows that new data is available have been around for quite some time. They go by names such as 'Push' or 'Comet'. One of the most common hacks to create the illusion of a server initiated connection is called long polling. With long polling, the client opens an HTTP connection to the server which keeps it open until sending response. Whenever the server actually has new data it sends the response (other techniques involve Flash, XHR multipart requests and so called htmlfiles). Long polling and the other techniques work quite well. You use them every day in applications such as GMail chat.

However, all of these work-arounds share one problem: They carry the overhead of HTTP, which doesn't make them well suited for low latency applications. Think multiplayer first person shooter games in the browser or any other online game with a realtime component.

Introducing WebSocket: Bringing sockets to the web #

The WebSocket specification defines an API establishing "socket" connections between a web browser and a server. In plain words: There is an persistent connection between the client and the server and both parties can start sending data at any time.

Getting Started #

You open up a WebSocket connection simply by calling the WebSocket constructor:

var connection = new WebSocket('ws://html5rocks.websocket.org/echo', ['soap', 'xmpp']);

Notice the ws:. This is the new URL schema for WebSocket connections. There is also wss: for secure WebSocket connection the same way https: is used for secure HTTP connections.

Attaching some event handlers immediately to the connection allows you to know when the connection is opened, received incoming messages, or there is an error.

The second argument accepts optional sub-protocols. It can be a string or an array of strings. Each string should represent a sub-protocol name and server accepts only one of passed sub-protocols in the array. Accepted sub-protocol can be determined by accessing protocol property of WebSocket object.

The sub-protocol names must be one of registered sub-protocol names in IANA registry. There is currently only one sub-protocol name (soap) registered as of February 2012.

// When the connection is open, send some data to the server
connection.onopen = function () {
connection.send('Ping'); // Send the message 'Ping' to the server
};

// Log errors
connection.onerror = function (error) {
console.log('WebSocket Error ' + error);
};

// Log messages from the server
connection.onmessage = function (e) {
console.log('Server: ' + e.data);
};

Communicating with the server #

As soon as we have a connection to the server (when the open event is fired) we can start sending data to the server using the send('your message') method on the connection object. It used to support only strings, but in the latest spec it now can send binary messages too. To send binary data, you can use either Blob or ArrayBuffer object.

// Sending String
connection.send('your message');

// Sending canvas ImageData as ArrayBuffer
var img = canvas_context.getImageData(0, 0, 400, 320);
var binary = new Uint8Array(img.data.length);
for (var i = 0; i < img.data.length; i++) {
binary[i] = img.data[i];
}
connection.send(binary.buffer);

// Sending file as Blob
var file = document.querySelector('input[type="file"]').files[0];
connection.send(file);

Equally the server might send us messages at any time. Whenever this happens the onmessage callback fires. The callback receives an event object and the actual message is accessible via the data property.

WebSocket can also receive binary messages in the latest spec. Binary frames can be received in Blob or ArrayBuffer format. To specify the format of the received binary, set the binaryType property of WebSocket object to either 'blob' or 'arraybuffer'. The default format is 'blob'. (You don't have to align binaryType param on sending.)

// Setting binaryType to accept received binary as either 'blob' or 'arraybuffer'
connection.binaryType = 'arraybuffer';
connection.onmessage = function(e) {
console.log(e.data.byteLength); // ArrayBuffer object if binary
};

Another newly added feature of WebSocket is extensions. Using extensions, it will be possible to send frames compressed, multiplexed, etc. You can find server accepted extensions by examining the extensions property of the WebSocket object after the open event. There is no officially published extensions spec just yet as of February 2012.

// Determining accepted extensions
console.log(connection.extensions);

Cross-origin communication #

Being a modern protocol, cross origin communication is baked right into WebSocket. While you should still make sure only to communicate with clients and servers that you trust, WebSocket enables communication between parties on any domain. The server decides whether to make its service available to all clients or only those that reside on a set of well defined domains.

Proxy servers #

Every new technology comes with a new set of problems. In the case of WebSocket it is the compatibility with proxy servers which mediate HTTP connections in most company networks. The WebSocket protocol uses the HTTP upgrade system (which is normally used for HTTP/SSL) to 'upgrade' an HTTP connection to a WebSocket connection. Some proxy servers do not like this and will drop the connection. Thus, even if a given client uses the WebSocket protocol, it may not be possible to establish a connection. This makes the next section even more important :)

Use WebSockets today #

WebSocket is still a young technology and not fully implemented in all browsers. However, you can use WebSocket today with libraries that use one of the fallbacks mentioned above whenever WebSocket is not available. A library that has become very popular in this domain is socket.io which comes with a client and a server implementation of the protocol and includes fallbacks (socket.io doesn't support binary messaging yet as of Februrary 2012). There are also commercial solutions such as PusherApp which can be easily integrated into any web environment by providing a HTTP API to send WebSocket messages to clients. Due to the extra HTTP request there will always be extra overhead compared to pure WebSocket.

The server side #

Using WebSocket creates a whole new usage pattern for server side applications. While traditional server stacks such as LAMP are designed around the HTTP request/response cycle they often do not deal well with a large number of open WebSocket connections. Keeping a large number of connections open at the same time requires an architecture that receives high concurrency at a low performance cost. Such architectures are usually designed around either threading or so called non-blocking IO.

Server side implementations #

Node.js
Java
- Jetty
Ruby
- EventMachine
Python
- pywebsocket
- Tornado
Erlang
- Shirasu
C++
- libwebsockets
.NET
- SuperWebSocket

Protocol versions #

The wire protocol (a handshake and the data transfer between client and server) for WebSocket is now RFC6455. The latest Chrome and Chrome for Android are fully compatible with RFC6455 including binary messaging. Also, Firefox will be compatible on version 11, Internet Explorer on version 10. You can still use older protocol versions but it is not recommended since they are known to be vulnerable. If you have server implementations for older versions of WebSocket protocol, we recommend you to upgrade it to the latest version.

Use cases #

Use WebSocket whenever you need a truly low latency, near realtime connection between the client and the server. Keep in mind that this might involve rethinking how you build your server side applications with a new focus on technologies such as event queues. Some example use cases are:

Multiplayer online games
Chat applications
Live sports ticker
Realtime updating social streams

Demos #

References #

The Basics of Web Workers

2012-10-20T00:00:00Z

The problem: JavaScript concurrency #

There are a number of bottlenecks preventing interesting applications from being ported (say, from server-heavy implementations) to client-side JavaScript. Some of these include browser compatibility, static typing, accessibility, and performance. Fortunately, the latter is quickly becoming a thing of the past as browser vendors rapidly improve the speed of their JavaScript engines.

One thing that's remained a hindrance for JavaScript is actually the language itself. JavaScript is a single-threaded environment, meaning multiple scripts cannot run at the same time. As an example, imagine a site that needs to handle UI events, query and process large amounts of API data, and manipulate the DOM. Pretty common, right? Unfortunately all of that can't be simultaneous due to limitations in browsers' JavaScript runtime. Script execution happens within a single thread.

Developers mimic 'concurrency' by using techniques like setTimeout(), setInterval(), XMLHttpRequest, and event handlers. Yes, all of these features run asynchronously, but non-blocking doesn't necessarily mean concurrency. Asynchronous events are processed after the current executing script has yielded. The good news is that HTML5 gives us something better than these hacks!

Introducing Web Workers: bring threading to JavaScript #

The Web Workers specification defines an API for spawning background scripts in your web application. Web Workers allow you to do things like fire up long-running scripts to handle computationally intensive tasks, but without blocking the UI or other scripts to handle user interactions. They're going to help put and end to that nasty 'unresponsive script' dialog that we've all come to love:

Common unresponsive script dialog.

Workers utilize thread-like message passing to achieve parallelism. They're perfect for keeping your UI refresh, performant, and responsive for users.

Types of Web Workers #

It's worth noting that the specification discusses two kinds of Web Workers, Dedicated Workers and Shared Workers. This article will only cover dedicated workers. I'll refer to them as 'web workers' or 'workers' throughout.

Getting started #

Web Workers run in an isolated thread. As a result, the code that they execute needs to be contained in a separate file. But before we do that, the first thing to do is create a new Worker object in your main page. The constructor takes the name of the worker script:

var worker = new Worker('task.js');

If the specified file exists, the browser will spawn a new worker thread, which is downloaded asynchronously. The worker will not begin until the file has completely downloaded and executed. If the path to your worker returns an 404, the worker will fail silently.

After creating the worker, start it by calling the postMessage() method:

worker.postMessage(); // Start the worker.

Communicating with a worker via message passing #

Communication between a work and its parent page is done using an event model and the postMessage() method. Depending on your browser/version, postMessage() can accept either a string or JSON object as its single argument. The latest versions of the modern browsers support passing a JSON object.

Below is a example of using a string to pass 'Hello World' to a worker in doWork.js. The worker simply returns the message that is passed to it.

Main script:

var worker = new Worker('doWork.js');

worker.addEventListener('message', function(e) {
console.log('Worker said: ', e.data);
}, false);

worker.postMessage('Hello World'); // Send data to our worker.

doWork.js (the worker):

self.addEventListener('message', function(e) {
self.postMessage(e.data);
}, false);

When postMessage() is called from the main page, our worker handles that message by defining an onmessage handler for the message event. The message payload (in this case 'Hello World') is accessible in Event.data. Although this particular example isn't very exciting, it demonstrates that postMessage() is also your means for passing data back to the main thread. Convenient!

Messages passed between the main page and workers are copied, not shared. For example, in the next example the 'msg' property of the JSON message is accessible in both locations. It appears that the object is being passed directly to the worker even though it's running in a separate, dedicated space. In actuality, what is happening is that the object is being serialized as it's handed to the worker, and subsequently, de-serialized on the other end. The page and worker do not share the same instance, so the end result is that a duplicate is created on each pass. Most browsers implement this feature by automatically JSON encoding/decoding the value on either end.

The following is a more complex example that passes messages using JSON objects.

Main script:

<button onclick="sayHI()">Say HI</button>
<button onclick="unknownCmd()">Send unknown command</button>
<button onclick="stop()">Stop worker</button>
<output id="result"></output>

<script>
function sayHI() {
worker.postMessage({'cmd': 'start', 'msg': 'Hi'});
}

function stop() {
// worker.terminate() from this script would also stop the worker.
worker.postMessage({'cmd': 'stop', 'msg': 'Bye'});
}

function unknownCmd() {
worker.postMessage({'cmd': 'foobard', 'msg': '???'});
}

var worker = new Worker('doWork2.js');

worker.addEventListener('message', function(e) {
document.getElementById('result').textContent = e.data;
}, false);
</script>

doWork2.js:

self.addEventListener('message', function(e) {
var data = e.data;
switch (data.cmd) {
case 'start':
    self.postMessage('WORKER STARTED: ' + data.msg);
    break;
case 'stop':
    self.postMessage('WORKER STOPPED: ' + data.msg +
                    '. (buttons will no longer work)');
    self.close(); // Terminates the worker.
    break;
default:
    self.postMessage('Unknown command: ' + data.msg);
};
}, false);

Transferrable objects #

Most browsers implement the structured cloning algorithm, which allows you to pass more complex types in/out of Workers such as File, Blob, ArrayBuffer, and JSON objects. However, when passing these types of data using postMessage(), a copy is still made. Therefore, if you're passing a large 50MB file (for example), there's a noticeable overhead in getting that file between the worker and the main thread.

Structured cloning is great, but a copy can take hundreds of milliseconds. To combat the perf hit, you can use Transferable Objects.

With Transferable Objects, data is transferred from one context to another. It is zero-copy, which vastly improves the performance of sending data to a Worker. Think of it as pass-by-reference if you're from the C/C++ world. However, unlike pass-by-reference, the 'version' from the calling context is no longer available once transferred to the new context. For example, when transferring an ArrayBuffer from your main app to Worker, the original ArrayBuffer is cleared and no longer usable. Its contents are (quiet literally) transferred to the Worker context.

To use transferrable objects, use a slightly different signature of postMessage():

worker.postMessage(arrayBuffer, [arrayBuffer]);
window.postMessage(arrayBuffer, targetOrigin, [arrayBuffer]);

The worker case, the first argument is the data and the second is the list of items that should be transferred. The first argument doesn't have to be an ArrayBuffer by the way. For example, it can be a JSON object:

worker.postMessage({data: int8View, moreData: anotherBuffer},
                [int8View.buffer, anotherBuffer]);

The important point being: the second argument must be an array of ArrayBuffers. This is your list of transferrable items.

For more information on transferrables, see our post at developer.chrome.com.

The worker environment #

Worker scope #

In the context of a worker, both self and this reference the global scope for the worker. Thus, the previous example could also be written as:

addEventListener('message', function(e) {
var data = e.data;
switch (data.cmd) {
case 'start':
    postMessage('WORKER STARTED: ' + data.msg);
    break;
case 'stop':
...
}, false);

Alternatively, you could set the onmessage event handler directly (though addEventListener is always encouraged by JavaScript ninjas).

onmessage = function(e) {
var data = e.data;
...
};

Features available to workers #

Due to their multithreaded behavior, Web Workers only has access to a subset of JavaScript's features:

The navigator object
The location object (read-only)
XMLHttpRequest
setTimeout()/clearTimeout() and setInterval()/clearInterval()
The Application Cache
Importing external scripts using the importScripts() method
Spawning other web workers

Workers do NOT have access to:

The DOM (it's not thread-safe)
The window object
The document object
The parent object

Loading external scripts #

You can load external script files or libraries into a worker with the importScripts() function. The method takes zero or more strings representing the filenames for the resources to import.

This example loads script1.js and script2.js into the worker:

worker.js:

importScripts('script1.js');
importScripts('script2.js');

Which can also be written as a single import statement:

importScripts('script1.js', 'script2.js');

Subworkers #

Workers have the ability to spawn child workers. This is great for further breaking up large tasks at runtime. However, subworkers come with a few caveats:

Subworkers must be hosted within the same origin as the parent page.
URIs within subworkers are resolved relative to their parent worker's location (as opposed to the main page).

Keep in mind most browsers spawn separate processes for each worker. Before you go spawning a worker farm, be cautious about hogging too many of the user's system resources. One reason for this is that messages passed between main pages and workers are copied, not shared. See Communicating with a Worker via Message Passing.

For an sample of how to spawn a subworker, see the example in the specification.

Inline workers #

What if you want to create your worker script on the fly, or create a self-contained page without having to create separate worker files? With Blob(), you can "inline" your worker in the same HTML file as your main logic by creating a URL handle to the worker code as a string:

var blob = new Blob([
"onmessage = function(e) { postMessage('msg from worker'); }"]);

// Obtain a blob URL reference to our worker 'file'.
var blobURL = window.URL.createObjectURL(blob);

var worker = new Worker(blobURL);
worker.onmessage = function(e) {
// e.data == 'msg from worker'
};
worker.postMessage(); // Start the worker.

Blob URLs #

The magic comes with the call to window.URL.createObjectURL(). This method creates a simple URL string which can be used to reference data stored in a DOM File or Blob object. For example:

blob:http://localhost/c745ef73-ece9-46da-8f66-ebes574789b1

Blob URLs are unique and last for the lifetime of your application (e.g. until the document is unloaded). If you're creating many Blob URLs, it's a good idea to release references that are no longer needed. You can explicitly release a Blob URLs by passing it towindow.URL.revokeObjectURL():

window.URL.revokeObjectURL(blobURL);

In Chrome, there's a nice page to view all of the created blob URLs: chrome://blob-internals/.

Full example #

Taking this one step further, we can get clever with how the worker's JS code is inlined in our page. This technique uses a <script> tag to define the worker:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
</head>
<body>

<div id="log"></div>

<script id="worker1" type="javascript/worker">
// This script won't be parsed by JS engines
// because its type is javascript/worker.
self.onmessage = function(e) {
    self.postMessage('msg from worker');
};
// Rest of your worker code goes here.
</script>

<script>
function log(msg) {
    // Use a fragment: browser will only render/reflow once.
    var fragment = document.createDocumentFragment();
    fragment.appendChild(document.createTextNode(msg));
    fragment.appendChild(document.createElement('br'));

    document.querySelector("#log").appendChild(fragment);
}

var blob = new Blob([document.querySelector('#worker1').textContent]);

var worker = new Worker(window.URL.createObjectURL(blob));
worker.onmessage = function(e) {
    log("Received: " + e.data);
}
worker.postMessage(); // Start the worker.
</script>
</body>
</html>

In my opinion, this new approach is a bit cleaner and more legible. It defines a script tag with id="worker1" and type='javascript/worker' (so the browser doesn't parse the JS). That code is extracted as a string using document.querySelector('#worker1').textContent and passed to Blob() to create the file.

Loading external scripts #

When using these techniques to inline your worker code, importScripts() will only work if you supply an absolute URI. If you attempt to pass a relative URI, the browser will complain with a security error. The reason being: the worker (now created from a blob URL) will be resolved with a blob: prefix, while your app will be running from a different (presumably http://) scheme. Hence, the failure will be due to cross origin restrictions.

One way to utilize importScripts() in an inline worker is to "inject" the current url of your main script is running from by passing it to the inline worker and constructing the absolute URL manually. This will insure the external script is imported from the same origin. Assuming your main app is running from http://example.com/index.html:

...
<script id="worker2" type="javascript/worker">
self.onmessage = function(e) {
var data = e.data;

if (data.url) {
var url = data.url.href;
var index = url.indexOf('index.html');
if (index != -1) {
    url = url.substring(0, index);
}
importScripts(url + 'engine.js');
}
...
};
</script>
<script>
var worker = new Worker(window.URL.createObjectURL(bb.getBlob()));
worker.postMessage(<b>{url: document.location}</b>);
</script>

handling errors #

As with any JavaScript logic, you'll want to handle any errors that are thrown in your web workers. If an error occurs while a worker is executing, the an ErrorEvent is fired. The interface contains three useful properties for figuring out what went wrong: filename - the name of the worker script that caused the error, lineno - the line number where the error occurred, and message - a meaningful description of the error. Here is an example of setting up an onerror event handler to print the properties of the error:

<output id="error" style="color: red;"></output>
<output id="result"></output>

<script>
function onError(e) {
document.getElementById('error').textContent = [
    'ERROR: Line ', e.lineno, ' in ', e.filename, ': ', e.message
].join('');
}

function onMsg(e) {
document.getElementById('result').textContent = e.data;
}

var worker = new Worker('workerWithError.js');
worker.addEventListener('message', onMsg, false);
worker.addEventListener('error', onError, false);
worker.postMessage(); // Start worker without a message.
</script>

Example: workerWithError.js tries to perform 1/x, where x is undefined.

workerWithError.js:

self.addEventListener('message', function(e) {
postMessage(1/x); // Intentional error.
};

A word on security #

Restrictions with local access #

Due to Google Chrome's security restrictions, workers will not run locally (e.g. from file://) in the latest versions of the browser. Instead, they fail silently! To run your app from the file:// scheme, run Chrome with the --allow-file-access-from-files flag set.

Other browsers do not impose the same restriction.

Same-origin considerations #

Worker scripts must be external files with the same scheme as their calling page. Thus, you cannot load a script from a data: URL or javascript: URL, and an https: page cannot start worker scripts that begin with http: URLs.

Use cases #

So what kind app would utilize web workers? Here are a few more ideas to get your brain churning:

Prefetching and/or caching data for later use.
Code syntax highlighting or other real-time text formatting.
Spell checker.
Analyzing video or audio data.
Background I/O or polling of webservices.
Processing large arrays or humungous JSON responses.
Image filtering in <canvas>.
Updating many rows of a local web database.

For more information about use cases involving the Web Workers API, visit Workers Overview.

Demos #

HTML5demos sample

References #

Web Workers specification
"Using web workers" from the Mozilla Developer Network Web Docs.
"Web Workers rise up!" from Dev.Opera

Rendering HTML5 in older browsers with Google Chrome Frame

2011-05-30T00:00:00Z

Introduction #

HTML5 adds a multitude of new awesome tools to the web developer toolbox, including the following:

New, more powerful JavaScript APIs
SVG for vector graphics
Canvas for 2D and with WebGL 3D graphics
CSS3 for rounded corners, gradients, etc.
More expressive markup

This list is, of course, not comprehensive; the web platform has moved forward massively, and the gap between old browsers and modern ones is widening every day.
Every major desktop browser now supports significant parts of HTML5 in the latest version but old browsers sticking around create a challenge for adopting the latest and greatest features today.

Google Chrome Frame can help you build state-of-the-art HTML5 pages today while still enabling people using older browsers to see your content.

What is Google Chrome Frame #

Google Chrome Frame is a plugin for Internet Explorer that enables rendering the full browser canvas using Google Chrome’s rendering engine. It supports all the HTML5 features that you find in Chrome seamlessly integrated into the Internet Explorer user experience. Chrome Frame is available for Internet Explorer 6, 7, 8, and 9. Chrome Frame is certainly more useful when supporting old browser such as IE6-to-IE8 but if you, for example, require WebGL for your application, requiring Chrome Frame for IE9 users might be useful as well.

HTML5 polyfills provide another way to smooth out the transition to newer browsers. Unfortunately, they cannot emulate every feature, and they slow down your page in old browsers, which are already slower that the new generation, even more.

Even if your site does not need HTML5 features, using Chrome Frame could still provide a better user experience. For users who already have it installed, rendering is generally faster and they can get access to features that are not supported in older browsers. You can, of course, still decide to support old browsers for users who do not have Chrome Frame on their machine.

Opting in #

You can enable Chrome Frame to render a page by adding an HTML metatag or using an HTTP header. This is very important. It means no site will break if a user has Chrome Frame installed, because the site is in full control of using the plugin or default rendering. The following code snippets show how a site can opt into being rendered by Chrome Frame.

Option 1: HTTP-Header (you can add this to your HTTP server (e.g. Apache) configuration):

X-UA-Compatible: chrome=1

Option 2: Meta-tag (Just paste this into your HTML <head> section)

<meta http-equiv="X-UA-Compatible" content="chrome=1">

Once you have added either one of these to your site, pages are rendered using Chrome Frame if it is installed on the user’s machine.

Prompting for Google Chrome Frame #

You may decide to fully deprecate support for old browsers for many reasons including the following:

Your site requires modern features such as HTML5 video, canvas, WebGL, or CSS3
Development time spent on old browsers is too high
Speed up development time for new features

Chrome Frame might provide a strategy to continue giving users of old browsers a way to still use your site.

Chrome Frame transmits that it is available by extending the host's User-Agent header with the string "chromeframe". For more information see Chrome Frame User Agent.

Use server-side detection to look for this token and determine whether Chrome Frame can be used for a page. If Chrome Frame is present, you can insert the required meta tag; if not, you can redirect users to a page that explains how to install Chrome Frame. As an alternative to server-side sniffing, you can use the CFInstall.js script to detect Chrome Frame and prompt users to install the plug-in without restarting their browsers. Using the script is straightforward. Just add the script tags and optional styles to your page as in the following example:

<html>
<body>
<script type="text/javascript"
src="http://ajax.googleapis.com/ajax/libs/chrome-frame/1/CFInstall.min.js"></script>

<style>
/*
CSS rules to use for styling the overlay:
    .chromeFrameOverlayContent
    .chromeFrameOverlayContent iframe
    .chromeFrameOverlayCloseBar
    .chromeFrameOverlayUnderlay
*/
</style>

<script>
// You may want to place these lines inside an onload handler
CFInstall.check({
mode: "overlay",
destination: "http://www.waikiki.com"
});
</script>
</body>
</html>

Prompt yourself #

You might also decide to build a landing page or layer yourself. Send users to this URL

http://www.google.com/chromeframe/

which can be put in an IFRAME.

Append a redirect parameter to send users back to your site after installation is complete:

http://www.google.com/chromeframe/?redirect=http://www.google.com/ Instead of going to the Chrome Frame landing page, you could also send the users directly to the EULA thus saving one step in the installation process. http://www.google.com/chromeframe/eula.html

No admin-rights needed #

Users can install Chrome Frame without having administrative privileges on their machines.

Append the user=true parameter to enable user level installation of Chrome Frame, as in the following:

http://www.google.com/chromeframe/?user=true

Enterprise installation #

Enterprises can deploy Chrome Frame company wide using the MSI installer which can be downloaded here: http://www.google.com/chromeframe/eula.html?msi=true.

For more information on Chrome and enterprise deployments see http://www.chromium.org/administrators.

Adoption #

Many major websites such as yahoo.com, wordpress.com and several Google properties have adopted Google Chrome Frame. Besides giving their users access to a more modern web experience for many sites, Chrome Frame also presents a significant improvement in initial load time. You can check whether Chrome Frame helps your site get faster rendering by going to webpagetest.org and selecting Chrome Frame as the browser.

More info #

For more Information see the Getting Started Guide or watch this video from Google IO 2011

Improving the performance of your HTML5 App

2011-02-14T00:00:00Z

Introduction #

HTML5 gives us great tools to enhance the visual appearance of web applications. This is especially true in the realm of animations. However, with this new power also come new challenges. Actually these challenges aren't really that new and it might sometimes make sense to ask your friendly desk neighbor, the Flash programmer, how she has overcome similar things in the past.

Anyway, when you work in animation it becomes hugely important that users perceive these animations to be smooth. What we need to realize is that smoothness in animations can't really be created by simply increasing the frames per second beyond any cognitive threshold. Our brain is, unfortunately, smarter than that. What you will learn is that true 30 frames of animation per second (fps) is much better than 60 fps with just a few frames dropped in the middle. People hate jaggedness.

This article will try to give you the tools and techniques to work on improving the experience of your own application.

The Strategy #

By no means do we want to discourage you from building awesome, stunningly visual apps with HTML5.

Then when you notice that performance could be a little better, come back here and read up on how you can improve the elements of your application. It can, of course, help to do some things right in the first place but never let that get in your way of being productive.

Visual fidelity++ with HTML5 #

Hardware Acceleration #

Hardware acceleration is an important milestone for overall render performance in the browser. The general scheme is to offload tasks that would otherwise be calculated by the main CPU to the graphics processing unit (GPU) in your computer's graphics adapter. This can yield massive performance gains and can also reduce resource consumption on mobile devices.

These aspects of your document can be accelerated by the GPU #

General layout compositing
CSS3 transitions
CSS3 3D transforms
Canvas Drawing
WebGL 3D Drawing

While acceleration of canvas and WebGL are special purpose features that might not apply to your specific application the first three aspects can help pretty much every app to become faster.

What can be accelerated? #

GPU acceleration works by offloading well-defined and specific tasks to special purpose hardware. The general scheme is that your document is broken down into multiple "layers" which are invariant to the aspects of your page that are accelerated. These layers are rendered using the traditional render pipeline. The GPU is then used to composite the layers onto a single page applying the "effects" that can be accelerated on the fly. A possible outcome is that an object that is animated on the screen does not require a single "relayout" of the page while the animation happens.

What you need to take away from that is that you need to make it easy for the rendering engine to identify when it can apply it's GPU acceleration magic. Consider the following example:

While this works, the browser doesn't really know that you are performing something that is supposed to be perceived as smooth animation by a human being. Consider what happens when you achieve the same visual appearance using CSS3 transitions instead:

How the browser implements this animation is completely hidden from the developer. This in turn means that the browser is able to apply tricks such as GPU acceleration to achieve the defined goal.

There are two useful command-line flags for Chrome to help debugging GPU acceleration:

--show-composited-layer-borders shows a red border around elements that are being manipulated at the GPU level. Good for confirming your manipulations occur within the GPU layer.
--show-paint-rects all non-GPU changes are painted and this throws a light border around all areas that are repainted. You can see the browser optimizing paint areas in action.

Safari has similar runtime flags described here.

CSS3 Transitions #

CSS Transitions make style animation trivial for everyone, but they also are a smart performance feature. Because a CSS transition is managed by the browser, the fidelity of its animation can be greatly improved, and in many cases hardware accelerated. Currently WebKit (Chrome, Safari, iOS) have hardware accelerated CSS transforms, but it's coming quickly to other browsers and platforms.

You can use transitionEnd events in order to script this into powerful combinations, though right now, capturing all supported transition end events means watching webkitTransitionEnd transitionend oTransitionEnd.

Many libraries have now introduced animation APIs that leverage transitions if present and fall back to standard DOM style animation otherwise. scripty2, YUI transition, jQuery animate enhanced.

CSS3 Translate #

I'm sure you've found yourself animating the x/y position of an element across the page before. You probably manipulated the inline style's left and top properties. With 2D transforms, we can use the translate() functionality to replicate this behavior.

We can combo this with DOM animation to use the best thing possible

<div style="position:relative; height:120px;" class="hwaccel">

  <div style="padding:5px; width:100px; height:100px; background:papayaWhip;
              position:absolute;" id="box">
  </div>
</div>

<script>
document.querySelector('#box').addEventListener('click', moveIt, false);

function moveIt(evt) {
  var elem = evt.target;

  if (Modernizr.csstransforms && Modernizr.csstransitions) {
    // vendor prefixes omitted here for brevity
    elem.style.transition = 'all 3s ease-out';
    elem.style.transform = 'translateX(600px)';

  } else {
    // if an older browser, fall back to jQuery animate
    jQuery(elem).animate({ 'left': '600px'}, 3000);
  }
}
</script>

We use Modernizr to feature test for CSS 2D Transforms and CSS Transitions, if so we're going to use translate to shift the position. If this is animated using a transition there is a good chance the browser can hardware accelerate it. To give the browser another push in the right direction we'll use the "magic CSS bullet" from above.

If our browser is less capable, we'll fallback to jQuery to move our element. You can pick up the jQuery Transform polyfill plugin by Louis-Remi Babe to make this whole thing automatic.

`window.requestAnimationFrame` #

requestAnimationFrame was introduced by Mozilla and iterated on by WebKit with the goal of providing you a native API for running animations, whether they be DOM/CSS-based or on <canvas> or WebGL. The browser can optimize concurrent animations together into a single reflow and repaint cycle, leading to higher fidelity animation. For example, JS-based animations synchronized with CSS transitions or SVG SMIL. Plus, if you're running the animation loop in a tab that's not visible, the browser won't keep it running, which means less CPU, GPU, and memory usage, leading to much longer battery life.

For more details on how and why to use requestAnimationFrame, view Paul Irish's article requestAnimationFrame for smart animating.

Profiling #

When you discover that the speed of your application can be improved, it is time to dig into profiling to find out where optimizations could yield the greatest benefit. Optimizations will often have negative impact on the maintainability of your source code and should thus only be applied if necessary. Profiling tells you which parts of your code would yield the greatest benefits when their performance would be improved.

JavaScript Profiling #

JavaScript profilers give you an overview on the performance of your application on the JavaScript function level by measuring the time it takes to execute each individual function from its starts to its end.

The gross execution time of a function is the overall time it takes to execute it from top to bottom. The net execution time is the gross execution time minus the time it took to execute functions called from the function.

Some functions get called more often than others. Profilers usually give you the time it took for all invocations to run as well as the average and minimum and maximum execution time.

For more details, check out the Chrome Dev Tools docs on profiling.

The DOM #

The performance of JavaScript has a strong influence in to how fluid and responsive your application will feel. It is important to understand that, while JavaScript profilers measure the execution time of your JavaScript, they also indirectly measure the time spent doing DOM operations. These DOM operations are often at the heart of your performance issues.

function drawArray(array) {
  for(var i = 0; i < array.length; i++) {
    document.getElementById('test').innerHTML += array[i]; // No good :(
  }
}

E.g. in the code above almost no time is spent executing actual JavaScript. It is still very likely that the drawArray-function will show up in your profiles because it is interacting with the DOM in a very wasteful fashion.

Tips and Tricks #

Anonymous Functions #

Anonymous functions are not easy to profile because they inherently don't have a name under which they could show up in the profiler. There are two ways to work around this:

$('.stuff').each(function() { ... });

rewrite to:

$('.stuff').each(function workOnStuff() { ... });

It is not commonly known that JavaScript supports naming function expressions. Doing this will make them show up perfectly in the profiler. There is one problem with this solution: The named expression actually puts the function name into the current lexical scope. This might clobber other symbols, so be careful.

Profiling long functions #

Imagine you have a long function and you suspect that a small part of it might be the reason for your performance problems. There are two ways to find out which part is the problem:

The correct method: Refactor your code to not include any long functions.
The evil getting-things-done method: add statements in the form of named self calling functions to your code. If you are a little careful this does not change the semantics and it makes parts of your function show up as individual functions in the profiler:

function myLongFunction() {
  ...
  (function doAPartOfTheWork() {
    ...
  })();
  ...
}

Don't forget to remove these extra functions after profiling is done; or even use them as a starting point to refactor your code.

DOM Profiling #

The latest Chrome Web Inspector development tools contain the new "Timeline View" which shows a timeline of the low level actions performed by the browser. You can use this information to optimize your DOM operations. You should aim to reduce the number of "actions" the browser has to perform while your code executes.

The timeline view can create an immense amount of information. You should thus try to create minimal test cases that you can execute independently.

The image above shows the output of the timeline view for a very simple script. The left pane shows the operations performed by the browser in chronical order, while the timeline in the right pane shows the actual time consumed by an individual operation.

More info on the timeline view. An alternative tool for profiling in Internet Explorer is DynaTrace Ajax Edition.

Profiling Strategies #

Single out aspects #

When you want to profile your application, try to single out the aspects of its functionality that might trigger slowness as close as possible. Then try to do a profile run that only executes parts of your code that are relevant to these aspects of your application. This will make the profiling data easier to interpret because it is not intermixed with code paths that are not related to your actual problem. Good examples for individual aspects of your application might be:

Start up time (activate the profiler, reload application, wait until initialization is complete, stop the profiler.
Click a button and subsequent animation (start profiler, click button, wait until animation is complete, stop profiler).

GUI Profiling #

Executing only the right part of your application can be harder in a GUI program than when you optimize, say, the ray tracer of your 3D engine. When you, for example, want to profile the stuff that happens when you click a button, you might trigger unrelated mouseover events along the way that make your results less conclusive. Try to avoid that :)

Programatic Interface #

There is also a programatic interface to activate the debugger. This allows precise control over when profiling starts and when it ends.

Start a profiling with:

console.profile()

Stop profiling with:

console.profileEnd()

Repeatability #

When you do profiling make sure you can actually reproduce your results. Only then will you be able to tell whether your optimizations did actually improve things. Also function level profiling is done in the context of your whole computer. It is not an exact science. Individual profile runs might be influenced by many other things happening on your computer:

An unrelated timer in your own application that fires while you measure something else.
The garbage collector doing its work.
Another tab in your browser doing hard work in the same operating thread.
Another program on your computer using up the CPU thus making your application slower.
Sudden changes in the gravitational field of the earth.

It also makes sense to execute the same code path multiple times in one profiling session. This way you decrease the influence of above factors and the slow parts may stand out even more clearly.

Measure, improve, measure #

When you identified a slow spot in your program, try to think of ways to improve the execution behavior. After you changed your code, profile again. If you are satisfied with the result, move on, if you are not seeing an improvement you should probably roll back your change and not leave it in "because it can't hurt".

Optimization Strategies #

Minimize DOM interaction #

A common theme for improving the speed of web client applications is to minimize DOM interaction. While the speed of JavaScript engines has increased by an order of magnitude, accessing the DOM has not gotten faster at the same rate. This is also for very practical reasons never going to happen (things like layouting and drawing stuff on a screen just take time).

Cache DOM Nodes #

Whenever you retrieve a node or a list of nodes from the DOM, try to think about whether you might be able to reuse them in a later computation (or even just the next loop iteration). As long as you don't actually add or delete nodes in the relevant area, this is often the case.

Before:

function getElements() {
  return $('.my-class');
}

After:

var cachedElements;
function getElements() {
  if (cachedElements) {
    return cachedElements;
  }
  cachedElements = $('.my-class');
  return cachedElements;
}

Cache Attribute Values #

The same way you can cache DOM nodes you can also cache the values of attributes. Imagine you are animating an attribute of a node's style. If you know that you (as in that part of the code) are the only one that will ever touch that attribute you can cache the last value on every iteration so that you will not have to read it repeatedly.

Before:

setInterval(function() {
  var ele = $('#element');
  var left = parseInt(ele.css('left'), 10);
  ele.css('left', (left + 5) + 'px');
}, 1000 / 30);

After:

var ele = $('#element');
var left = parseInt(ele.css('left'), 10);
setInterval(function() {
  left += 5;
  ele.css('left', left + 'px');
}, 1000 / 30);

Move DOM Manipulation Out of Loops #

Loops are often hot points for optimization. Try to think of ways to decouple actual number crunching to working with the DOM. It is often possible to do a calculation and then, after it is done, apply all the results in one go.

Before:

document.getElementById('target').innerHTML = '';
for(var i = 0; i < array.length; i++) {
  var val = doSomething(array[i]);
  document.getElementById('target').innerHTML += val;
}

After:

var stringBuilder = [];
for(var i = 0; i < array.length; i++) {
  var val = doSomething(array[i]);
  stringBuilder.push(val);
}
document.getElementById('target').innerHTML = stringBuilder.join('');

Redraws and Reflows #

As discussed earlier accessing the DOM is relatively slow. It becomes very slow when your code is reading a value which has to be recalculated because your code recently modified something related in the DOM. Thus, it should be avoided to intermix reading and writing access to the DOM. Ideally your code should always be grouped in two phases:

Phase 1: Read DOM values necessary for your code
Phase 2: Modify the DOM

Try not to program a pattern such as:

Phase 1: Read DOM values
Phase 2: Modify the DOM
Phase 3: Read some more
Phase 4: Modify the DOM somewhere else.

Before:

function paintSlow() {
  var left1 = $('#thing1').css('left');
  $('#otherThing1').css('left', left);
  var left2 = $('#thing2').css('left');
  $('#otherThing2').css('left', left);
}

After:

function paintFast() {
  var left1 = $('#thing1').css('left');
  var left2 = $('#thing2').css('left');
  $('#otherThing1').css('left', left);
  $('#otherThing2').css('left', left);
}

This advice should be considered for actions happening within one JavaScript execution context. (e.g. within an event handler, within an interval handler or when handling an ajax response.)

Executing the function paintSlow() from above creates this image:

Switching to the faster implementation yields this image:

These images show that reordering the way your code accesses the DOM can greatly enhance render performance. In this case the original code has to recalculate styles and layout the page twice to create the same result. Similar optimization can be applied to basically all "real world" code and yield some really dramatic results.

Redraws and the Event Loop #

JavaScript execution in the browser follows an "Event Loop" model. By default the browser is in an "idle" state. This state can be interrupted by events from user interactions or such things as JavaScript timers or Ajax callbacks. Whenever a piece of JavaScript runs at such an interruption point, the browser will usually wait for it to finish until it repaints the screen (There might be exceptions for extremely long running JavaScripts or in cases such as alert-boxes which effectively interrupt the JavaScript execution).

Consequences

If your JavaScript animation cycles take longer than 1/30 seconds to execute, you will not be able to create smooth animations because the browser will not repaint during the JS execution. When you expect to also handle user events you need to be much faster.
Sometimes it comes in handy to delay some JavaScript actions until just a little bit later. E.g. setTimeout(function() { ... }, 0) This effectively tells the browser to execute the callback as soon as the event loop is idle again (effectively some browsers will wait at least 10ms). You need to be aware that this will create two JavaScript execution cycles which are very close together in time. Both might trigger a repaint of the screen which might double the overall time spent with painting. Whether this actually triggers two paints depends on heuristics in the browser.

Regular version:

function paintFast() {
  var height1 = $('#thing1').css('height');
  var height2 = $('#thing2').css('height');
  $('#otherThing1').css('height', '20px');
  $('#otherThing2').css('height', '20px');
}

Lets add some delay:

function paintALittleLater() {
  var height1 = $('#thing1').css('height');
  var height2 = $('#thing2').css('height');
  $('#otherThing1').css('height', '20px');
  setTimeout(function() {
    $('#otherThing2').css('height', '20px');
  }, 10)
}

The delayed version shows that the browser paints twice although the two changes to the page are only 1/100 of a second a part.

Lazy Initialization #

Users want web apps that load fast and feel responsive. However, users have different thresholds into what they perceive as slow depending on the action that they do. E.g. an app should never do a lot of computation on a mouseover event because this might create a bad user experience while the user continues to move his mouse. However, users are used to accepting a little delay after they clicked on a button.

Thus it might make sense to move your initialization code to be executed as late as possible (e.g. when the user clicks a button that activates a particular component of your application).

Before:

var things = $('.ele > .other * div.className');
$('#button').click(function() { things.show() });

After:

$('#button').click(function() { $('.ele > .other * div.className').show() });

Event Delegation #

Spreading event handlers across a page might take a relatively long time and can also be tedious once elements are dynamically replaced which then requires reattaching event handlers to the new elements.

The solution in this case is to use a technique called event delegation. Instead of attaching individual event handlers to elements, the bubbling nature of many browser events is used by actually attaching the event handler to a parent node and checking the target node of the event to see if the event is of interest.

In jQuery this can be easily expressed as:

$('#parentNode').delegate('.button', 'click', function() { ... });

When not to use event delegation #

Sometimes the opposite can be true: You are using event delegation and you're having a performance problem. Basically event delegation allows constant-complexity initialization time. However, the price of checking if an event is of interest has to be paid for every invocation of that event. This might come in expensive, especially for events that occur frequently like "mouseover" or even "mousemove".

Typical Problems and Solutions #

The stuff I do in `$(document).ready` takes a long time #

Malte's personal advice: Never do anything in $(document).ready. Try to deliver your document in its final form. OK, you are allowed to register event listeners, but only using id-selector and/or using event delegation. For expensive events such as "mousemove", delay the registration until they are needed (mouseover event on the relevant element).

And if you really need to do stuff, such as making an Ajax request to get actual data, then show a nice animation; you might want to include the animation as a data URI if it is an animated GIF or the like.

Since I added a Flash movie to the page everything is really slow #

Adding Flash to a page will always slow down rendering a little because the final layout of the window has to be "negotiated" between the browser and the Flash plugin. When you cannot completely avoid putting Flash on your pages, make sure you set the "wmode" Flash-parameter to the value "window" (which is the default). This will disable the ability to composite HTML and Flash elements (You won't be able to see an HTML element that lies above the Flash movie and your Flash movie cannot be transparent). This might be an inconvenience but it will dramatically improve your performance. For example check out the way that youtube.com carefully avoids placing layers above the main movie player.

I'm saving things to localStorage, now my application stutters #

Writing to localStorage is a synchronous operations that involves spinning up your hard disk. You never want to do "long running" synchronous operations while doing animations. Move the access to localStorage to a spot in your code where you are sure that the user is idle and no animations are going on.

Profiling points to a jQuery selector being really slow #

First you want to make sure that your selector can be run through document.querySelectorAll. You can test that in the JavaScript console. If there is an exception rewrite your selector to not use any special extension of your JavaScript framework. This will speed up your selector in modern browsers by an order of magnitude.

If this doesn't help or if you also want to be fast in modern browsers, follow these guidelines:

Be as specific on the right side of your selector as possible.
Use a tag name that you don't use often as the rightmost selector part.
If nothing helps, think about rewriting things so you can use an id-selector

All these DOM manipulations take a long time #

A bunch of DOM node inserts, removes and updates can be really slow. This can generally be optimized by generating a large string of html and the using domNode.innerHTML = newHTML to replace the old content. Note that this might be really bad for maintainability and might create memory links in IE so be careful.

Another common problem is that your initialization code might create a lot of HTML. E.g. a jQuery plugin that transforms a select box into a bunch of divs because that is what the design people wanted in ignorance of UX best practices. If you really want your page to be fast, never do that. Instead deliver all the markup from the server side in its final form. This again has many problems so think hard whether the speed is worth the tradeoff.

Tools #

JSPerf - Benchmark little snippets of JavaScript
Firebug - For profiling in Firefox
Google Chrome Developer Tools (Available as WebInspector in Safari)
DOM Monster - For optimizing DOM performance
DynaTrace Ajax Edition - For profiling and paint optimizations in Internet Explorer

Malte Ubl on web.dev

Introducing WebSockets - Bringing Sockets to the Web

The problem: Low latency client-server and server-client connections #

Introducing WebSocket: Bringing sockets to the web #

Getting Started #

Communicating with the server #

Cross-origin communication #

Proxy servers #

Use WebSockets today #

The server side #

Server side implementations #

Protocol versions #

Use cases #

Demos #

References #

The Basics of Web Workers

The problem: JavaScript concurrency #

Introducing Web Workers: bring threading to JavaScript #

Types of Web Workers #

Getting started #

Communicating with a worker via message passing #

Transferrable objects #

The worker environment #

Worker scope #

Features available to workers #

Loading external scripts #

Subworkers #

Inline workers #

Blob URLs #

Full example #

Loading external scripts #

handling errors #

A word on security #

Restrictions with local access #

Same-origin considerations #

Use cases #

Demos #

References #

Rendering HTML5 in older browsers with Google Chrome Frame

Introduction #

What is Google Chrome Frame #

Opting in #

Prompting for Google Chrome Frame #

Prompt yourself #

No admin-rights needed #

Enterprise installation #

Adoption #

More info #

Improving the performance of your HTML5 App

Introduction #

The Strategy #

Visual fidelity++ with HTML5 #

Hardware Acceleration #

These aspects of your document can be accelerated by the GPU #

What can be accelerated? #

CSS3 Transitions #

CSS3 Translate #

window.requestAnimationFrame #

Profiling #

JavaScript Profiling #

The DOM #

Tips and Tricks #

Anonymous Functions #

Profiling long functions #

DOM Profiling #

Profiling Strategies #

Single out aspects #

GUI Profiling #

Programatic Interface #

Repeatability #

Measure, improve, measure #

Optimization Strategies #

Minimize DOM interaction #

Cache DOM Nodes #

Cache Attribute Values #

Move DOM Manipulation Out of Loops #

Redraws and Reflows #

Redraws and the Event Loop #

Lazy Initialization #

Event Delegation #

`window.requestAnimationFrame` #

The stuff I do in `$(document).ready` takes a long time #