Performance

The "Optimal Image Format" for Each Browser

Perhaps you’ve heard about the WebP image format? And how it’s a pretty good performance win, for the browsers that support it? Well that’s only for Blink-based browsers, at the moment. Estelle Weyl’s article Image Optimization explains the best image format for each browser:

Browser Optimal image format
Chrome WebP
IE 9+ / Edge JPEG-XR
Opera WebP
Safari JPEG-2000

And you can serve these formats through the <picture><source type=""> syntax.

Couple that complexity with the complexity of responsive images, and it really seems like outsourcing image delivery to a dedicated service seems like the way to go. At least above a certain scale.

`font-display`, a CSS alternative to JavaScript font loading

The font-display property is landing in browsers, and this is a great introduction to using it:

If you don’t know which option to use, then go with swap. Not only does it provide an optimal balance between custom fonts and accessibility of content, it provides the same font loading behavior that we’ve relied on JavaScript for. If you have fonts on the page that you’d like to have load, but could ultimately do without, consider going with fallback or optional when using font-display.

Until it’s more widely supported, you can continue to use a JavaScript solution, but even then you can feature detect first:

Code language: JavaScript

if ("fontDisplay" in document.body.style === false) {
  /* JavaScript font loading logic goes here. */
}

10 things I learned making the fastest site in the world

Most of this post is really useful (and also hilarious), but these stand out as possibly super helpful:

So, this is what I wanted to happen:

  • Start downloading the data as soon as possible (without blocking the HTML).
  • Start downloading the app’s JavaScript as soon as possible (without blocking the HTML).
  • When both the script and the data are downloaded, and the HTML has been parsed, run the script which will breath life into the page.

I could have done all sorts of fancy footwork in JavaScript to get this working, but I have a better solution. Well, it works, but I have a nagging feeling I’m doing something [ableist slur].

Browser experts get your magnifying glasses out…

  • In the <head> I have a <link rel="preload" … > for both the JSON and and the JS (I have prefetch as well for browsers that don’t support preload yet)
  • At the end of the body I load the application JS in a regular <script> tag.
  • When the JS executes, it’s does a fetch() for the JSON file, and .then() kicks off the rendering of the React app.

That looks something like this.

Once any asset is on the way down, further calls to download it won’t go out to the network. The network calls look like this:

So unless I’m wrong, I see no reason to not preload everything at the top of the page.

JavaScript loading: Prefer DEFER Over ASYNC

ASYNC and DEFER are similar in that they allow scripts to load without blocking the HTML parser which means users see page content more quickly. But they do have differences:

  • Scripts loaded with ASYNC are parsed and executed immediately when the resource is done downloading. Whereas DEFER scripts don’t execute until the HTML document is done being parsed (AKA, DOM Interactive or performance.timing.domInteractive).
  • ASYNC scripts may load out-of-order, whereas DEFER scripts are executed in the order in which they appear in markup. (Although there’s a bug that makes DEFER’s execution order questionable in IE⇐9.)

Even though ASYNC and DEFER don’t block the HTML parser, they can block rendering. This happens when they’re parsed and executed before rendering is complete and take over the browser main thread. There’s nothing in the spec that says they have to wait until rendering is complete. ASYNC scripts execute immediately once they finish downloading, and DEFER scripts execute after DOM Interactive.

[…]

DEFER always causes script execution to happen at the same time as or later than ASYNC. Presumably, scripts are made DEFER or ASYNC because they are less important for the critical content on the page. Therefore, it’s better to use DEFER so that their execution happens outside of the main rendering time.

DEFER scripts can never block synchronous scripts, while ASYNC scripts might depending on how quickly they download. Synchronous scripts are typically made synchronous because they are important for the critical content on the page. Therefore, it’s better to use DEFER so that synchronous scripts are not blocked from executing and their critical work is completed more quickly.

GPU Animation: Doing It Right

