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).

This is not a React hit piece, but rather a plea for consideration of how we do our work. Some of these performance pitfalls can be avoided if we take care to evaluate what tools make sense for the job, even for apps with a great deal of complex interactivity.
[…] if you use React or any VDOM library, you should spend some time investigating its impact on an array of devices. Get a cheap Android device and see how your app feels to use. Contrast that experience with your high-end devices.

… ~50% savings compared to JPEG, and ~20% savings compared to WebP.
… can be lossy or lossless, has the ability to use an alpha channel (transparency for UI and design elements), and even has the ability to store a series of animated frames (think lightweight high-quality animated GIFs).
… one of the first image formats to support HDR color support; offering higher brightness, color bit depth, and color gamuts.

content-visibility enables the user agent to skip an element's rendering work, including layout and painting, until it is needed. Because rendering is skipped, if a large portion of your content is off-screen, leveraging the content-visibility property makes the initial user load much faster. It also allows for faster interactions with the on-screen content.

The implementations of Back/Forward caches in popular browsers are helping to improve this experience even further - which has the benefit of significantly speeding up the web for up to 20% of navigations!

Fortunes are made and lost based on how brands thread the needle between site speed and functionality. Despite this, the Retail Systems Research (RSR)’s survey reveals the average retailer’s website is still too slow, and their mobile sites are even slower.

Even worse, many have no idea how they stack up.

Assuming that an optimised 404 page is only required because users will mistype a URL in their browser is short-sighted. As the HTTP Archive data has shown, there are many other reasons why a user may encounter a 404 response (even if they have no idea they actually are!). The web performance impact of a users browser loading an unoptimised 404 page can be huge, and it can have a real impact on their experience of your whole site. All it takes is a forgotten file or misplaced ; in some JavaScript, and your users could be encountering it.

Now that you know these metrics, we can use them to understand what’s happening on our sites and to ask better questions.

Leur donner un nom c’est donner une importance à ce qui ne l’est pas. Le nom n’est pas important. Ce que l’on en fait l’est.

[A-zÀ-ú] // accepts lowercase and uppercase characters
[A-zÀ-ÿ] // as above but including letters with an umlaut (includes [ ] ^ \ × ÷)
[A-Za-zÀ-ÿ] // as above but not including [ ] ^ \
[A-Za-zÀ-ÖØ-öø-ÿ] // as above but not including [ ] ^ \ × ÷