7 Performance Tips for Jank-free JavaScript Animations

The role of web animation has evolved from mere decorative fluff to serving concrete purposes in the context of user experience — such as providing visual feedback as users interact with your app, directing users’ attention to fulfill your app’s goals, offering visual cues that help users make sense of your app’s interface, and so on.
To ensure web animation is up to such crucial tasks, it’s important that motion takes place at the right time in a fluid and smooth fashion, so that users perceive it as aiding them, rather than as getting in the way of whatever action they’re trying to pursue on your app.
One dreaded effect of ill-conceived animation is jank, which is explained on jankfree.org like this:

Modern browsers try to refresh the content on screen in sync with a device’s refresh rate. For most devices today, the screen will refresh 60 times a second, or 60Hz. If there is some motion on screen (such as scrolling, transitions, or animations) a browser should create 60 frames per second to match the refresh rate. Jank is any stuttering, juddering or just plain halting that users see when a site or app isn’t keeping up with the refresh rate.

If animations are janky, users will eventually interact less and less with your app, thereby negatively impacting on its success. Obviously, nobody wants that.
In this article, I’ve gathered a few performance tips to help you solve issues with JavaScript animations and make it easier to meet the 60fps (frame per second) target for achieving smooth motion on the web.
#1 Avoid Animating Expensive CSS Properties
Whether you plan on animating CSS properties using CSS Transitions/CSS keyframes or JavaScript, it’s important to know which properties bring about a change in the geometry of the page (layout) — meaning that the position of other elements on the page will have to be recalculated, or that painting operations will be involved. Both layout and painting tasks are very expensive for browsers to process, especially if you have several elements on your page. As a consequence, you’ll see animation performance improve significantly if you avoid animating CSS properties that trigger layout or paint operations and stick to properties like transforms and opacity, because modern browsers do an excellent job of optimizing them.
On CSS Triggers you’ll find an up-to-date list of CSS properties with information about the work they trigger in each modern browser, both on the first change and on subsequent changes.

Changing CSS properties that only trigger composite operations is both an easy and effective step you can take to optimize your web animations for performance.
#2 Promote Elements You Want to Animate to Their Own Layer (with Caution)
If the element you want to animate is on its own compositor layer, some modern browsers leverage hardware acceleration by offloading the work to the GPU. If used judiciously, this move can have a positive effect on the performance of your animations.
To have the element on its own layer, you need to promote it. One way you can do so is by using the CSS will-change property. This property allows developers to warn the browser about some changes they want to make on an element, so that the browser can make the required optimizations ahead of time.
However, it’s not advised that you promote too many elements on their own layer or that you do so with exaggeration. In fact, every layer the browser creates requires memory and management, which can be expensive.
You can learn the details of how to use will-change, its benefits and downsides, in An Introduction to the CSS will-change Property by Nick Salloum.
#3 Replace setTimeOut/setInterval with requestAnimationFrame
JavaScript animations have commonly been coded using either setInterval() or setTimeout().
The code would look something like this:
var timer;
function animateElement() {
timer = setInterval( function() {
// animation code goes here
} , 2000 );
}

// To stop the animation, use clearInterval
function stopAnimation() {
clearInterval(timer);
}

Although this works, the risk of jank is high, because the callback function runs at some point in the frame, perhaps at the very end, which can result in one or more frames being missed. Today, you can use a native JavaScript method which is tailored for smooth web animation (DOM animation, canvas, etc.), called requestAnimationFrame().
requestAnimationFrame() executes your animation code at the most appropriate time for the browser, usually at the beginning of the frame.
Your code could look something like this:
function makeChange( time ) {
// Animation logic here

// Call requestAnimationFrame recursively inside the callback function
requestAnimationFrame( makeChange ):
}

// Call requestAnimationFrame again outside the callback function
requestAnimationFrame( makeChange );

Performance with requestAnimationFrame by Tim Evko here on SitePoint offers a great video introduction to coding with requestAnimationFrame().
The post 7 Performance Tips for Jank-free JavaScript Animations appeared first on SitePoint.

Link: https://www.sitepoint.com/7-performance-tips-jank-free-javascript-animations/

The web can be anything we want it to be

I really enjoyed this chat between Bruce Lawson and Mustafa Kurtuldu where they talked about browser support and the health of the web. Bruce expands upon a lot of the thoughts in a post he wrote last year called World Wide Web, Not Wealthy Western Web where he writes:
…across the world, regardless of disposable income, regardless of hardware or network speed, people want to consume the same kinds of goods and services. And if your websites are made for …
The post The web can be anything we want it to be appeared first on CSS-Tricks.

Link: https://www.youtube.com/watch?v=tvLF7zllsv0

