Paul Lewis on web.dev

Avoid large, complex layouts and layout thrashing

2015-03-20T00:00:00Z

Layout is where the browser figures out the geometric information for elements: their size and location in the page. Each element will have explicit or implicit sizing information based on the CSS that was used, the contents of the element, or a parent element. The process is called Layout in Chrome (and derived browsers such as Edge), and Safari. In Firefox it's called Reflow, but the process is effectively the same.

Similarly to style calculations, the immediate concerns for layout cost are:

The number of elements that require layout, which is a byproduct of the page's DOM size.
The complexity of those layouts.

Summary #

Layout has a direct effect on interaction latency
Layout is normally scoped to the whole document.
The number of DOM elements will affect performance; you should avoid triggering layout wherever possible.
Avoid forced synchronous layouts and layout thrashing; read style values then make style changes.

The effects of layout on interaction latency #

When a user interacts with the page, those interactions should be as fast as possible. The amount of time it takes for an interaction to complete—ending when the browser presents the next frame to show the results of the interaction—is known as interaction latency. This is an aspect of page performance that the Interaction to Next Paint metric measures.

The amount of time it takes for the browser to present the next frame in response to a user interaction is known as the interaction's presentation delay. The goal of an interaction is to provide visual feedback in order to signal to the user that something has occurred, and visual updates can involve some amount of layout work in order to achieve that goal.

In order to keep your website's INP as low as possible, it's important to avoid layout when possible. If it's not possible to avoid layout entirely, it's important to limit that layout work so that the browser can present the next frame quickly.

Avoid layout wherever possible #

When you change styles the browser checks to see if any of the changes require layout to be calculated, and for that render tree to be updated. Changes to "geometric properties", such as widths, heights, left, or top all require layout.

.box {
  width: 20px;
  height: 20px;
}

/**
  * Changing width and height
  * triggers layout.
  */

.box--expanded {
  width: 200px;
  height: 350px;
}

Layout is almost always scoped to the entire document. If you have a lot of elements, it's going to take a long time to figure out the locations and dimensions of them all.

If it's not possible to avoid layout then the key is to once again use Chrome DevTools to see how long it's taking, and determine if layout is the cause of a bottleneck. Firstly, open DevTools, go to the Timeline tab, hit record and interact with your site. When you stop recording you'll see a breakdown of how your site performed:

When digging into the trace in the above example, we see that over 28 milliseconds is spent inside layout for each frame, which, when we have 16 milliseconds to get a frame on screen in an animation, is far too high. You can also see that DevTools will tell you the tree size (1,618 elements in this case), and how many nodes were in need of layout (5 in this case).

Keep in mind that the general advice here is to avoid layout whenever possible—but it isn't always possible to avoid layout. In cases where you can't avoid layout, know that the cost of layout has a relationship with the size of the DOM. Although the relationship between the two isn't tightly coupled, larger DOMs will generally incur higher layout costs.

Avoid forced synchronous layouts #

Shipping a frame to screen has this order:

First the JavaScript runs, then style calculations, then layout. It is, however, possible to force a browser to perform layout earlier with JavaScript. This is called forced synchronous layout.

The first thing to keep in mind is that as the JavaScript runs all the old layout values from the previous frame are known and available for you to query. So if, for example, you want to write out the height of an element (let's call it "box") at the start of the frame you may write some code like this:

// Schedule our function to run at the start of the frame:
requestAnimationFrame(logBoxHeight);

function logBoxHeight () {
  // Gets the height of the box in pixels and logs it out:
  console.log(box.offsetHeight);
}

Things get problematic if you've changed the styles of the box before you ask for its height:

function logBoxHeight () {
  box.classList.add('super-big');

  // Gets the height of the box in pixels and logs it out:
  console.log(box.offsetHeight);
}

Now, in order to answer the height question, the browser must first apply the style change (because of adding the super-big class), and then run layout. Only then will it be able to return the correct height. This is unnecessary and potentially expensive work.

Because of this, you should always batch your style reads and do them first (where the browser can use the previous frame's layout values) and then do any writes:

Done correctly the above function would be:

function logBoxHeight () {
  // Gets the height of the box in pixels and logs it out:
  console.log(box.offsetHeight);

  box.classList.add('super-big');
}

For the most part you shouldn't need to apply styles and then query values; using the last frame's values should be sufficient. Running the style calculations and layout synchronously and earlier than the browser would like are potential bottlenecks, and not something you will typically want to do.

Avoid layout thrashing #

There's a way to make forced synchronous layouts even worse: do lots of them in quick succession. Take a look at this code:

function resizeAllParagraphsToMatchBlockWidth () {
  // Puts the browser into a read-write-read-write cycle.
  for (let i = 0; i < paragraphs.length; i++) {
    paragraphs[i].style.width = `${box.offsetWidth}px`;
  }
}

This code loops over a group of paragraphs and sets each paragraph's width to match the width of an element called "box". It looks harmless enough, but the problem is that each iteration of the loop reads a style value (box.offsetWidth) and then immediately uses it to update the width of a paragraph (paragraphs[i].style.width). On the next iteration of the loop, the browser has to account for the fact that styles have changed since offsetWidth was last requested (in the previous iteration), and so it must apply the style changes, and run layout. This will happen on every single iteration!.

The fix for this sample is to once again read and then write values:

// Read.
const width = box.offsetWidth;

function resizeAllParagraphsToMatchBlockWidth () {
  for (let i = 0; i < paragraphs.length; i++) {
    // Now write.
    paragraphs[i].style.width = `${width}px`;
  }
}

If you want to guarantee safety, consider using FastDOM, which automatically batches your reads and writes for you, and should prevent you from triggering forced synchronous layouts or layout thrashing accidentally.

Hero image from Unsplash, by Hal Gatewood.

Reduce the scope and complexity of style calculations

2015-03-20T00:00:00Z

Changing the DOM, through adding and removing elements, changing attributes, classes, or through animation, will all cause the browser to recalculate element styles and, in many cases, layout (or reflow) the page, or parts of it. This process is called computed style calculation.

The first part of computing styles is to create a set of matching selectors, which is essentially the browser figuring out which classes, pseudo-selectors, and IDs apply to any given element.

The second part of the process involves taking all the style rules from the matching selectors and figuring out what final styles the element has.

Summary #

How reducing style calculation costs can lower interaction latency.
Reduce the complexity of your selectors; use a class-centric methodology (BEM, for example).
Reduce the number of elements on which style calculation must be calculated.

Style recalculation time and interaction latency #

The Interaction to Next Paint (INP) is a user-centric runtime performance metric that assesses a page's overall responsiveness to user input. When interaction latency is assessed by this metric, it measures the time starting from when the user interacts with the page, up until the browser paints the next frame showing the corresponding visual updates made to the user interface.

A significant component of an interaction is the time it takes to paint the next frame. Rendering work done to present the next frame is made up of many parts, including calculation of page styles that occur just prior to layout, paint, and compositing work. While this article focuses solely on style calculation costs, it's important to emphasize that reducing any part of the rendering phase inherent to interaction will reduce its total latency—style calculation included.

Reduce the complexity of your selectors #

In the simplest case, you can reference an element in your CSS with just a class:

.title {
  /* styles */
}

But, as any project grows, it will likely result in more complex CSS, such that you may end up with selectors that look like this:

.box:nth-last-child(-n+1) .title {
  /* styles */
}

In order to know how these styles apply to the page, the browser has to effectively ask "is this an element with a class of title which has a parent who happens to be the minus nth child plus 1 element with a class of box?" Figuring this out can take a lot of time, depending on the selector used as well as the browser in question. The intended behavior of the selector could instead be changed to a class:

.final-box-title {
  /* styles */
}

You can take issue with the name of the class, but the job just got a lot simpler for the browser. In the previous version, in order to know, for example, that the element is the last of its type, the browser must first know everything about all the other elements and whether the are any elements that come after it that would be the nth-last-child, which is potentially more expensive than simply matching up the selector to the element because its class matches.

Reduce the number of elements being styled #

Another performance consideration—which is typically the more important factor for many style updates—is the sheer volume of work that needs to be carried out when an element changes.

In general terms, the worst case cost of calculating the computed style of elements is the number of elements multiplied by the selector count, because each element needs to be at least checked once against every style to see if it matches.

Style calculations can often be targeted to a few elements directly rather than invalidating the page as a whole. In modern browsers, this tends to be less of an issue because the browser doesn't necessarily need to check all the elements potentially affected by a change. Older browsers, on the other hand, aren't necessarily as optimized for such tasks. Where you can, you should reduce the number of invalidated elements.

Measure your style recalculation cost #

One way to measure the cost of style recalculations is to use the performance panel in Chrome DevTools. To begin, open DevTools, go to the tab labeled Performance, hit record, and interact with the page. When you stop recording, you'll see something like the image below:

The strip at the top is a miniature flame chart that also plots frames per second. The closer the activity is to the bottom of the strip, the faster frames are being painted by the browser. If you see the flame chart leveling out at the top with red strips above it, then you have work that's causing long running frames.

If you have a long running frame during an interaction like scrolling, then it bears further scrutiny. If you have a large purple block, zoom in on the activity and select any work labeled Recalculate Style to get more information on potentially expensive style recalculation work.

In this grab there is long-running style recalculation work that is taking just over 25ms.

If you click the event itself, you are given a call stack. If the rendering work was due to a user interaction, the place in your JavaScript that is responsible for triggering the style change will be called out. In addition to that, you also get the number of elements that have been affected by the change—just over 900 elements in this case—and how long it took to do the style calculation work. You can use this information to start trying to find a fix in your code.

Use Block, Element, Modifier #

Approaches to coding like BEM (Block, Element, Modifier) actually bake in the selector matching performance benefits above, because it recommends that everything has a single class, and, where you need hierarchy, that gets baked into the name of the class as well:

.list {
  /* Styles */
}

.list__list-item {
  /* Styles */
}

If you need some modifier, like in the above where we want to do something special for the last child, you can add that like so:

.list__list-item--last-child {
  /* Styles */
}

If you're looking for a good way to organize your CSS, BEM is a good starting point, both from a structure point-of-view, and also because of the simplifications of style lookup the methodology promotes.

If you don't like BEM, there are other ways to approach your CSS, but the performance considerations should be assessed alongside the ergonomics of the approach.

Resources #

Hero image from Unsplash, by Markus Spiske.

Simplify paint complexity and reduce paint areas

2015-03-20T00:00:00Z

Paint is the process of filling in pixels that eventually get composited to the users' screens. It is often the longest-running of all tasks in the pipeline, and one to avoid if at all possible.

Summary #

Changing any property apart from transforms or opacity always triggers paint.
Paint is often the most expensive part of the pixel pipeline; avoid it where you can.
Reduce paint areas through layer promotion and orchestration of animations.
Use the Chrome DevTools paint profiler to assess paint complexity and cost; reduce where you can.

Triggering Layout And Paint #

If you trigger layout, you will always trigger paint, since changing the geometry of any element means its pixels need fixing!

You can also trigger paint if you change non-geometric properties, like backgrounds, text color, or shadows. In those cases layout won’t be needed and the pipeline will look like this:

Use Chrome DevTools to quickly identify paint bottlenecks #

You can use Chrome DevTools to quickly identify areas that are being painted. Open the Rendering tab and then enable Paint Flashing.

With this option switched on Chrome will flash the screen green whenever painting happens. If you’re seeing the whole screen flash green, or areas of the screen that you didn’t think should be painted, then you should dig in a little further.

Promote elements that move or fade #

Painting is not always done into a single image in memory. In fact, it’s possible for the browser to paint into multiple images, or compositor layers, if necessary.

The benefit of this approach is that elements that are regularly repainted, or are moving on screen with transforms, can be handled without affecting other elements. This is the same as with art packages like Sketch, GIMP, or Photoshop, where individual layers can be handled and composited on top of each other to create the final image.

The best way to create a new layer is to use the will-change CSS property. This will work in Chrome, Opera and Firefox, and, with a value of transform, will create a new compositor layer:

.moving-element {
  will-change: transform;
}

For browsers that don’t support will-change, but benefit from layer creation, such as Safari and Mobile Safari, you need to (mis)use a 3D transform to force a new layer:

.moving-element {
  transform: translateZ(0);
}

Care must be taken not to create too many layers, however, as each layer requires both memory and management. There is more information on this in the Stick to compositor-only properties and manage layer count section.

If you have promoted an element to a new layer, use DevTools to confirm that doing so has given you a performance benefit. Don't promote elements without profiling.

Reduce paint areas #

Sometimes, however, despite promoting elements, paint work is still necessary. A large challenge of paint issues is that browsers union together two areas that need painting, and that can result in the entire screen being repainted. So, for example, if you have a fixed header at the top of the page, and something being painted at the bottom of the screen, the entire screen may end up being repainted.

Note: On High DPI screens elements that are fixed position are automatically promoted to their own compositor layer. This is not the case on low DPI devices because the promotion changes text rendering from subpixel to grayscale, and layer promotion needs to be done manually.

Reducing paint areas is often a case of orchestrating your animations and transitions to not overlap as much, or finding ways to avoid animating certain parts of the page.

Simplify paint complexity #

When it comes to painting, some things are more expensive than others. For example, anything that involves a blur (like a shadow, for example) is going to take longer to paint than -- say -- drawing a red box. In terms of CSS, however, this isn’t always obvious: background: red; and box-shadow: 0, 4px, 4px, rgba(0,0,0,0.5); don’t necessarily look like they have vastly different performance characteristics, but they do.

The paint profiler above will allow you to determine if you need to look at other ways to achieve effects. Ask yourself if it’s possible to use a cheaper set of styles or alternative means to get to your end result.

Where you can you always want to avoid paint during animations in particular, as the 10ms you have per frame is normally not long enough to get paint work done, especially on mobile devices.

Debounce your input handlers

2015-03-20T00:00:00Z

Input handlers are a potential cause of performance problems in your apps, as they can block frames from completing, and can cause additional and unnecessary layout work.

Summary #

Avoid long-running input handlers; they can block scrolling.
Do not make style changes in input handlers.
Debounce your handlers; store event values and deal with style changes in the next requestAnimationFrame callback.

Avoid long-running input handlers #

In the fastest possible case, when a user interacts with the page, the page’s compositor thread can take the user’s touch input and simply move the content around. This requires no work by the main thread, where JavaScript, layout, styles, or paint are done.

If, however, you attach an input handler, like touchstart, touchmove, or touchend, the compositor thread must wait for this handler to finish executing because you may choose to call preventDefault() and stop the touch scroll from taking place. Even if you don’t call preventDefault() the compositor must wait, and as such the user’s scroll is blocked, which can result in stuttering and missed frames.

In short, you should make sure that any input handlers you run should execute quickly and allow the compositor to do its job.

Avoid style changes in input handlers #

Input handlers, like those for scroll and touch, are scheduled to run just before any requestAnimationFrame callbacks.

If you make a visual change inside one of those handlers, then at the start of the requestAnimationFrame, there will be style changes pending. If you then read visual properties at the start of the requestAnimationFrame callback, as the advice in “Avoid large, complex layouts and layout thrashing” suggests, you will trigger a forced synchronous layout!

Debounce your scroll handlers #

The solution to both of the problems above is the same: you should always debounce visual changes to the next requestAnimationFrame callback:

function onScroll (evt) {

    // Store the scroll value for laterz.
    lastScrollY = window.scrollY;

    // Prevent multiple rAF callbacks.
    if (scheduledAnimationFrame)
    return;

    scheduledAnimationFrame = true;
    requestAnimationFrame(readAndUpdatePage);
}

window.addEventListener('scroll', onScroll);

Doing this also has the added benefit of keeping your input handlers light, which is awesome because now you’re not blocking things like scrolling or touch on computationally expensive code!

Optimize JavaScript execution

2015-03-20T00:00:00Z

JavaScript often triggers visual changes. Sometimes that's directly through style manipulations, and sometimes it's calculations that result in visual changes, like searching or sorting data. Badly-timed or long-running JavaScript is a common cause of performance issues. You should look to minimize its impact where you can.

JavaScript performance profiling can be something of an art, because the JavaScript you write is nothing like the code that is actually executed. Modern browsers use JIT compilers and all manner of optimizations and tricks to try and give you the fastest possible execution, and this substantially changes the dynamics of the code.

With all that said, however, there are some things you can definitely do to help your apps execute JavaScript well.

Summary #

Avoid setTimeout or setInterval for visual updates; always use requestAnimationFrame instead.
Move long-running JavaScript off the main thread to Web Workers.
Use micro-tasks to make DOM changes over several frames.
Use Chrome DevTools’ Timeline and JavaScript Profiler to assess the impact of JavaScript.

Use `requestAnimationFrame` for visual changes #

When visual changes are happening on screen you want to do your work at the right time for the browser, which is right at the start of the frame. The only way to guarantee that your JavaScript will run at the start of a frame is to use requestAnimationFrame.

/**
    * If run as a requestAnimationFrame callback, this
    * will be run at the start of the frame.
    */
function updateScreen(time) {
    // Make visual updates here.
}

requestAnimationFrame(updateScreen);

Frameworks or samples may use setTimeout or setInterval to do visual changes like animations, but the problem with this is that the callback will run at some point in the frame, possibly right at the end, and that can often have the effect of causing us to miss a frame, resulting in jank.

In fact, jQuery used to use setTimeout for its animate behavior. It was changed to use requestAnimationFrame in version 3. If you are using older version of jQuery, you can patch it to use requestAnimationFrame, which is strongly advised.

Reduce complexity or use Web Workers #

JavaScript runs on the browser’s main thread, right alongside style calculations, layout, and, in many cases, paint. If your JavaScript runs for a long time, it will block these other tasks, potentially causing frames to be missed.

You should be tactical about when JavaScript runs, and for how long. For example, if you’re in an animation like scrolling, you should ideally be looking to keep your JavaScript to something in the region of 3-4ms. Any longer than that and you risk taking up too much time. If you’re in an idle period, you can afford to be more relaxed about the time taken.

In many cases you can move pure computational work to Web Workers, if, for example, it doesn’t require DOM access. Data manipulation or traversal, like sorting or searching, are often good fits for this model, as are loading and model generation.

var dataSortWorker = new Worker("sort-worker.js");
dataSortWorker.postMesssage(dataToSort);

// The main thread is now free to continue working on other things...

dataSortWorker.addEventListener('message', function(evt) {
    var sortedData = evt.data;
    // Update data on screen...
});

Not all work can fit this model: Web Workers do not have DOM access. Where your work must be on the main thread, consider a batching approach, where you segment the larger task into micro-tasks, each taking no longer than a few milliseconds, and run inside of requestAnimationFrame handlers across each frame.

There are UX and UI consequences to this approach, and you will need to ensure that the user knows that a task is being processed, either by using a progress or activity indicator. In any case this approach will keep your app's main thread free, helping it to stay responsive to user interactions.

Know your JavaScript’s “frame tax” #

When assessing a framework, library, or your own code, it’s important to assess how much it costs to run the JavaScript code on a frame-by-frame basis. This is especially important when doing performance-critical animation work like transitioning or scrolling.

The Performance panel of Chrome DevTools is the best way to measure your JavaScript's cost. Typically you get low-level records like this:

The Main section provides a flame chart of JavaScript calls so you can analyze exactly which functions were called and how long each took.

Armed with this information you can assess the performance impact of the JavaScript on your application, and begin to find and fix any hotspots where functions are taking too long to execute. As mentioned earlier you should seek to either remove long-running JavaScript, or, if that’s not possible, move it to a Web Worker freeing up the main thread to continue on with other tasks.

See Get Started With Analyzing Runtime Performance to learn how to use the Performance panel.

Avoid micro-optimizing your JavaScript #

It may be cool to know that the browser can execute one version of a thing 100 times faster than another thing, like that requesting an element’s offsetTop is faster than computing getBoundingClientRect(), but it’s almost always true that you’ll only be calling functions like these a small number of times per frame, so it’s normally wasted effort to focus on this aspect of JavaScript’s performance. You'll typically only save fractions of milliseconds.

If you’re making a game, or a computationally expensive application, then you’re likely an exception to this guidance, as you’ll be typically fitting a lot of computation into a single frame, and in that case everything helps.

In short, you should be very wary of micro-optimizations because they won’t typically map to the kind of application you’re building.

Rendering Performance

2015-03-20T00:00:00Z

Users of today’s web expect that the pages they visit will be interactive and smooth and that’s where you need to increasingly focus your time and effort. Pages should not only load quickly, but also run well; scrolling should be stick-to-finger fast, and animations and interactions should be silky smooth.

To write performant sites and apps you need to understand how HTML, JavaScript and CSS is handled by the browser, and ensure that the code you write (and the other 3rd party code you include) runs as efficiently as possible.

60fps and Device Refresh Rates #

Most devices today refresh their screens 60 times a second. If there’s an animation or transition running, or the user is scrolling the pages, the browser needs to match the device’s refresh rate and put up 1 new picture, or frame, for each of those screen refreshes.

Each of those frames has a budget of just over 16ms (1 second / 60 = 16.66ms). In reality, however, the browser has maintenance work to do, so all of your work needs to be completed inside 10ms. When you fail to meet this budget the frame rate drops, and the content judders on screen. This is often referred to as jank, and it negatively impacts the user's experience.

The pixel pipeline #

There are five major areas that you need to know about and be mindful of when you work. They are areas you have the most control over, and key points in the pixels-to-screen pipeline:

JavaScript. Typically JavaScript is used to handle work that will result in visual changes, whether it’s jQuery’s animate function, sorting a data set, or adding DOM elements to the page. It doesn’t have to be JavaScript that triggers a visual change, though: CSS Animations, Transitions, and the Web Animations API are also commonly used.
Style calculations. This is the process of figuring out which CSS rules apply to which elements based on matching selectors, for example, .headline or .nav > .nav__item. From there, once rules are known, they are applied and the final styles for each element are calculated.
Layout. Once the browser knows which rules apply to an element it can begin to calculate how much space it takes up and where it is on screen. The web’s layout model means that one element can affect others, for example the width of the <body> element typically affects its children’s widths and so on all the way up and down the tree, so the process can be quite involved for the browser.
Paint. Painting is the process of filling in pixels. It involves drawing out text, colors, images, borders, and shadows, essentially every visual part of the elements. The drawing is typically done onto multiple surfaces, often called layers.
Compositing. Since the parts of the page were drawn into potentially multiple layers they need to be drawn to the screen in the correct order so that the page renders correctly. This is especially important for elements that overlap another, since a mistake could result in one element appearing over the top of another incorrectly.

Each of these parts of the pipeline represents an opportunity to introduce jank, so it's important to understand exactly what parts of the pipeline your code triggers.

Sometimes you may hear the term "rasterize" used in conjunction with paint. This is because painting is actually two tasks: 1) creating a list of draw calls, and 2) filling in the pixels.

