Performance optimizations for the interaction to next paint metric and sharing the learning along the way

Essentially, there are multiple different ways in which we can attribute a certain task to other tasks or to the party that initiated it.

Those different ways are not always obvious, because for the straightforward case, they all kinda give you the same answer. As a result, it took me a while to wrap my head around their differences, and I’m hoping to save someone some time by outlining them.

Read JavaScript for Web Designers by Mat Marquis online. A detailed yet approachable tour around this essential language: pick up syntax rules, the fundamentals of scripting, and much more.

In short, we wanted our list of top web performance recommendations to focus on:

• Recommendations we believe will have the largest real-world impact
• Recommendations that are relevant and applicable to most sites
• Recommendations that are realistic for most developers to implement

Progressive enhancement. Because sometimes your JavaScript just won’t work.

🧞 Phenomenal Cosmic Powers, Itty Bitty Living Space

JavaScript, even if Cached, has significant cost on an end user's device; we'll discuss Disk, Parse, Compilation, IPC, and Bytecode Loading

As we have seen, the for-of loop beats for, for-in, and .forEach() w.r.t. usability.

Any difference in performance between the four looping mechanisms should normally not matter. If it does, you are probably doing something very computationally intensive and switching to WebAssembly may make sense.

As always, the big advice here is whether you're using a framework or not, keep the total amount of JavaScript as small as possible.

It’s rare that you will need to use a JavaScript label. In fact, you can lead a very fulfilling career without ever knowing that this exists. But, on the offhand chance you find that one place where this syntax helps out, you’re now empowered to use it.

Don’t use runtime CSS-in-JS if you care about the load performance of your site. Simply less JS = Faster Site. There isn’t much we can do about it. But if you want to see some numbers, continue reading.

There’s a huge focus recently on JavaScript bundle size: how big are your dependencies? Could you use a smaller one? Could you lazy-load it? But I believe we focus on bundle size first and foremost because it’s easy to measure.

[…] you could imagine some basic stats around initial CPU execution time, memory usage, and disk usage that wouldn’t be impossible to measure in an automated way.

Therefore I use either of the following two approaches if I need a special value:

• I use null as a “switched off” value. (As an aside, this approach is relatively well supported by TypeScript.)
• I avoid both undefined and null via one of the techniques described above. This has the upside of being cleaner and the downside of involving more work.

First-party JavaScript often impacts the interaction readiness of modern pages on the web, but it can often get delayed on the network behind non-critical JS from either first or third-party sources that keep the main thread busy.

Today, ES2017 is the closest to modern syntax and tools such as npm, Babel, webpack, and Rollup have made it possible to configure your build system and write your packages using this syntax. This post covers several approaches, and you should use the easiest option that works for your use case.

If you’re using anti-flicker snippets as part of your experimentation toolset, you should measure how long visitors are being shown a blank screen, with the aim of reducing the timeout values or even removing the anti-flicker snippet completely.

Great site called Operator Lookup that explains how JavaScript operators work. There are some code examples to explain what they do as well, which is pretty handy.

Je suis convaincu que la formation dans les technologies Web de base souffre de lacunes évidentes qui ont conduit à cet état des choses. Cette connaissance essentielle d’HTTP, HTML et CSS fait défaut. Or la réponse à cet engorgement réside dans ce savoir… Il est la clef pour apprendre à se passer de JavaScript.

JavaScript is your behavior layer; the way to add interactivity to your sites, to provide a slick and delightful user experience, to make everything fast and easy and clean. But at some point everything changed: the tail started to wag the dog instead and development became Javascript-first. We'll talk about how you maybe shouldn't rely on JS as much as you're told to, and some practical strategies for how to build sites without reaching for a JS framework as first, last, and only tool for making the web happen.

The techniques at your disposal can be (roughly) grouped into the following types of optimizations:

• Parallel execution (with web workers usually)
• GPU acceleration
• Efficient Arrays and linear algebra routines
• Source compilation + optimization (asm.js, WebAssembly)

And each of these is suited particularly well to overcome a specific performance bottleneck (or use case).