CDN, BCD, and SVG: MDN Changelog for April 2018

The MDN engineering team reports on work accomplished in April and what’s ahead in May. Some highlights: MDN Web Docs site moved to a CDN, improving page load time by 16%. The migration of browser compatibility data (the BCD project) continues apace, and is now 72% done. The team began the work of replacing font-based icons with inline SVG; the work to improve accessibility and localization with SVG icons continues. In April, 510 pull requests were merged, including 140 pull requests from 57 new contributors.

Link: https://hacks.mozilla.org/2018/05/cdn-bcd-and-svg-mdn-changelog-for-april-2018/

Hey hey `font-display`

Y’all know about font-display? It’s pretty great. It’s a CSS property that you can use within @font-face blocks to control how, visually, that font loads. Font loading is really pretty damn complicated. Here’s a guide from Zach Leatherman to prove it, which includes over 10 font loading strategies, including strategies that involve critical inline CSS of subsets of fonts combined with loading the rest of the fonts later through JavaScript. It ain’t no walk in the park.

Using font-display…
The post Hey hey `font-display` appeared first on CSS-Tricks.

Link: https://css-tricks.com/hey-hey-font-display/

16 Best Practices for Shared UI Libraries

Recently, the New Relic Core UI team moved to React v16.0. In support of this move, we’ve had to upgrade a handful of shared UI libraries owned by teams across the company. As most of us know, upgrading cross-company dependencies can be quite the challenge, and it takes a lot of time.
Often, during such work, we find that UI libraries are not always in the best shape for sharing. To that end, I’ve put together this list of some best practices and recommendations for building shareable UI libraries. For clarity, I’ve grouped the recommendations in three critical categories: CSS, JavaScript, and packaging and distribution.

Link: https://dzone.com/articles/16-best-practices-for-shared-ui-libraries

Chrome DevTools “Local Overrides”

There’s been two really interesting videos released recently that use the “Local Overrides" feature of Chrome DevTools in order to play with web performance without even touching the original source code.

Umar Hansa: Improving the performance of Soylent.com with local overrides and font-display
Harry Roberts: Using Chrome’s ‘Local Overrides’ to Test Performance Hypotheses

The big idea is that you can literally edit CSS and reload the page and your changes stick. Meaning you can use the other performance testing tools …
The post Chrome DevTools “Local Overrides” appeared first on CSS-Tricks.

Link: https://www.youtube.com/watch?v=yRrrL0Mg1pM

Top 3 Invisible UX Design Decisions That ‘Level Up’ Player Happiness

This article was featured in our first ever DZone Guide to Game Development. Get your free copy for more insightful articles, industry statistics, and more!  A game’s user experience starts before a player levers a thumbstick or taps their screen. Game developers have gotten the offline, in-game experience down to a science, but increasing dependence on the internet for exceptional gaming experiences has created new opportunities for developers to win… or for “Game Over.”

Link: https://dzone.com/articles/top-3-invisible-ux-design-decisions-that-level-up?utm_medium=feed&utm_source=feedpress.me&utm_campaign=Feed%3A+dzone%2Fwebdev

Three Techniques for Performant Custom Font Usage

There’s a lot of good news in the world of web fonts!

The forthcoming version of Microsoft Edge will finally implement unicode-range, the last modern browser to do so.
Preload and font-display are landing in Safari and Firefox.
Variable fonts are shipping everywhere.

Using custom fonts in a performant way is becoming far easier. Let’s take a peek at some things we can do when using custom fonts to make sure we’re being as performant as we can be.…

Three Techniques for Performant Custom Font Usage is a post from CSS-Tricks

Link: https://css-tricks.com/three-techniques-performant-custom-font-usage/

Oxidizing Source Maps with Rust and WebAssembly

A detailed look at how we replaced the most performance-sensitive portions of the source-map JavaScript Library’s source map parser with Rust code that is compiled to WebAssembly. The results: The WebAssembly is up to 5.89 times faster than the JavaScript implementation on realistic benchmarks operating on real world source maps! Additionally, performance is also more consistent: relative standard deviations decreased.
We hope that, by sharing our experience, we inspire others rewrite performance-sensitive JavaScript in Rust via WebAssembly.

Link: https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/

Third-Party Scripts

Trent Walton:
My latest realization is that delivering a performant, accessible, responsive, scalable website isn’t enough: I also need to consider the impact of third-party scripts. No matter how solid I think my prototype is, it doesn’t absolve me from paying attention to what happens during implementation, specifically when it comes to the addition of these third-party scripts.
I recently had a conversation with a friend working on quite a high profile e-commerce site. They were hired to develop …

Third-Party Scripts is a post from CSS-Tricks

Link: https://css-tricks.com/third-party-scripts/