The latter is called "rasterization" and so whenever you see paint records in DevTools, you should think of it as including rasterization. (In some architectures creating the list of draw calls and rasterizing are done in different threads, but that isn't something under developer control.)

You won’t always necessarily touch every part of the pipeline on every frame. In fact, there are three ways the pipeline normally plays out for a given frame when you make a visual change, either with JavaScript, CSS, or Web Animations:

1. JS / CSS > Style > Layout > Paint > Composite #

If you change a “layout” property, so that’s one that changes an element’s geometry, like its width, height, or its position with left or top, the browser will have to check all the other elements and “reflow” the page. Any affected areas will need to be repainted, and the final painted elements will need to be composited back together.

2. JS / CSS > Style > Paint > Composite #

If you changed a “paint only” property, like a background image, text color, or shadows, in other words one that does not affect the layout of the page, then the browser skips layout, but it will still do paint.

3. JS / CSS > Style > Composite #

If you change a property that requires neither layout nor paint, and the browser jumps to just do compositing.

This final version is the cheapest and most desirable for high pressure points in an app's lifecycle, like animations or scrolling.

Note: If you want the fast track to high performance animations, read the section on changing compositor-only properties.

Performance is the art of avoiding work, and making any work you do as efficient as possible. In many cases it's about working with the browser, not against it. It’s worth bearing in mind that the work listed above in the pipeline differ in terms of computational cost; some tasks are more expensive than others!

Let’s take a dive into the different parts of the pipeline. We’ll take a look at the common issues, as well how to diagnose and fix them.

Browser Rendering Optimizations #

Performance matters to users. Web developers need to build apps that react quickly and render smoothly. Google performance guru Paul Lewis is here to help you destroy jank and create web apps that maintain 60 frames per second performance. You'll leave this course with the tools you need to profile apps and identify the causes of jank. You'll explore the browser's rendering pipeline and uncover patterns that make it easy to build performant apps.

This is a free course offered through Udacity

Take Course

Stick to Compositor-Only Properties and Manage Layer Count

2015-03-20T00:00:00Z

Compositing is where the painted parts of the page are put together for displaying on screen.

There are two key factors in this area that affect page performance: the number of compositor layers that need to be managed, and the properties that you use for animations.

Summary #

Stick to transform and opacity changes for your animations.
Promote moving elements with will-change or translateZ.
Avoid overusing promotion rules; layers require memory and management.

Use transform and opacity changes for animations #

The best-performing version of the pixel pipeline avoids both layout and paint, and only requires compositing changes:

In order to achieve this you will need to stick to changing properties that can be handled by the compositor alone. Today there are only two properties for which that is true - transforms and opacity:

The caveat for the use of transforms and opacity is that the element on which you change these properties should be on its own compositor layer. In order to make a layer you must promote the element, which we will cover next.

Promote elements that you plan to animate #

As we mentioned in the "Simplify paint complexity and reduce paint areas" section, you should promote elements that you plan to animate (within reason, don't overdo it!) to their own layer:

.moving-element {
  will-change: transform;
}

Or, for older browsers, or those that don't support will-change:

.moving-element {
  transform: translateZ(0);
}

Manage layers and avoid layer explosions #

It's perhaps tempting, then, knowing that layers often help performance, to promote all the elements on your page with something like the following:

* {
  will-change: transform;
  transform: translateZ(0);
}

Which is a roundabout way of saying that you'd like to promote every single element on the page. The problem here is that every layer you create requires memory and management, and that's not free. In fact, on devices with limited memory the impact on performance can far outweigh any benefit of creating a layer. Every layer's textures needs to be uploaded to the GPU, so there are further constraints in terms of bandwidth between CPU and GPU, and memory available for textures on the GPU.

Use Chrome DevTools to understand the layers in your app #

To get an understanding of the layers in your application, and why an element has a layer you must enable the Paint profiler in Chrome DevTools' Timeline:

With this switched on you should take a recording. When the recording has finished you will be able to click individual frames, which is found between the frames-per-second bars and the details:

Clicking on this will provide you with a new option in the details: a layer tab.

This option will bring up a new view that allows you to pan, scan and zoom in on all the layers during that frame, along with reasons that each layer was created.

Using this view you can track the number of layers you have. If you're spending a lot time in compositing during performance-critical actions like scrolling or transitions (you should aim for around 4-5ms), you can use the information here to see how many layers you have, why they were created, and from there manage layer counts in your app.

Animating Between Views

2014-08-08T00:00:00Z

Often, you want to move users between views in your application, whether that's from a list to a details view, or show a sidebar navigation. Animations between these views keep the user engaged and add even more life to your projects.

Use translations to move between views; avoid using left, top, or any other property that triggers layout.
Ensure that any animations you use are snappy and the durations are kept short.
Consider how your animations and layouts change as the screen sizes go up; what works for a smaller screen may look odd when used in a desktop context.

What these view transitions look and behave like depends on the type of views you’re dealing with. For example, animating a modal overlay on top of a view should be a different experience from transitioning between a list and details view.

Success: Try to maintain 60fps for all of your animations. That way, your users won't see stuttering animations that interfere with their experience. Ensure that any animating element has will-change set for anything you plan to change well ahead of the animation starting. For view transitions, it’s highly likely you will want to use will-change: transform.

Use translations to move between views #

To make life easier, assume that there are two views: a list view and a details view. As the user taps a list item inside the list view, the details view slides in, and the list view slides out.

To achieve this effect, you need a container for both views that has overflow: hidden set on it. That way, the two views can both be inside the container side-by-side without showing any horizontal scrollbars, and each view can slide side-to-side inside the container as needed.

The CSS for the container is:

.container {
  width: 100%;
  height: 100%;
  overflow: hidden;
  position: relative;
}

The position of the container is set as relative. This means that each view inside it can be positioned absolutely to the top left corner and then moved around with transforms. This approach is better for performance than using the left property (because that triggers layout and paint), and is typically easier to rationalize.

.view {
  width: 100%;
  height: 100%;
  position: absolute;
  left: 0;
  top: 0;

  /* let the browser know we plan to animate
     each view in and out */
  will-change: transform;
}

Adding a transition on the transform property provides a nice slide effect. To give it a nice feel, it’s using a custom cubic-bezier curve, which we discussed in the Custom Easing guide.

.view {
  transition: transform 0.3s cubic-bezier(0.465, 0.183, 0.153, 0.946);
}

The view that is offscreen should be translated to the right, so in this case the details view needs to be moved:

.details-view {
  transform: translateX(100%);
}

Now a small amount of JavaScript is necessary to handle the classes. This toggles the appropriate classes on the views.

var container = document.querySelector('.container');
var backButton = document.querySelector('.back-button');
var listItems = document.querySelectorAll('.list-item');

/**
    * Toggles the class on the container so that
    * we choose the correct view.
    */
function onViewChange(evt) {
    container.classList.toggle('view-change');
}

// When you click a list item, bring on the details view.
for (var i = 0; i < listItems.length; i++) {
    listItems[i].addEventListener('click', onViewChange, false);
}

// And switch it back again when you click the back button
backButton.addEventListener('click', onViewChange);

Finally, we add the CSS declarations for those classes.

.view-change .list-view {
  transform: translateX(-100%);
}

.view-change .details-view {
  transform: translateX(0);
}

Try it

You could expand this to cover multiple views, and the basic concept should remain the same; each non-visible view should be offscreen and brought on as needed, and the currently onscreen view should be moved off.

Caution: Making this kind of hierarchy in a cross-browser way can be challenging. For example, iOS requires an additional CSS property, -webkit-overflow-scrolling: touch, to "reenable" fling scrolling, but you don’t get to control which axis that’s for, as you can with the standard overflow property. Be sure to test your implementation across a range of devices!

In addition to transitioning between views, this technique can also be applied to other slide-in elements, like sidebar navigation elements. The only real difference is that you shouldn’t need to move the other views.

Ensure that your animation works with larger screens #

For a larger screen, you should keep the list view around all the time rather than removing it, and slide on the details view from the right-hand side. It’s pretty much the same as dealing with a navigation view.

Animations and performance

2014-08-08T00:00:00Z

Maintain 60fps whenever you are animating, because any less results in stutters or stalls that will be noticeable to your users and negatively impact their experiences.

Take care that your animations don’t cause performance issues; ensure that you know the impact of animating a given CSS property.
Animating properties that change the geometry of the page (layout) or cause painting are particularly expensive.
Where you can, stick to changing transforms and opacity.
Use will-change to ensure that the browser knows what you plan to animate.

Animating properties is not free, and some properties are cheaper to animate than others. For example, animating the width and height of an element changes its geometry and may cause other elements on the page to move or change size. This process is called layout (or reflow in Gecko-based browsers like Firefox), and can be expensive if your page has a lot of elements. Whenever layout is triggered, the page or part of it will normally need to be painted, which is typically even more expensive than the layout operation itself.

Where you can, you should avoid animating properties that trigger layout or paint. For most modern browsers, this means limiting animations to opacity or transform, both of which the browser can highly optimize; it doesn’t matter if the animation is handled by JavaScript or CSS.

Read a full guide on creating high performance animations.

Using the `will-change` property #

Browser support

Chrome 36, Supported 36
Firefox 36, Supported 36
Edge 79, Supported 79
Safari 9.1, Supported 9.1

Source

Use the will-change to ensure the browser knows that you intend to change an element’s property. This allows the browser to put the most appropriate optimizations in place ahead of when you make the change. Don't overuse will-change, however, because doing so can cause the browser to waste resources, which in turn causes even more performance issues.

The general rule of thumb is that if the animation might be triggered in the next 200ms, either by a user’s interaction or because of your application’s state, then having will-change on animating elements is a good idea. For most cases, then, any element in your app’s current view that you intend to animate should have will-change enabled for whichever properties you plan to change. In the case of the box sample we’ve been using throughout the previous guides, adding will-change for transforms and opacity looks like this:

.box {
  will-change: transform, opacity;
}

Now the browsers that support it, currently most modern browsers, will make the appropriate optimizations under the hood to support changing or animating those properties.

CSS vs JavaScript performance #

There are many pages and comments threads around the web that discuss the relative merits of CSS and JavaScript animations from a performance perspective. Here are a few points to keep in mind:

CSS-based animations, and Web Animations where supported natively, are typically handled on a thread known as the "compositor thread". This is different from the browser's "main thread", where styling, layout, painting, and JavaScript are executed. This means that if the browser is running some expensive tasks on the main thread, these animations can keep going without being interrupted.
Other changes to transforms and opacity can, in many cases, also be handled by the compositor thread.
If any animation triggers paint, layout, or both, the "main thread" will be required to do work. This is true for both CSS- and JavaScript-based animations, and the overhead of layout or paint will likely dwarf any work associated with CSS or JavaScript execution, rendering the question moot.

Animating Modal Views

2014-08-08T00:00:00Z

Try it

Modal views are for important messages, and for which you have very good reasons to block the user interface. Use them carefully, because they're disruptive and can easily ruin the user’s experience if overused. But, in some circumstances, they’re the right views to use, and adding some animation will bring them to life.

Use modal views sparingly; users get frustrated if you interrupt their experience unnecessarily.
Adding scale to the animation gives a nice "drop on" effect.
Get rid of the modal view quickly when the user dismisses it. However, bring the modal view onto the screen a little more slowly so that it doesn't surprise the user.

The modal overlay should be aligned to the viewport, so set its position to fixed:

.modal {
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;

  pointer-events: none;
  opacity: 0;

  will-change: transform, opacity;
}

It has an initial opacity of 0, so it's hidden from view, but then it also needs pointer-events set to none so that clicks and touches pass through. Without that, it blocks all interactions, rendering the whole page unresponsive. Finally, because it animates its opacity and transform, those need to be marked as changing with will-change (see also Using the will-change property).

When the view is visible, it needs to accept interactions and have an opacity of 1:

.modal.visible {
  pointer-events: auto;
  opacity: 1;
}

Now whenever the modal view is required, you can use JavaScript to toggle the "visible" class:

modal.classList.add('visible');

At this point, the modal view appears without any animation, so you can now add that in (see also Custom Easing):

.modal {
  transform: scale(1.15);

  transition:
    transform 0.1s cubic-bezier(0.465, 0.183, 0.153, 0.946),
    opacity 0.1s cubic-bezier(0.465, 0.183, 0.153, 0.946);
}

Adding scale to the transform makes the view appear to drop onto the screen slightly, which is a nice effect. The default transition applies to both transform and opacity properties with a custom curve and a duration of 0.1 seconds.

The duration is pretty short, though, but it's ideal for when the user dismisses the view and wants to get back to your app. The downside is that it’s probably too aggressive for when the modal view appears. To fix this, override the transition values for the visible class:

.modal.visible {
  transform: scale(1);

  transition:
    transform 0.3s cubic-bezier(0.465, 0.183, 0.153, 0.946),
    opacity 0.3s cubic-bezier(0.465, 0.183, 0.153, 0.946);
}

Now the modal view takes 0.3 seconds to come onto the screen, which is a bit less aggressive, but it is dismissed quickly, which the user will appreciate.

Custom easing

2014-08-08T00:00:00Z

Sometimes you won't want to use the easing keywords that are included with CSS, or you will be using Web Animations or a JavaScript framework. In these cases, you can typically define your own curves (or equations), and this provides a lot of control over the feel of your project's animations.

Summary #

Custom easing allows you to give more personality to your projects.
You can create cubic Bézier curves that resemble the default animation curves (ease-out, ease-in, etc.), but with emphasis in different places.
Use JavaScript when you need more control over the animation timing and behavior, for example, elastic or bounce animations.

If you're animating with CSS, you'll find that you can define cubic Bézier curves to define the timing. In fact, the keywords ease, ease-in, ease-out, and linear map to predefined Bézier curves, which are detailed in the CSS transitions specification and the Web Animations specification.

These Bézier curves take four values, or two pairs of numbers, with each pair describing the X and Y coordinates of a cubic Bézier curve’s control points. The starting point of the Bézier curve has coordinates (0, 0) and the ending point has coordinates (1, 1); you get to set the X and Y values of the two control points. The X values for the two control points must be between 0 and 1, and each control point’s Y value can exceed the [0, 1] limit, although the spec isn’t clear by how much.

Changing the X and Y value of each control point gives you a vastly different curve, and therefore a vastly different feel to your animation. For example, if the first control point is in the lower right area, the animation will be slow to start. If it’s in the top left area, it’s going to be fast to start. Conversely, if the second control point is in the bottom right area of the grid, it’s going to be fast at the end; if it’s in the top left, it will be slow to end.

For comparison, here are two curves: a typical ease-in-out curve and a custom curve:

See an animation with custom easing

The CSS for the custom curve is:

transition: transform 500ms cubic-bezier(0.465, 0.183, 0.153, 0.946);

The first two numbers are the X and Y coordinates of the first control point, and the second two numbers are the X and Y coordinates of the second control point.

Making a custom curve is a lot of fun, and it gives you significant control over the feel of the animation. For example, given the above curve, you can see that the curve resembles a classic ease-in-out curve, but with a shortened ease-in, or "getting started," portion, and an elongated slowdown at the end.

Experiment with this animation curve tool and see how the curve affects the feel of an animation.

Use JavaScript frameworks for more control #

Sometimes you need even more control than a cubic Bézier curve can provide. If you wanted an elastic bounce feel, you might consider using a JavaScript framework, because this is a difficult effect to achieve with either CSS or Web Animations.

TweenMax #

One powerful framework is GreenSock’s TweenMax (or TweenLite if you want to keep things really lightweight), because you get a lot of control from it in a small JavaScript library, and it’s a very mature codebase.

See an elastic ease animation

To use TweenMax, include this script in your page:

    <script src="https://cdnjs.cloudflare.com/ajax/libs/gsap/latest/TweenMax.min.js"></script>

After the script is in place, you can call TweenMax against your element and tell it which properties you’d like, along with any easing you’d like. There are many easing options that you can use; the code below uses an elastic ease-out:

    var box = document.getElementById('my-box');
    var animationDurationInSeconds = 1.5;

    TweenMax.to(box, animationDurationInSeconds, {
      x: '100%',
      ease: 'Elastic.easeOut'
    });

The TweenMax documentation highlights all the options you have here, so it's well worth a read.

The Basics of easing

2014-08-08T00:00:00Z

Nothing in nature moves linearly from one point to another. In reality, things tend to accelerate or decelerate as they move. Our brains are wired to expect this kind of motion, so when animating, you should use this to your advantage. Natural motion makes your users feel more comfortable with your apps, which in turn leads to a better overall experience.

Summary #

Easing makes your animations feel more natural.
Choose ease-out animations for UI elements.
Avoid ease-in or ease-in-out animations unless you can keep them short; they tend to feel sluggish to end users.

In classic animation, the term for motion that starts slowly and accelerates is "slow in," and for motion that starts quickly and decelerates is "slow out." The terminology most commonly used on the web for these are “ease in” and “ease out,” respectively. Sometimes the two are combined, which is called "ease in out." Easing, then, is really the process of making the animation less severe or pronounced.

Easing keywords #

CSS transitions and animations both let you choose the kind of easing you want to use for your animations. You can use keywords that affect the easing (or timing, as it's sometimes called) of the animation in question. You can also go completely custom with your easing, which gives you a lot more freedom to express your app's personality.

Here are some of the keywords that you can use in CSS:

linear
ease-in
ease-out
ease-in-out

Source: CSS Transitions, W3C

You can also use a steps keyword, which allows you to create transitions that have discrete steps, but the keywords listed above are the most useful for creating animations that feel natural.

Linear animations #

Animations without any kind of easing are referred to as linear. A graph of a linear transition looks like this:

As time moves along, the value increases in equal amounts. With linear motion, things tend to feel robotic and unnatural, and this is something that users find jarring. Generally speaking, you should avoid linear motion.

Whether you’re coding your animations using CSS or JavaScript, you’ll find that there is always an option for linear motion.

See a linear animation

To achieve the effect above with CSS, the code would look something like this:

transition: transform 500ms linear;

Ease-out animations #

Easing out causes the animation to start more quickly than linear ones, and it also has deceleration at the end.

Easing out is typically the best for user interface work, because the fast start gives your animations a feeling of responsiveness, while still allowing for a natural slowdown at the end.

See an ease-out animation

There are many ways to achieve an ease out effect, but the simplest is the ease-out keyword in CSS:

transition: transform 500ms ease-out;

Ease-in animations #

Ease-in animations start slowly and end fast, which is the opposite of ease-out animations.

This kind of animation is like a heavy stone falling, where it starts slowly and hits the ground quickly with a deadening thump.

From an interaction point of view, however, ease-ins can feel a little unusual because of their abrupt end; things that move in the real world tend to decelerate rather than simply stopping suddenly. Ease-ins also have the detrimental effect of feeling sluggish when starting, which negatively impacts the perception of responsiveness in your site or app.

See an ease-in animation

To use an ease-in animation, similarly to ease-out and linear animations, you can use its keyword:

transition: transform 500ms ease-in;

Ease-in-out animations #

Easing both in and out is akin to a car accelerating and decelerating and, used judiciously, can provide a more dramatic effect than just easing out.

Do not use an overly long animation duration, because of the sluggishness of an ease-in start to the animation. Something in the range of 300-500ms is typically suitable, but the exact number depends heavily on the feel of your project. That said, because of the slow start, fast middle, and slow end, there is increased contrast in the animation, which can be quite satisfying for users.

See an ease-in-out animation

To get an ease-in-out animation, you can use the ease-in-out CSS keyword:

transition: transform 500ms ease-in-out;

CSS versus JavaScript animations

2014-08-08T00:00:00Z

There are two primary ways to create animations on the web: with CSS and with JavaScript. Which one you choose really depends on the other dependencies of your project, and what kinds of effects you're trying to achieve.

Summary #

Use CSS animations for simpler "one-shot" transitions, like toggling UI element states.
Use JavaScript animations when you want to have advanced effects like bouncing, stop, pause, rewind, or slow down.
If you choose to animate with JavaScript, use the Web Animations API or a modern framework that you're comfortable with.

Most basic animations can be created with either CSS or JavaScript, but the amount of effort and time differs (see also CSS vs JavaScript Performance). Each has its pros and cons, but these are good guidelines:

Use CSS when you have smaller, self-contained states for UI elements. CSS transitions and animations are ideal for bringing a navigation menu in from the side, or showing a tooltip. You may end up using JavaScript to control the states, but the animations themselves will be in your CSS.
Use JavaScript when you need significant control over your animations. The Web Animations API is the standards-based approach, available today in most modern browsers. This provides real objects, ideal for complex object-oriented applications. JavaScript is also useful when you need to stop, pause, slow down, or reverse your animations.
Use requestAnimationFrame directly when you want to orchestrate an entire scene by hand. This is an advanced JavaScript approach, but can be useful if you're building a game or drawing to an HTML canvas.

Alternatively, if you're already using a JavaScript framework that includes animation functionality, such as via jQuery's .animate() method or GreenSock's TweenMax, then you may find it more convenient overall to stick with that for your animations.

Animate with CSS #

Animating with CSS is the simplest way to get something moving on screen. This approach is described as declarative, because you specify what you'd like to happen.

Below is some CSS that moves an element 100px in both the X and Y axes. It's done by using a CSS transition that's set to take 500ms. When the move class is added, the transform value is changed and the transition begins.

.box {
  transform: translate(0, 0);
  transition: transform 500ms;
}

.box.move {
  transform: translate(100px, 100px);
}

Try it

Besides the transition's duration, there are options for the easing, which is essentially how the animation feels. For more information about easing, see The Basics of Easing guide.

If, as in the above snippet, you create separate CSS classes to manage your animations, you can then use JavaScript to toggle each animation on and off:

box.classList.add('move');

Doing this provides a nice balance to your apps. You can focus on managing state with JavaScript, and simply set the appropriate classes on the target elements, leaving the browser to handle the animations. If you go down this route, you can listen to transitionend events on the element, but only if you’re able to forego support for older versions of Internet Explorer; version 10 was the first version to support these events. All other browsers have supported the event for some time.

The JavaScript required to listen for the end of a transition looks like this:

var box = document.querySelector('.box');
box.addEventListener('transitionend', onTransitionEnd, false);

function onTransitionEnd() {
    // Handle the transition finishing.
}

In addition to using CSS transitions, you can also use CSS animations, which allow you to have much more control over individual animation keyframes, durations, and iterations.

You can, for example, animate the box in the same way with transitions, but have it animate without any user interactions like clicking, and with infinite repetitions. You can also change multiple properties at the same time.

.box {
  animation-name: movingBox;

  animation-duration: 1300ms;

  animation-iteration-count: infinite;

  animation-direction: alternate;
}

@keyframes movingBox {
  0% {
    transform: translate(0, 0);
    opacity: 0.3;
  }

  25% {
    opacity: 0.9;
  }

  50% {
    transform: translate(100px, 100px);
    opacity: 0.2;
  }

  100% {
    transform: translate(30px, 30px);
    opacity: 0.8;
  }
}

Try it

With CSS animations you define the animation itself independently of the target element, and use the animation-name property to choose the required animation.

If you want your CSS animations to work on older browsers, you will need to add vendor prefixes. Many tools can help you create the prefixed versions of the CSS you need, allowing you to write the unprefixed version in your source files.

Animate with JavaScript and the Web Animations API #

Creating animations with JavaScript is, by comparison, more complex than writing CSS transitions or animations, but it typically provides developers significantly more power. You can use the Web Animations API to either animate specific CSS properties or build composable effect objects.

JavaScript animations are imperative, as you write them inline as part of your code. You can also encapsulate them inside other objects. Below is the JavaScript that you would need to write to re-create the CSS transition described earlier:

var target = document.querySelector('.box');
var player = target.animate([
    {transform: 'translate(0)'},
    {transform: 'translate(100px, 100px)'}
], 500);
player.addEventListener('finish', function() {
    target.style.transform = 'translate(100px, 100px)';
});

By default, Web Animations only modify the presentation of an element. If you'd like to have your object remain at the location it has moved to, then you should modify its underlying styles when the animation has finished, as per our sample.

Try it

The Web Animations API is a relatively new standard from the W3C. It is supported natively in most modern browsers. For non-supporting modern browsers, a polyfill is available.

With JavaScript animations, you're in total control of an element's styles at every step. This means you can slow down animations, pause them, stop them, reverse them, and manipulate elements as you see fit. This is especially useful if you're building complex, object-oriented applications, because you can properly encapsulate your behavior.

Asymmetric animation timing

2014-08-08T00:00:00Z

Asymmetric animation timing improves the user experience by allowing you to express personality while at the same time respond quickly to user interactions. It also provides contrast to the feel, which makes the interface more visually appealing.

Use asymmetric animation timing to add personality and contrast to your work.
Always favor the user's interaction; use shorter durations when responding to taps or clicks, and reserve longer durations for times when you aren't.

Like most "rules" of animation, you should experiment to find out what works for your application, but when it comes to the user experience, users are notoriously impatient. The rule of thumb is to always respond to a user interaction quickly. That said, most of the time the user's action is asymmetric, and therefore the animation can be, too.

For example, when a user taps to display a sidebar navigation, you should display it as quickly as possible, with a duration of around 100ms. When the user dismisses the menu, however, you can afford to animate the view out a little more slowly, say, around the 300ms mark.

By contrast, when you bring on a modal view, this is normally to display an error or some other critical message. In such cases, you will want to bring on the view a little more slowly, again around the 300ms mark, but dismissal, which the user triggers, should happen very quickly.

The general rule of thumb, then, is the following:

For UI animations triggered by a user’s interaction, such as view transitions or showing an element, have a fast intro (short duration), but a slow outro (longer duration).
For UI animations triggered by your code, such as errors or modal views, have a slower intro (longer duration), but a fast outro (short duration).

Choosing the right easing

2014-08-08T00:00:00Z

Having discussed the various options available for easing in animations, what kind should you use in your projects, and what kind of durations should your animations have?

Summary #

Use ease-out animations for UI elements; a Quintic ease-out is a very nice, albeit quick, ease.
Be sure to use the animation duration; ease-outs and ease-ins should be 200ms-500ms, whereas bounces and elastic eases should clock in a longer duration of 800ms-1200ms.

Generally speaking, an ease-out will be the right call, and certainly a good default. It is quick to start, giving your animations a feeling of responsiveness, which is desirable, but with a nice slowdown at the end.

There is a group of well-known ease-out equations beyond the one specified with the ease-out keyword in CSS, which range in their "aggressiveness." For a fast ease-out effect, consider a Quintic ease-out.

See a Quintic ease-out animation

Other easing equations, particularly bounces or elastic eases, should be used sparingly, and only when it’s appropriate to your project. There are few things that bring a user out of an experience like a jarring animation. If your project isn’t intended to be fun, then don’t have elements bouncing around the UI. Conversely, if you’re creating a site that is supposed to be lighthearted, then by all means use bounces!

Play around with eases, see which ones match your project’s personality, and go from there. For a full list of easing types, along with demos, see easings.net.

Pick the right animation duration #

It is important that any animation added to your project has the correct duration. Too short and the animation will feel aggressive and sharp; too long and it will be obstructive and annoying.

Ease-outs: around 200ms-500ms. This gives the eye a chance to see the animation, but it doesn’t feel obstructive.
Ease-ins: around 200ms-500ms. Bear in mind that it will jolt at the end, and no amount of timing changes will soften that impact.
Bounce or elastic effects: around 800ms-1200ms. You need to allow time for the elastic or bounce effect to "settle." Without this extra time, the elastic bouncing part of the animation will be aggressive and unpleasant to the eye.

Of course, these are just guidelines. Experiment with your own eases and choose what feels right for your projects.

Canvas inspection using Chrome DevTools

2013-09-16T00:00:00Z

Introduction #

It doesn’t matter if you’re using a 2D or WebGL context, anyone who has ever worked with the <canvas> element knows that it can be extremely difficult to debug. Working with a canvas usually involves a long and difficult-to-follow list of calls:

function draw() {

  context.clearRect(0, 0, 258, 258);
  context.fillStyle = "#EEEEEE";
  context.beginPath();
  context.arc(129, 129, 127, 0, 6.28, true);
  context.closePath();
  context.fill();

  // … and on and on
}

Sometimes you want to capture the instructions sent to a canvas context and step through them one by one. Fortunately there is a new Canvas Inspection feature in Chrome’s DevTools that lets us do just that!

In this article I will be showing you how to use this feature to start debugging your canvas work. The inspector supports both 2D and WebGL contexts, so no matter which one you're using, you should be able to get useful debugging information straight away.

Getting Started #

To get started, go to about:flags in Chrome and toggle on “Enable Developer Tools experiments”

Figure 1 - Enabling Developer Tools Experiments in about:flags

Next, head over to DevTools and hit the cog in the lower right corner. From there you can go to Experiments and enable Canvas inspection:

Figure 2 - Enabling Canvas inspection in DevTools’ experiments

For the changes to take effect, you need to close and reopen DevTools (you can use Alt+R or Option+R, a handy alternative).

When DevTools reopens, go to the Profiles section and you'll see a new Canvas Profiler option.

To begin with you will notice that the Canvas Profiler is disabled. Once you have a page that contains a canvas you want to debug simply press Enable and the page will reload ready to capture the <canvas> calls:

Figure 3 - Switching on the Canvas Profiler

You’ll need to decide whether you would like to capture a single frame, or consecutive frames, where a frame is exactly the same as you would see in the DevTools Timeline.

Single frame captures the calls until the end of the current frame then stops. Consecutive frames, on the other hand, captures all frames of all <canvas> elements until you tell it to stop. Which mode you choose depends on how you're using the <canvas> element. For an ongoing animation, you might want to capture a single frame. For a brief animation that occurs in response to a user event, you may need to capture consecutive frames.

Figure 4 - Choosing how many frames to capture

With that we’re all set up and ready to start capturing!

Capturing frames #

To capture you simply press Start and then interact with your application as you normally would. After some time head back over to DevTools and, if you’re capturing consecutively, press Stop.

Now you have a shiny new profile in the list on the left, complete with the number of captured context calls across all <canvas> elements. Click on the profile and you’ll see a screen that looks something like this:

Figure 5 - A canvas profile in DevTools

In the lower pane you’ll see a list of all the captured frames you can step through and, as you click on each, the screenshot at the top will show you the <canvas> element’s state at the end of that frame. If you have multiple <canvas> elements you can choose which one is shown using the menu just below the screenshot.

Figure 6 - Choosing your canvas context

Inside the frame you will see draw call groups. Each draw call group contains a single draw call, which will be the last call in the group. So what’s a draw call? For a 2D context that would be things like clearRect(), drawImage(), fill(), stroke(), putImageData() or any text rendering functions, and for WebGL it would be clear(), drawArrays() or drawElements(). It’s essentially anything that would change the current drawing buffer’s contents. (If you’re not into graphics you can think of a buffer as a bitmap with pixels that we're manipulating.)

Now all you do is step through the list. You can do that at the frame, draw call group or call level. Whichever way you choose to step through the list (and there are buttons just below the screenshot that help you navigate quickly) you’ll see the context at that point, meaning you can quickly find and fix bugs as they crop up.

Figure 7 - navigation buttons for convenient list hopping

Spot the difference #

Another useful feature is the ability to see which properties and variables have changed between two calls.

To see that you simply click on the sidebar button () and a new view will pop out. As you step through the draw calls you will see the properties that have been updated. Any buffers or arrays will display their contents if you hover over them.

Be heard! #

So now you know how to debug your canvas work in Chrome’s DevTools. If you have feedback on the Canvas Profiler tool, please do file a bug or post to the Chrome DevTools Group. Let us know if you find any bugs or if there’s anything else you would like to see when inspecting a <canvas>, because it’s really only through developer use and feedback that Chrome’s tools get better.

Antialiasing 101

2013-06-28T00:00:00Z

Introduction #

Antialiasing is something of an unsung hero in web graphics; it’s the reason we have clear text and smooth vector shapes on our screens. There are actually a couple of approaches to antialiasing used in browsers today which are most obvious when it comes to text rendering. When the algorithm used for antialising switches it can lead to unexpected visual results. In this article we’ll take a look at the approaches to antialiasing and see how the pixels get drawn.

All of our screens are made up, as we all know, of pixels. It’s a giant grid of blocks, and each one contains red, green and blue (RGB) components. At a distance we see images, text and icons, but up close we can actually see the grid of RGB components and how everything is made up.

Figure 1 - Pixels of a screen up close. Each pixel has red, green and blue components.

Antialiasing #

So what happens when we’re drawing a vector shape and it passes through “part” of a pixel? Let’s assume that the shape we’re drawing is black and the background is white. Should we color that pixel at all? If we color it, what color should it be? Black, gray, something else?

The process of antialiasing determines which color we should use when we’re filling in pixels. The simplest version of it is called grayscale antialiasing, and it treats the three components of the pixels equally. So if the pixel is half covered - and let's assume black text on white for a second to keep it simple - you'd think each component will be set to half brightness (I know I certainly did), but actually it's more complex than that: you have to account for gamma, which means you'll likely never set it to that exact value. That of course makes things a little trickier, but since this is an introduction to the topic I won't dive into that here. The important thing to know is that grayscale antialiasing is dealt with at the pixel level and we can, in fact, do much better.

Figure 2 - Antialiased vs hard edges

In Figure 2 you can see the same triangle being drawn, but on the left it has antialiasing enabled and on the right it’s been disabled. As you can see, when antialiasing is enabled the pixels are shades of gray when the triangle only passes through part of the pixel. When disabled, however, the pixel is filled in as either solid black or solid white and the shape looks jagged.

Text Rendering #

Whenever a browser is rendering text, which is essentially a vector shape, we will come up against the same problem: the characters of text will only partially fill some pixels so we will want to have a strategy for how to fill in those pixels. Ideally we want the text to be antialiased as it will make it easier and more pleasant to read.

It turns out, however, that the grayscale approach to antialiasing is only one way to handle it. An approach that is often taken is to be a bit more selective with how we enable the RGB components of the pixels. The process is called subpixel antialiasing and over the years the ClearType team at Microsoft in particular have invested a great deal of time and effort to make progress on it. It’s now much more widely used, and all the major browsers use it to a greater or lesser degree.

Firstly, since we know that each pixel is in fact made up of separate red, green and blue components we detect how much of each of those components should be “switched on” for the pixel in question. So if a pixel is “half covered” from the left hand side then we might switch on the red component totally, the green component to half way, and keep the blue switched off. This process is often described as “tripling the horizontal resolution of the screen”, and relies on the fact that each pixel is really the three separate components side by side rather than a single unit.

Figure 3 - Antialiasing using grayscale vs subpixel

In figure 3 above you can see that on the left we treat each component equally and each is turned on or off equally (grayscale). On the right hand side, however, we use the subpixel approach, enabling each component (red, green and blue) differently depending on how much it overlaps with the shape being drawn.

With all that said, however, human vision doesn’t actually weigh red, green and blue light equally. We are far more sensitive to green than either red or blue, and this means that while there is definite benefit over grayscale antialiasing, as Darel Rex Finley notes, enabling each component separately is not actually going to yield a 3x improvement in clarity. Subpixel antialiasing is definitely helpful, though, and it does mean that we see text more clearly than if grayscale antialiasing is used.

Figure 4 - Subpixel antialiased text. Individual components of the pixels are enabled to create the overall effect

Cutting to the chase #

What does all this mean for us as developers? Well, from a Chrome perspective at least there is a mix of both grayscale and subpixel antialiasing used to render text, and which one you get depends on a few criteria. To begin with, however, we need to understand a little about layers, since that’s the main criterion at play. If you’ve not come across layers and how they are used internally by Chrome, Tom Wiltzius has written a fantastic introduction to the topic that you should read first.

Assuming you’re familiar with layers, or you’ve just read about them, let’s continue on. If hardware compositing is enabled for the page, and you have text content on a layer that isn’t the root layer it will, by default, be rendered using grayscale antialiasing. Developers often notice that if they apply hacks to elements to get them into their own (non-root) layers (such as using translateZ) that they see text being rendered differently. Often times developers apply “new layer” triggers on the fly through JavaScript or CSS causing the text rendering to switch from subpixel to grayscale; it can be confusing if you don’t know what triggered the rendering change. If your text resides in the root layer, however, it should be rendered with subpixel antialiasing, and consequently it will be much clearer to read.

But, like all things web, it’s changing. Subpixel antialiasing is being enabled in Chrome for text in non-root layers, provided the layer satisfies three criteria. It’s worth saying that these criteria apply today, but it’s likely they will change and you should expect to see more cases covered over time. Today those criteria are:

The layer has a fully opaque background color. Notably using border-radius or a non-default background-clip value results in the layer being treated as non-opaque and text rendering reverts to grayscale antialiasing.
The layer can only have either identity transform or integral translation applied to it. By integral we mean rounded values. So for example translate(20.2px, 30px) would result in grayscale antialiasing since the x component, 20.2px, is non-integral. The identity transform simply means that there is no additional rotation, translation, or scaling applied beyond its default.
The layer has an opacity of 1.0. Any change in opacity will change the antialiasing from subpixel to grayscale.

Figure 5 - Before and after: grayscale vs. subpixel. Note the color edging on the text to the right

One final thing of note is that applying a CSS animation may cause a new layer to be created, whereas using requestAnimationFrame does not. For some developers the text rendering differences that implies has precluded the use of CSS animations. So if you’ve been using JavaScript to animate elements because of text rendering differences, check to see if this update fixes things for you!

So that’s Chrome covered. As far as other browsers go, Opera, as it moves to Chromium, should match Chrome’s behaviours closely. Internet Explorer seems to use subpixel antialiasing for virtually all text (if you’ve enabled ClearType, of course!), although seemingly not in Windows 8’s Metro mode. Safari, given WebKit’s proximity to Blink, behaves very similarly to Chrome, albeit without these newer improvements that allow for more subpixel antialiasing. Firefox largely behaves in the same way as Internet Explorer insofar as it uses subpixel antialiasing for virtually all text. Of course this isn’t an exhaustive list, and there are likely to be cases in all browsers where grayscale antialiasing is used instead of subpixel, but it’s good to know that subpixel antialiasing is widely used across the main set of browsers.

Conclusion #

So now you know a little about how antialiasing works, and why you might see text rendering differences in your sites and applications today, especially on lower DPI devices. If you’re interested in following along with Chrome’s implementation with respect to text rendering you should star the following bugs:

Resources and references #

Avoiding unnecessary paints

2013-05-08T00:00:00Z

Introduction #

Painting the elements for a site or application can get really expensive, and it can have a negative knock-on effect on our runtime performance. In this article we take a quick look at what can trigger painting in the browser, and how you can prevent unnecessary paints from taking place.

Painting: A super-quick tour #

One of the major tasks a browser has to perform is converting your DOM and CSS into pixels on the screen, and it does this through a fairly complex process. It starts by reading the markup and from this it creates a DOM tree. It does a similar thing with the CSS and from that it creates the CSSOM. The DOM and CSSOM are then combined and, eventually, we arrive at a structure from which we can start to paint some pixels.

The painting process itself is interesting. In Chrome that combined tree of DOM and CSS is rasterized by some software called Skia. If you've ever played with the canvas element Skia's API would look awfully familiar to you; there are many moveTo- and lineTo-style functions as well as a bunch of more advanced ones. Essentially all the elements that need to be painted are distilled to a collection of Skia calls that can be executed, and the output of is a bunch of bitmaps. These bitmaps are uploaded to the GPU, and the GPU helps out by compositing them together to give us the final picture on screen.

The thing to take away is that Skia's workload is directly affected by the styles you apply to your elements. If you use algorithmically heavy styles then Skia is going to have more work to do. Colt McAnlis has written an article on how CSS affects page render weight, so you should read that for more insight.

With all that said, paint work takes time to perform, and if we don’t reduce it we will run over our frame budget of ~16ms. Users will notice that we missed frames and see it as jank, which ultimately hurts the user experience of our app. We really don’t want that, so let’s see what kinds of things cause paint work to be necessary, and what we can do about it.

Scrolling #

Whenever you scroll up or down in the browser it needs to repaint content before it appears onscreen. All being well that will just be a small area, but even if that’s the case the elements that need to be drawn could have complex styles applied. So just because you have a small area to paint doesn't mean it's going to happen quickly.

In order to see what areas are being repainted you can use the “Show Paint Rectangles” feature in Chrome’s DevTools (just hit the little cog in the lower right corner). Then, with DevTools open, simply interact with your page and you’ll see flashing rectangles show where and when Chrome painted a part of your page.

Show Paint Rectangles in Chrome DevTools

Scrolling performance is critical to your site's success; users really notice when your site or application doesn't scroll well, and they don't like it. We therefore have a vested interest in keeping the paint work light during scrolls so users don't see jank.

I've previously written an article on scrolling performance, so take a look at that if you want to know more about the specifics of scrolling performance.

Interactions #

Interactions are another cause of paint work: hovers, clicks, touches, drags. Whenever the user performs one of those interactions, let's say a hover, then Chrome will have to repaint the affected element. And, much as with scrolling, if there's a large and complex paint required you're going to see the frame rate drop.

Everyone wants nice, smooth, interaction animations, so again we will need to see if the styles that change in our animation are costing us too much time.

An unfortunate combination #

A demo with expensive paints

What happens if I scroll and I happen to move the mouse at the same time? It's perfectly possible for me to inadvertently "interact" with an element as I scroll past it, triggering an expensive paint. That, in turn, could push me through my frame budget of ~16.7ms (the time we need to stay under that to hit 60 frames per second). I've created a demo to show you exactly what I mean. Hopefully as you scroll and move your mouse you'll see the hover effects kicking in, but let's see what Chrome's DevTools makes of it:

Chrome's DevTools showing expensive frames

In the image above you can see that DevTools is registering the paint work when I hover on one of the blocks. I've gone with some super heavy styles in my demo to make the point, and so I'm pushing up to and occasionally through my frame budget. The last thing I want is to have to do this paint work unnecessarily, and especially so during a scroll when there's other work to be done!

So how can we stop this from happening? As it happens the fix is pretty simple to implement. The trick here is to attach a scroll handler that will disable hover effects and set a timer for enabling them again. That means we are guaranteeing that when you scroll we won't need to perform any expensive interaction paints. When you've stopped for long enough we figure it's safe to switch them back on again.

Here's the code:

// Used to track the enabling of hover effects
var enableTimer = 0;

/*
 * Listen for a scroll and use that to remove
 * the possibility of hover effects
 */
window.addEventListener('scroll', function() {
  clearTimeout(enableTimer);
  removeHoverClass();

  // enable after 1 second, choose your own value here!
  enableTimer = setTimeout(addHoverClass, 1000);
}, false);

/**
 * Removes the hover class from the body. Hover styles
 * are reliant on this class being present
 */
function removeHoverClass() {
  document.body.classList.remove('hover');
}

/**
 * Adds the hover class to the body. Hover styles
 * are reliant on this class being present
 */
function addHoverClass() {
  document.body.classList.add('hover');
}

As you can see we use a class on the body to track whether or not hover effects are "allowed", and the underlying styles rely on this class to be present:

/* Expect the hover class to be on the body
 before doing any hover effects */
.hover .block:hover {
 …
}

And that's all there is to it!

Conclusion #

Rendering performance is critical to users enjoying your application, and you should always aim to keep your paint workload under 16ms. To help you do that, you should integrate using DevTools throughout your development process to identify and fix bottlenecks as they arise.

Inadvertent interactions, particularly on paint-heavy elements, can be very costly and will kill rendering performance. As you've seen, we can use a small piece of code to fix that.

Take a look at your sites and applications, could they do with a little paint protection?

High DPI Canvas

2012-08-25T00:00:00Z

Introduction #

HiDPI screens are lovely, they make everything look smoother and cleaner. But they also present a new set of challenges to developers. In this article we are going to take a look into the unique challenges of drawing images in the canvas in the context of HiDPI screens.

The devicePixelRatio property #

Let's start at the beginning. Back before we had HiDPI screens a pixel was a pixel (if we ignore zooming and scaling for a bit) and that was it, you didn't really need to change anything around. If you set something to be 100px wide that was all there was to it. Then the first few HiDPI mobile handsets started popping up with the slightly enigmatic devicePixelRatio property on the window object and available for use in media queries. What this property allowed us to do was understand the ratio of how pixel values (which we call the logical pixel value) in - say - CSS would translate to the actual number of pixels the device would use when it came to rendering. In the case of an iPhone 4S, which has a devicePixelRatio of 2, you will see that a 100px logical value equates to a 200px device value.

That's interesting, but what does that mean for us developers? Well in the early days we all started to notice that our images were being upscaled by these devices. We were creating images at the logical pixel width of our elements and, when they were drawn out, they would be upscaled by the devicePixelRatio and they'd be blurry.

Figure 1 - An image being upscaled and blurred due to the devicePixelRatio

The de facto solution to this has been to create images scaled up by the devicePixelRatio and then use CSS to scale it down by the same amount, and the same is true for canvas!

function setupCanvas(canvas) {
  // Get the device pixel ratio, falling back to 1.
  var dpr = window.devicePixelRatio || 1;
  // Get the size of the canvas in CSS pixels.
  var rect = canvas.getBoundingClientRect();
  // Give the canvas pixel dimensions of their CSS
  // size * the device pixel ratio.
  canvas.width = rect.width * dpr;
  canvas.height = rect.height * dpr;
  var ctx = canvas.getContext('2d');
  // Scale all drawing operations by the dpr, so you
  // don't have to worry about the difference.
  ctx.scale(dpr, dpr);
  return ctx;
}

// Now this line will be the same size on the page
// but will look sharper on high-DPI devices!
var ctx = setupCanvas(document.querySelector('.my-canvas'));
ctx.lineWidth = 5;
ctx.beginPath();
ctx.moveTo(100, 100);
ctx.lineTo(200, 200);
ctx.stroke();

Parallaxin'

2011-12-20T00:00:00Z

Introduction #

Parallax sites have been all the rage recently, just take a look at these:

If you’re not familiar with them, they’re the sites where the visual structure of the page changes as you scroll. Normally elements within the page scale, rotate or move proportionally to the scroll position on the page.

Our demo page complete with parallax effect

Whether or not you like parallaxing sites is one thing, but what you can say pretty confidently is that they’re a black hole of performance. The reason for this is that browsers tend to be optimized for the case where new content appears at the top or bottom of the screen when you scroll (depending on your scroll direction) and, in general terms, the browsers work best when very little changes visually during a scroll. For a parallax site that’s rarely the case since many times large visual elements all over the page change, causing the browser to do a repaint of the whole page.

It is reasonable to generalize a parallaxing site like this:

Background elements which, as you scroll up and down, change their position, rotation and scale.
Page content, such as text or smaller images, which scrolls in the typical top-to-bottom fashion.

We previously covered scrolling performance and the ways in which you can look to improve your app’s responsiveness, and this article builds on that foundation so it may be worth reading that if you’ve not done so already.

So the question is if you’re building a parallax scrolling site are you locked into expensive repaints or are there alternative approaches you can take to maximise performance? Let’s take a look at our options.

Option 1: Use DOM elements and absolute positions #

This appears to be the default approach that most people take. There are a bunch of elements within the page, and whenever a scroll event is fired a bunch of visual updates are done to transform them.

If you start the DevTools Timeline in frame mode and scroll around you’ll notice that there are expensive full-screen paint operations, and if you scroll a lot you may see several scroll events inside a single frame, each of which is going to trigger layout work.

DevTools showing large paints and multiple event-triggered layouts in a single frame.

The important thing to bear in mind is that to hit 60fps (matching the typical monitor refresh rate of 60Hz) we have just over 16ms to get everything done. In this first version we’re performing our visual updates every time we get a scroll event, but as we’ve discussed in previous articles on leaner, meaner animations with requestAnimationFrame and scrolling performance, this doesn’t coincide with the browser’s update schedule, and so we either miss frames or do too much work inside each one. That could easily result in a janky and unnatural feel to your site, which leads to disappointed users and unhappy kittens.

Let’s move the update code out from the scroll event to a requestAnimationFrame callback and simply capture the scroll value in the scroll event’s callback.

If you repeat the scrolling test you’ll possibly notice a slight improvement, although not much. The reason is that the layout operation that we trigger by scrolling isn’t all that expensive, but in other use-cases it really could be. Now at least we are only performing one layout operation in each frame.

DevTools showing large paints and multiple event-triggered layouts in a single frame.

We can now handle one or one hundred scroll events per frame but crucially we only store the most recent value for use whenever the requestAnimationFrame callback runs and performs our visual updates. The point is you’ve moved from attempting to force visual updates every time you receive a scroll event to requesting that the browser give you an appropriate window in which to do them. Aren’t you sweet?

The main problem with this approach, requestAnimationFrame or not, is that we essentially have one layer for the whole page, and by moving these visual elements around we require large (and expensive) repaints. Typically speaking the painting is a blocking operation (although that is changing), meaning that the browser can’t do any other work and we often run way over our frame’s budget of 16ms and things remain janky.

Option 2: Use DOM elements and 3D transforms #

Instead of using absolute positions another approach we can take it is to apply 3D transforms to the elements. In this situation we see that the elements with the 3D transforms applied are given a new layer per element and, in WebKit browsers, it often also causes a switch over to the hardware compositor. In Option 1, by contrast, we had one large layer for the page that needed to be repainted when anything changed and all the painting and compositing was handled by the CPU.

That means with this option, things are different: we potentially have one layer for any element to which we apply a 3D transform. If all we do from this point is more transformations on the elements we won’t need to repaint the layer, and the GPU can deal with moving the elements around and compositing the final page together.

Many times people just use the -webkit-transform: translateZ(0); hack and see magical performance improvements, and while this works today there are problems:

It’s not cross-browser compatible.
It forces the browser’s hand by creating a new layer for every transformed element. Lots of layers can bring other performance bottlenecks, so use sparingly!
It’s been disabled for some WebKit ports (fourth bullet from the bottom!).

If you go down the 3D translation route be cautious, it’s a temporary solution to your problem! Ideally speaking we would see similar rendering characteristics from 2D transforms as we do with 3D. Browsers are progressing at a phenomenal rate, so hopefully before that's what we'll see.

Finally, you should aim to avoid paints wherever you can and simply move existing elements around the page. By way of example, it is a typical approach in parallax sites to use fixed height divs and change their background position to provide the effect. Unfortunately that means that the element needs to be repainted on every pass, which can cost you in terms of performance. Instead you should, if you can, create the element (wrap it inside an div with overflow: hidden if necessary) and simply translate it instead.

Option 3: Use a fixed position canvas or WebGL #

The final option we’re going to consider is to use a fixed position canvas at the back of the page into which we will draw our transformed images. At first glance that might not seem like the most performant solution, but there are actually a few benefits to this approach:

We no longer require as much compositor work due to only having one element, the canvas.
We’re effectively dealing with a single hardware accelerated bitmap.
The Canvas2D API is a great fit for the kind of transformations we’re looking to perform, meaning development and maintenance is more manageable.

Using a canvas element gives us a new layer, but it’s just one layer, whereas in Option 2 we were actually given a new layer for every element with a 3D transform applied, so we have an increased workload compositing all those layers together. This is also the most compatible solution today in light of the differing cross-browser implementations of transforms.


/**
 * Updates and draws in the underlying visual elements to the canvas.
 */
function updateElements () {

  var relativeY = lastScrollY / h;

  // Fill the canvas up
  context.fillStyle = "#1e2124";
  context.fillRect(0, 0, canvas.width, canvas.height);

  // Draw the background
  context.drawImage(bg, 0, pos(0, -3600, relativeY, 0));

  // Draw each of the blobs in turn
  context.drawImage(blob1, 484, pos(254, -4400, relativeY, 0));
  context.drawImage(blob2, 84, pos(954, -5400, relativeY, 0));
  context.drawImage(blob3, 584, pos(1054, -3900, relativeY, 0));
  context.drawImage(blob4, 44, pos(1400, -6900, relativeY, 0));
  context.drawImage(blob5, -40, pos(1730, -5900, relativeY, 0));
  context.drawImage(blob6, 325, pos(2860, -7900, relativeY, 0));
  context.drawImage(blob7, 725, pos(2550, -4900, relativeY, 0));
  context.drawImage(blob8, 570, pos(2300, -3700, relativeY, 0));
  context.drawImage(blob9, 640, pos(3700, -9000, relativeY, 0));

  // Allow another rAF call to be scheduled
  ticking = false;
}

/**
 * Calculates a relative disposition given the page's scroll
 * range normalized from 0 to 1
 * @param {number} base The starting value.
 * @param {number} range The amount of pixels it can move.
 * @param {number} relY The normalized scroll value.
 * @param {number} offset A base normalized value from which to start the scroll behavior.
 * @returns {number} The updated position value.
 */
function pos(base, range, relY, offset) {
  return base + limit(0, 1, relY - offset) * range;
}

/**
 * Clamps a number to a range.
 * @param {number} min The minimum value.
 * @param {number} max The maximum value.
 * @param {number} value The value to limit.
 * @returns {number} The clamped value.
 */
function limit(min, max, value) {
  return Math.max(min, Math.min(max, value));
}

This approach really works where you’re dealing with large images (or other elements that can be easily written into a canvas), and certainly dealing with large blocks of text would be more challenging, but depending on your site it may prove to be the most appropriate solution. If you do have to deal with text in the canvas you would have to use the fillText API method, but it’s at the cost of accessibility (you just rasterized the text into a bitmap!) and you will now have to deal with line wrapping and a whole heap of other issues. If you can avoid it, you really should, and you'd likely be better served using the transforms approach above.

Seeing as we’re taking this as far as possible, there’s no reason to presume that the parallax work should be done inside a canvas element. If the browser supports it we could use WebGL. The key here is that WebGL has the most direct route of all APIs to the graphics card and, as such, is your most likely candidate for achieving 60fps, especially if the site’s effects are complex.

Your immediate reaction might be that WebGL is overkill, or that it isn’t ubiquitous in terms of support, but if you use something like Three.js then you can always fall back to using a canvas element and your code is abstracted in a consistent and friendly manner. All we need to do is use Modernizr to check for the appropriate API support:

// check for WebGL support, otherwise switch to canvas
if (Modernizr.webgl) {
  renderer = new THREE.WebGLRenderer();
} else if (Modernizr.canvas) {
  renderer = new THREE.CanvasRenderer();
}

As a final thought on this approach, if you’re not a big fan of adding extra elements to the page you can always use a canvas as a background element in both Firefox and WebKit-based browsers. That’s not ubiquitous, obviously, so as usual you should treat it with caution.

The choice is yours #

The main reason developers default to absolutely positioned elements rather than any of the other options may simply be the ubiquity of support. This is, to some degree, illusory, since the older browsers that are being targeted are likely to provide an extremely poor rendering experience. Even in today’s modern browsers using absolutely positioned elements doesn’t necessarily result in good performance!

Transforms, certainly the 3D kind, offer you the ability to work directly with DOM elements and achieve a solid frame rate. The key to success here is to avoid painting wherever you can and simply try and move elements around. Do bear in mind that the way that WebKit browsers create layers doesn't necessarily correlate to other browser engines, so be sure to test it before committing yourself to that solution.

If you're aiming just for the top tier of browsers, and are able to render the site using canvases, that might the best option for you. Certainly if you were to use Three.js you should be able to swap and change between renderers very easily depending on the support you require.

Conclusion #

We’ve assessed a few approaches to dealing with parallax sites, from absolutely positioned elements to using a fixed position canvas. The implementation you take will, of course, depends on what you’re trying to achieve and the specific design you’re working with, but it’s always good to know you have options.

And as always, whichever approach you try: don’t guess it, test it.

Avoiding Unnecessary Paints - Animated GIF Edition

2011-10-21T00:00:00Z

Avoiding paints is critical to achieving a silky smooth frame rate, especially on mobile. Sometimes, however, paints crop up in the most unusual of places. This article looks at why animated GIFs can cause unnecessary paints to occur, and the remarkably simple fix you can apply.

Layers of loveliness #

As you probably know, modern browsers may paint groups of DOM elements into separate "images", called layers. Sometimes there's one layer for the entire page, sometimes there are hundreds or in rare cases - thousands!

When DOM elements are grouped together into a layer and one of the elements changes visually, we end up having to paint not just the changed element, but all the other elements in the layer that overlap the changed element as well. Painting one thing on top of another results in the overwritten pixels being effectively "lost" forever; if you want the original pixels back you need to repaint them.

Sometimes, therefore, we want to isolate one element from the others so that when it gets painted we won't need to repaint the other elements that haven't changed. For example, when you combine a fixed page header with scrollable content, you have to repaint the header each time the content scrolls, as well as the newly visible content. By placing the header in a separate layer, the browser can optimize scrolling. When you scroll, the browser can move the layers around - probably with the help of the GPU - and avoid repainting either layer.

Each additional layer increases memory consumption and adds performance overhead, so the goal is to group the page into as few layers as possible while maintaining good performance.

What does this all have to do with animated GIFs? #

Well let's have a look at this picture:

Figure 1: A web app broken down into four layers.

This is a potential layer setup for a simple app. There are four layers here: three of them (layers 2 to 4) are interface elements; the back layer is a loader, which happens to be an animated GIF. In the normal flow you show the loader (layer 1) while your app loads, then as everything finishes you would show the other layers. But here's the key: you need to hide the animated GIF.

But why do I need to hide it?! #

Good question. In a perfect world the browser would simply check the GIF’s visibility for you and avoid painting automatically. Unfortunately, checking whether the animated GIF is obscured or visible on the screen is typically more expensive than simply painting it, so it gets painted.

In the best case the GIF is in its own layer and the browser only has to paint and upload it to the GPU. But in the worst case all your elements might be grouped into a single layer and the browser has to repaint every single element. And, when it’s done, it still needs to upload everything to the GPU. All of this is work occurs for every GIF frame, despite the fact that the user can’t even see the GIF!

On desktops you can probably get away with this kind of painting behavior because the CPUs and GPUs are more powerful, and there's plenty of bandwidth for transferring data between the two. On mobile, however, painting is extremely expensive so you must take great care.

Which browsers does this affect? #

As is often the way, behaviors differ between browsers. Today Chrome, Safari and Opera all repaint, even if the GIF is obscured. Firefox, on the other hand, figures out that the GIF is obscured and doesn’t need to be repainted. Internet Explorer remains something of a black box, and even in IE11 - since the F12 tools are still being developed - there is no indication as to whether or not any repainting is taking place.

How can I tell if I have this problem? #

The easiest way is to use "Show paint rectangles" in Chrome DevTools. Load DevTools and press the cog in the lower right corner () and choose Show paint rectangles under the Rendering section.

Figure 2: Enabling Show paint rectangles inside Chrome DevTools.

Now all you need to do is look for a red rectangle like this:

Figure 3: DevTools’ Show Paint Rectangles hints at animated GIF problems with a red rectangle.

The little red box on the screen shows that Chrome is repainting something. You know that there’s a loader GIF hidden behind the other elements, so when you see a red box like this you need to hide the visible elements and check if you have left the animated GIF spinning away. If you have then you need to pop some CSS or JavaScript in place to apply display: none or visibility: hidden to it or its parent element. Of course if it's just a background image then you should make sure to remove it.

If you want to see an example of this behavior in a live site, check out Allegro, where each product’s image has a loader GIF that is obscured rather than explicitly hidden.

Conclusion #

Achieving 60fps means doing only what's needed to render the page and no more. Removing excess paints is a critical step in achieving this goal. Animated GIFs that are left running can trigger unnecessary paints, something which you can find and debug easily with DevTools' Show paint rectangles tool.

Now, you didn't leave that animated kitten loader GIF running forever, did you?

Getting started with Three.js

2011-06-02T00:00:00Z

Introduction #

I have used Three.js for some of my experiments, and it does a really great job of abstracting away the headaches of getting going with 3D in the browser. With it you can create cameras, objects, lights, materials and more, and you have a choice of renderer, which means you can decide if you want your scene to be drawn using HTML 5's canvas, WebGL or SVG. And since it's open source you could even get involved with the project. But right now I'll focus on what I've learned by playing with it as an engine, and talk you through some of the basics.

For all the awesomeness of Three.js, there can be times where you might struggle. Typically you will need to spend quite a large amount of time with the examples, reverse engineering and (in my case certainly) hunting down specific functionality and occasionally asking questions via GitHub. If you have to as questions, by the way, I've found Mr. doob and AlteredQualia are extremely helpful!

1. The basics #

I will assume that you have at least a passing knowledge of 3D, and reasonable proficiency with JavaScript. If you don't it may be worth learning a bit before you try and play with this stuff, as it can get a little confusing.

In our 3D world we will have some of the following, which I will guide you through the process of creating:

A scene
A renderer
A camera
An object or two (with materials)

You can, of course, do some cool things, and my hope is that you will go on to do that and start to experiment with 3D in your browser.

2. Support #

Just a quick note on support in the browsers. Google's Chrome browser is, in my experience, the best browser to work with in terms of which renderers are supported, and the speed of the underlying JavaScript engine. Chrome supports Canvas, WebGL and SVG and it's blazingly fast. Firefox is a close second, with the advent of version 4. Its JavaScript engine does seem to be a touch slower than Chrome's, but again its support for the render technologies is great. Opera and Safari are in the process of adding WebGL support, but their current versions only support canvas. Internet Explorer (version 9+) support canvas rendering only, and I've not heard anything of Microsoft planning to add WebGL capabilities.

3. Set the Scene #

I'll assume you've chosen a browser that supports all the rendering technologies, and that you want to render with canvas or WebGL, since they're the more standard choices. Canvas is more widely supported than WebGL, but it's worth noting that WebGL runs on your graphics card's GPU, which means that your CPU can concentrate on other non-rendering tasks like any physics or user interaction you're trying to do.

Irrespective of your chosen renderer you should bear in mind that the JavaScript will need to optimised for performance. 3D isn't a lightweight task for a browser (and it's awesome that it's even possible), so be careful to understand where any bottlenecks are in your code, and remove them if you can!

So with that said, and on the assumption you have downloaded and included three.js in your HTML file, how do you go about setting up a scene? Like this:

// set the scene size
var WIDTH = 400,
HEIGHT = 300;

// set some camera attributes
var VIEW_ANGLE = 45,
ASPECT = WIDTH / HEIGHT,
NEAR = 0.1,
FAR = 10000;

// get the DOM element to attach to
// - assume we've got jQuery to hand
var $container = $('#container');

// create a WebGL renderer, camera
// and a scene
var renderer = new THREE.WebGLRenderer();
var camera = new THREE.PerspectiveCamera(
                VIEW_ANGLE,
                ASPECT,
                NEAR,
                FAR );

var scene = new THREE.Scene();

// the camera starts at 0,0,0 so pull it back
camera.position.z = 300;

// start the renderer
renderer.setSize(WIDTH, HEIGHT);

// attach the render-supplied DOM element
$container.append(renderer.domElement);

Not too tricky, really!

4. Making a Mesh #

So we have a scene, a camera and a renderer (I opted for a WebGL one in my sample code) but we have nothing to actually draw. Three.js actually comes with support for loading a few different standard file types, which is great if you are outputting models from Blender, Maya, Cinema4D or anything else. To keep things simple (this is about getting started after all!) I'll talk about primitives. Primitives are geometric meshes, relatively basic ones like Spheres, Planes, Cubes and Cylinders. Three.js lets you create these types of primitives easily:

// set up the sphere vars
var radius = 50, segments = 16, rings = 16;

// create a new mesh with sphere geometry -
// we will cover the sphereMaterial next!
var sphere = new THREE.Mesh(
new THREE.SphereGeometry(radius,
segments,
rings),

sphereMaterial);

// add the sphere to the scene
scene.add(sphere);

All good, but what about the material for the sphere? In the code we've used a variable sphereMaterial but we've not defined it yet. First we need to talk about materials in a bit more detail.

5. Materials #

Without doubt this is one of the most useful parts of Three.js. It provides for you a number of common (and very handy) materials to apply to your meshes:

'Basic' - which just means that it renders 'unlit'
Lambert
Phong

There are more, but again in the interests of simplicity I'll let you discover those for yourself. In the case of WebGL particularly these materials can be a life-saver. Why? Well because in WebGL you have to write shaders for everything being rendered. Shaders are a huge topic in themselves, but in short they are written in GLSL (OpenGL Shader Language), which tells the GPU how something should look. This means you need to mimic the maths of lighting, reflection and so on. It can get very complicated very quickly. Thanks to Three.js you don't have to do this if you don't want to because it abstracts that away for you. If you want to write shaders, however, you can do that too with a MeshShaderMaterial, so it's a flexible setup.

For now, however, let's apply a lambert material to the sphere:

// create the sphere's material
var sphereMaterial = new THREE.MeshLambertMaterial(
{
// a gorgeous red.
color: 0xCC0000
});

It's worth pointing out as well that there are other properties you can specify when you create a material besides the colour, such as smoothing or environment maps. You should check out the Wiki page for the various properties you can set on the materials and, in fact, any object that the engine provides for you. Also threejs.org recently sprung up, which offers a more attractive view of the API.

6. Lights! #

If you were to render the scene right now you'd see a red circle. Even though we have a Lambert material applied there's no light in the scene so by default Three.js will revert to a full ambient light, which is the same as flat colouring. Let's fix that with a simple point of light:

// create a point light
var pointLight = new THREE.PointLight( 0xFFFFFF );

// set its position
pointLight.position.x = 10;
pointLight.position.y = 50;
pointLight.position.z = 130;

// add to the scene
scene.add(pointLight);

7. Render #

We now actually have everything set up to render, remarkably. But we actually need to go ahead and do just that:

// draw!
renderer.render(scene, camera);

You're probably going to want to render more than once, though, so if you're going to do a loop you should really use requestAnimationFrame; it's by far the smartest way of handling animation in the browser. It's not fully supported as yet, so I'd totally recommend that you take a look at Paul Irish's shim.

8. Common Object Properties #

If you take time to look through the code for Three.js you'll see a lot of objects 'inherit' from Object3D. This is a base object which contains some very useful properties, such as the position, rotation and scale information. In particular our Sphere is a Mesh which inherits from Object3D, to which it adds its own properties: geometry and materials. Why do I mention these? Well it's unlikely you're going to want to just have a sphere on your screen that does nothing, and these properties are worth investigating as they allow you to manipulate the underlying details of the meshes and materials on the fly.

// sphere geometry
sphere.geometry

// which contains the vertices and faces
sphere.geometry.vertices // an array
sphere.geometry.faces // also an array

// its position
sphere.position // has x, y and z properties
sphere.rotation // same
sphere.scale // ... same

9. Dirty Little Secrets #

I just wanted to quickly point out a quick gotcha for Three.js, which is that if you modify, for example, the vertices of a mesh, you will notice in your render loop that nothing changes. Why? Well because Three.js (as far as I can tell) caches the data for a mesh as something of an optimisation. What you actually need to do is to flag to Three.js that something has changed so it can recalculate whatever it needs to. You do this with the following:

// changes to the vertices
sphere.geometry.__dirtyVertices = true;

// changes to the normals
sphere.geometry.__dirtyNormals = true;

Again there are more, but those two I've found are the most useful. You should obviously only flag the things that have changed to avoid unnecessary calculations.

Conclusion #

Well I hope you've found this brief introduction to Three.js helpful. There's nothing quite like actually getting your hands dirty and trying something, and I can't recommend it highly enough. 3D running natively in the browser is a lot of fun, and using an engine like Three.js takes away a lot of the headaches for you and lets you get to making some seriously cool stuff. To help you out a bit I've wrapped up the source code in this lab article, so you can use that as a reference. If you've enjoyed this let me know via Twitter, it's always good to say hello!

An introduction to shaders

2011-06-02T00:00:00Z

Introduction #

I've previously given you an introduction to Three.js. If you've not read that you might want to as it's the foundation on which I will be building during this article.

What I want to do is discuss shaders. WebGL is brilliant, and as I've said before Three.js (and other libraries) do a fantastic job of abstracting away the difficulties for you. But there will be times you want to achieve a specific effect, or you will want to dig a little deeper into how that amazing stuff appeared on your screen, and shaders will almost certainly be a part of that equation. Also if you're like me you may well want to go from the basic stuff in the last tutorial to something a little more tricky. I'll work on the basis that you're using Three.js, since it does a lot of the donkey work for us in terms of getting the shader going. I'll say up front as well that at the start I will be explaining the context for shaders, and that the latter part of this tutorial is where we will get into slightly more advanced territory. The reason for this is that shaders are unusual at first sight and take a bit of explaining.

1. Our Two Shaders #

WebGL does not offer the use of the Fixed Pipeline, which is a shorthand way of saying that it doesn't give you any means of rendering your stuff out of the box. What it does offer, however, is the Programmable Pipeline, which is more powerful but also more difficult to understand and use. In short the Programmable Pipeline means as the programmer you take responsibility for getting the vertices and so forth rendered to the screen. Shaders are a part of this pipeline, and there are two types of them:

Vertex shaders
Fragment shaders

Both of which, I'm sure you'll agree, mean absolutely nothing by themselves. What you should know about them is that they both run entirely on your graphics card's GPU. This means that we want to offload all that we can to them, leaving our CPU to do other work. A modern GPU is heavily optimised for the functions that shaders require so it's great to be able to use it.

2. Vertex Shaders #

Take a standard primitive shape, like a sphere. It's made up of vertices, right? A vertex shader is given every single one of these vertices in turn and can mess around with them. It's up to the vertex shader what it actually does with each one, but it has one responsibility: it must at some point set something called gl_Position, a 4D float vector, which is the final position of the vertex on screen. In and of itself that's quite an interesting process, because we're actually talking about getting a 3D position (a vertex with x,y,z) onto, or projected, to a 2D screen. Thankfully for us if we're using something like Three.js we will have a shorthand way of setting the gl_Position without things getting too heavy.

3. Fragment Shaders #

So we have our object with its vertices, and we've projected them to the 2D screen, but what about the colours we use? What about texturing and lighting? That's exactly what the fragment shader is there for. Very much like the vertex shader, the fragment shader also only has one must-do job: it must set or discard the gl_FragColor variable, another 4D float vector, which the final colour of our fragment. But what is a fragment? Think of three vertices which make a triangle. Each pixel within that triangle needs to be drawn out. A fragment is the data provided by those three vertices for the purpose of drawing each pixel in that triangle. Because of this the fragments receive interpolated values from their constituent vertices. If one vertex is coloured red, and its neighbour is blue we would see the colour values interpolate from red, through purple, to blue.

4. Shader Variables #

When talking about variables there are three declarations you can make: Uniforms, Attributes and Varyings. When I first heard of those three I was very confused since they don't match anything else I'd ever worked with. But here's how you can think of them:

Uniforms are sent to both vertex shaders and fragment shaders and contain values that stay the same across the entire frame being rendered. A good example of this might be a light's position.
Attributes are values that are applied to individual vertices. Attributes are only available to the vertex shader. This could be something like each vertex having a distinct colour. Attributes have a one-to-one relationship with vertices.
Varyings are variables declared in the vertex shader that we want to share with the fragment shader. To do this we make sure we declare a varying variable of the same type and name in both the vertex shader and the fragment shader. A classic use of this would be a vertex's normal since this can be used in the lighting calculations.

Later on we'll use all three types so you can get a feel for how they are applied for real.

Now we've talked about vertex shaders and fragment shaders and the types of variables they deal with, it's now worth looking at the simplest shaders we can create.

5. Bonjourno World #

Here, then, is the Hello World of vertex shaders:

/**
* Multiply each vertex by the model-view matrix
* and the projection matrix (both provided by
* Three.js) to get a final vertex position
*/
void main() {
gl_Position = projectionMatrix *
                modelViewMatrix *
                vec4(position,1.0);
}

and here's the same for the fragment shader:

/**
* Set the colour to a lovely pink.
* Note that the color is a 4D Float
* Vector, R,G,B and A and each part
* runs from 0.0 to 1.0
*/
void main() {
gl_FragColor = vec4(1.0, 0.0, 1.0, 1.0);
}

Not too complicated though, right?

In the vertex shader we are sent a couple of uniforms by Three.js. These two uniforms are 4D matrices, called the Model-View Matrix and the Projection Matrix. You don't desperately need to know exactly how these work, although it's always best to understand how things do what they do if you can. The short version is that they are how the 3D position of the vertex is actually projected to the final 2D position on the screen.

I've actually left them out of the snippet above because Three.js adds them to the top of your shader code itself so you don't need to worry about doing it. Truth be told it actually adds a lot more than that, such as light data, vertex colours and vertex normals. If you were doing this without Three.js you would have to create and set all those uniforms and attributes yourself. True story.

6. Using a MeshShaderMaterial #

OK, so we have a shader set up, but how do we use it with Three.js? It turns out that it's terribly easy. It's rather like this:

/**
* Assume we have jQuery to hand and pull out
* from the DOM the two snippets of text for
* each of our shaders
*/
var shaderMaterial = new THREE.MeshShaderMaterial({
vertexShader:   $('vertexshader').text(),
fragmentShader: $('fragmentshader').text()
});

From there Three.js will compile and run your shaders attached to the mesh to which you give that material. It doesn't get much easier than that really. Well it probably does, but we're talking about 3D running in your browser so I figure you expect a certain amount of complexity.

We can actually add two more properties to our MeshShaderMaterial: uniforms and attributes. They can both take vectors, integers or floats but as I mentioned before uniforms are the same for the whole frame, i.e. for all vertices, so they tend to be single values. Attributes, however, are per-vertex variables, so they are expected to be an array. There should be a one-to-one relationship between the number of values in the attributes array and the number of vertices in the mesh.

7. Next Steps #

Now we are going to spend a bit of time adding in an animation loop, vertex attributes and a uniform. We'll also add in a varying variable so that the vertex shader can send some data to the fragment shader. The end result is that our sphere that was pink is going to appear to be lit from above and to the side and is going to pulsate. It's kind of trippy, but hopefully it will lead you to a good understanding of the three variable types as well as how they relate to each other and the underlying geometry.

8. A Fake Light #

Let's update the colouring so it's not a flat coloured object. We could take a look at how Three.js handles lighting, but as I'm sure you can appreciate it's more complex than we need right now, so we're going to fake it. You should totally look through the fantastic shaders that are a part of Three.js, and also the ones from the recent amazing WebGL project by Chris Milk and Google, Rome. Back to our shaders. We'll update our Vertex Shader to provide each vertex normal to the Fragment Shader. We do this with a varying:

// create a shared variable for the
// VS and FS containing the normal
varying vec3 vNormal;

void main() {

// set the vNormal value with
// the attribute value passed
// in by Three.js
vNormal = normal;

gl_Position = projectionMatrix *
                modelViewMatrix *
                vec4(position,1.0);
}

and in the Fragment Shader we're going to set up the same variable name and then use the dot product of the vertex normal with a vector that represents a light shining from above and to the right of the sphere. The net result of this gives us an effect similar to a directional light in a 3D package.

// same name and type as VS
varying vec3 vNormal;

void main() {

// calc the dot product and clamp
// 0 -> 1 rather than -1 -> 1
vec3 light = vec3(0.5,0.2,1.0);
    
// ensure it's normalized
light = normalize(light);

// calculate the dot product of
// the light to the vertex normal
float dProd = max(0.0, dot(vNormal, light));

// feed into our frag colour
gl_FragColor = vec4(dProd, dProd, dProd, 1.0);

}

So the reason the dot product works is that given two vectors it comes out with a number that tells you how 'similar' the two vectors are. With normalised vectors, if they point in exactly the same direction, you get a value of 1. If they point in opposite directions you get a -1. What we do is take that number and apply it to our lighting. So a vertex in the top right will have a value near or equal to 1, i.e. fully lit, whereas a vertex on the side would have a value near 0 and round the back would be -1. We clamp the value to 0 for anything negative, but when you plug the numbers in you end up with the basic lighting we're seeing.

What's next? Well it would be nice to maybe try messing with some vertex positions.

9. Attributes #

What I'd like us to do now is attach a random number to each vertex via an attribute. We'll use this number to push the vertex out along its normal. The net result will be some kind of weird spike ball that will change every time you refresh the page. It won't be animated just yet (that happens next) but a few page refreshes will show you it's randomised.

Let's start by adding in the attribute to the vertex shader:

attribute float displacement;
varying vec3 vNormal;

void main() {

vNormal = normal;

// push the displacement into the three
// slots of a 3D vector so it can be
// used in operations with other 3D
// vectors like positions and normals
vec3 newPosition = position + 
                    normal * 
                    vec3(displacement);

gl_Position = projectionMatrix *
                modelViewMatrix *
                vec4(newPosition,1.0);
}

How does it look?

Not much different really! This is because the attribute hasn't been set up in the MeshShaderMaterial so effectively the shader uses a zero value instead. It's kind of like a placeholder right now. In a second we'll add the attribute to the MeshShaderMaterial in the JavaScript and Three.js will tie the two together for us automatically.

Also of note is the fact that I had to assign the updated position to a new vec3 variable because the original attribute, like all attributes, is read only.

10. Updating the MeshShaderMaterial #

Let's hop straight into updating our MeshShaderMaterial with the attribute needed to power our displacement. A reminder: attributes are per-vertex values so we need one value per vertex in our sphere. Like this:

var attributes = {
displacement: {
    type: 'f', // a float
    value: [] // an empty array
}
};

// create the material and now
// include the attributes property
var shaderMaterial = new THREE.MeshShaderMaterial({
attributes:     attributes,
vertexShader:   $('#vertexshader').text(),
fragmentShader: $('#fragmentshader').text()
});

// now populate the array of attributes
var vertices = sphere.geometry.vertices;
var values = attributes.displacement.value
for(var v = 0; v < vertices.length; v++) {
values.push(Math.random() * 30);
}

Now we're seeing a mangled sphere, but the cool thing is that all the displacement is happening on the GPU.

11. Animating That Sucker #

We should totally make this animate. How do we do it? Well there are two things we need to get in place:

A uniform to animate how much displacement should be applied in each frame. We can use sine or cosine for that since they run from -1 to 1
An animation loop in the JS

We're going to add the uniform to both the MeshShaderMaterial and the Vertex Shader. First the Vertex Shader:

uniform float amplitude;
attribute float displacement;
varying vec3 vNormal;

void main() {

vNormal = normal;

// multiply our displacement by the
// amplitude. The amp will get animated
// so we'll have animated displacement
vec3 newPosition = position + 
                    normal * 
                    vec3(displacement *
                        amplitude);

gl_Position = projectionMatrix *
                modelViewMatrix *
                vec4(newPosition,1.0);
}

Next we update the MeshShaderMaterial:

// add a uniform for the amplitude
var uniforms = {
amplitude: {
    type: 'f', // a float
    value: 0
}
};

// create the final material
var shaderMaterial = new THREE.MeshShaderMaterial({
uniforms:       uniforms,
attributes:     attributes,
vertexShader:   $('#vertexshader').text(),
fragmentShader: $('#fragmentshader').text()
});

Our shaders are done for now. But right we would appear to have taken a step backwards. This is largely because our amplitude value is at 0 and since we multiply that with the displacement we're seeing nothing change. We also haven't set up the animation loop so we never see that 0 change to anything else.

In our JavaScript we now need to wrap up the render call into a function and then use requestAnimationFrame to call it. In there we also need to update the uniform's value.

var frame = 0;
function update() {

// update the amplitude based on
// the frame value
uniforms.amplitude.value = Math.sin(frame);
frame += 0.1;

renderer.render(scene, camera);

// set up the next call
requestAnimFrame(update);
}
requestAnimFrame(update);

12. Conclusion #

And that's it! You can now see it's animating in a strange (and slightly trippy) pulsating manner.

There's so much more we can cover on shaders as a topic, but I hope you've found this introduction helpful. You should now be able to understand shaders when you see them as well as having the confidence to create some amazing shaders of your own!

Paul Lewis on web.dev

Avoid large, complex layouts and layout thrashing

Summary #

The effects of layout on interaction latency #

Avoid layout wherever possible #

Avoid forced synchronous layouts #

Avoid layout thrashing #

Reduce the scope and complexity of style calculations

Summary #

Style recalculation time and interaction latency #

Reduce the complexity of your selectors #

Reduce the number of elements being styled #

Measure your style recalculation cost #

Use Block, Element, Modifier #

Resources #

Simplify paint complexity and reduce paint areas

Summary #

Triggering Layout And Paint #

Use Chrome DevTools to quickly identify paint bottlenecks #

Promote elements that move or fade #

Reduce paint areas #

Simplify paint complexity #

Debounce your input handlers

Summary #

Avoid long-running input handlers #

Avoid style changes in input handlers #

Debounce your scroll handlers #

Optimize JavaScript execution

Summary #

Use requestAnimationFrame for visual changes #

Reduce complexity or use Web Workers #

Know your JavaScript’s “frame tax” #

Avoid micro-optimizing your JavaScript #

Rendering Performance

60fps and Device Refresh Rates #

The pixel pipeline #

1. JS / CSS > Style > Layout > Paint > Composite #

2. JS / CSS > Style > Paint > Composite #

3. JS / CSS > Style > Composite #

Browser Rendering Optimizations #

Stick to Compositor-Only Properties and Manage Layer Count

Summary #

Use transform and opacity changes for animations #

Promote elements that you plan to animate #

Manage layers and avoid layer explosions #

Use Chrome DevTools to understand the layers in your app #

Animating Between Views

Use translations to move between views #

Ensure that your animation works with larger screens #

Animations and performance

Using the will-change property #

CSS vs JavaScript performance #

Animating Modal Views

Custom easing

Summary #

Use JavaScript frameworks for more control #

TweenMax #

The Basics of easing

Summary #

Easing keywords #

Linear animations #

Ease-out animations #

Ease-in animations #

Ease-in-out animations #

CSS versus JavaScript animations

Summary #

Animate with CSS #

Animate with JavaScript and the Web Animations API #

Asymmetric animation timing

Choosing the right easing

Summary #

Pick the right animation duration #

Canvas inspection using Chrome DevTools

Introduction #

Getting Started #

Capturing frames #

Spot the difference #

Be heard! #

Antialiasing 101

Introduction #

Use `requestAnimationFrame` for visual changes #

Using the `will-change` property #