Most people now know that modern web browsers use the GPU to render parts of web pages, especially ones with animation. For example, a CSS animation using the transform property looks much smoother than one using the left and top properties. But if you ask, “How do I get smooth animation from the GPU?” in most cases, you’ll hear something like, “Use transform: translateZ(0) or will-change: transform.”

These properties have become something like how we used zoom: 1 for Internet Explorer 6 (if you catch my drift) in terms of preparing animation for the GPU — or compositing, as browser vendors like to call it.

But sometimes animation that is nice and smooth in a simple demo runs very slowly on a real website, introduces visual artefacts or even crashes the browser. Why does this happen? How do we fix it?

[…]

  • Watch out for the number and size of composite layers from the very beginning — especially ones created by implicit compositing. The “Layers” panel in your browser’s development tools is your best friend.
  • Modern browsers make heavy use of compositing not just for animation but to optimize the painting of page elements. For example, position: fixed and the iframe and video elements use compositing.
  • The size of compositing layers is likely be more important than the number of layers. In some cases, the browser will try to reduce the number of composite layers (see the “Layer Squashing” section of “GPU Accelerated Compositing in Chrome“); this prevents so-called “layer explosion” and reduces memory consumption, especially when layers have large intersections. But sometimes, such optimization has a negative impact, such as when a very large texture consumes much more memory than a few small layers. To bypass this optimization, I add a small, unique translateZ() value to each element, such as translateZ(0.0001px), translateZ(0.0002px), etc. The browser will determine that the elements lie on different planes in the 3D space and, thus, skip optimization.
  • You can’t just add transform: translateZ(0) or will-change: transform to any random element to virtually improve animation performance or to get rid of visual artifacts. GPU compositing has many drawbacks and tradeoffs to be considered. When not used sparingly, compositing will decrease overall performance at best, and crash browsers at worst.

Allow me to remind you of the big disclaimer: There is no official specification for GPU compositing, and each browser solves the same problems differently. Some sections of this article may become obsolete in a few months.

Premonish - A library for predicting what element a user will interact with next.

This is really cool. This library seems to use the pointer’s trajectory to predict what you’re heading towards, and highlights the appropriate cube. I suspect this only works with pointers that can be detected as moving, like mice and styluses that have that capability, but probably does nothing useful with touch in most cases. Either way, give it a shot, it’s eerie. The most obvious use case for this is to pre-load a link if the user starts to head for it, but of course that has the side effect of possibly wasting the user’s data if they’re on a capped connection.

Performant Parallaxing

Love it or hate it, parallaxing is here to stay. When used judiciously it can add depth and subtlety to a web app. The problem, however, is that implementing parallaxing in a performant way can be challenging. In this article we’ll discuss a solution that is both performant and, just as importantly, works cross-browser.

TL;DR

  • Don’t use scroll events or background-position to create parallax animations.
  • Use CSS 3D transforms to create a more accurate parallax effect.
  • For Mobile Safari use position: sticky to ensure that the parallax effect gets propagated.

[…]

Both Scott Kellum and Keith Clark have done significant work in the area of using CSS 3D to achieve parallax motion, and the technique they use is effectively this:

  • Set up a containing element to scroll with overflow-y: scroll (and probably overflow-x: hidden).
  • To that same element apply a perspective value, and a perspective-origin set to top left, or 0 0.
  • To the children of that element apply a translation in Z, and scale them back up to provide parallax motion without affecting their size on screen.

The CSS for this approach looks like so:

Code language: CSS

.container {
  width: 100%;
  height: 100%;
  overflow-x: hidden;
  overflow-y: scroll;
  perspective: 1px;
  perspective-origin: 0 0;
}
 
.parallax-child {
  transform-origin: 0 0;
  transform: translateZ(-2px) scale(3);
}

Which assumes a snippet of HTML like this:

Code language: HTML

<div class="container”>
  <div class="parallax-child”></div>
</div>