This talk looks at our perception of performance, some of the issues and challenges with our current approach to designing and delivering fast experiences.
[…]
How we design, develop and deliver our pages determines our visitor's experience.

To make sure your animations don’t cause performance issues, consider the impact of animating a given CSS property. Avoid layout recalculations and minimize repaints. Where you can, stick to changing transforms and opacity.

So with a little bit of JavaScript, backend code and some thought, it is possible to deliver your website using less data.

Les fonctionnalités sont nombreuses et permettent d’améliorer grandement l’expérience utilisateur. L’impact écologique est moindre, ce qui n’est pas négligeable non plus.

Yes, we need to better prioritize our asset delivery, but most importantly, we need to stop delivering so much JavaScript. We need to audit our script inventory, and scrutinize our 3rd party integrations regularly, as many of these packages are abandoned or meant to be short-lived.

Pour éviter l’effet de flickering, l’internaute voit une page blanche en attendant que la page définie dans le cadre du test A/B s’exécute et s’affiche. Autrement dit, l’affichage est volontairement ralenti pour éviter de servir une première version de page qui disparaîtrait pour laisser place à celle qui doit s’afficher pour le test.

Let’s take a look at all of the different Resource Hints we have available to us, real-world examples of how best to use them, and learn about some of the more obscure intricacies and gotchas that we need to be aware of if we want to really get the best out of them (and to make sure that we really are being smarter than the browser).

We believe that data from inactive tabs should be considered unnecessary and distorting the picture.

Interesting take, even if I find it ambiguous to use "FirstMeaningfulPaint" for a Custom Metric. The issue with data from inactive tabs once again highlight that one should always back up their RUM findings with Synthetic Monitoring.

Early Flush the HTTP response, for faster head interpretation

Preloading and prefetching to optimize Instagram feed performance

DOM reflow or layout thrashing should always be kept at a minimum in order to increase performance and provide a fluid, nonblocking user experience.

Stop using cookieless domains, start migrating to HTTP/2!

For 27 years, JPEG has been the workhorse image format. While universally adopted, it doesn’t address many modern use cases including high dynamic range (HDR), transparency, responsive web, lossless and others.

We now track a Page Performance Score based off of four user-centric metrics: (TT)FCP, (TT)FMP, FID, and TBT.

Webpages can be good citizens of battery life. It’s important to measure the battery impact in Web Inspector and drive those costs down. Doing so improves the user experience and battery life.

[Apart from 2 very specific cases where treatments needed to be done without the user request] I have seen exactly zero other instances where Web Workers would have improved the user experience.

Cumulative Layout Shift (CLS) is a relatively new metric to help you understand the delightfulness of the user experience.

This way all the users will have to download upfront is the cover image, which seems pretty reasonable to me.

Predicting what our users will do next is difficult, and it certainly requires a lot of planning and testing. But, the performance benefits are definitely worth chasing.

Adding rel=preconnect to a <link> informs the browser that your page intends to establish a connection to another domain, and that you'd like the process to start as soon as possible.