Boris' Bookmarks
We intuitively know that faster is better, but what's the psychology and physiology behind it?
I recommend the part on how to curb the JS tax (14:48).
Blurhash strings are short enough to be added as a field in a JSON object and to be stored in a database. The implementations are small and easy to port to new languages, and the end result is a smooth and interesting experience for your users.
Instantly test how accessible your experience is with the real assistive technologies your disabled users rely on — screen readers, magnifiers, and more — from any computer.
Slowfil.es generates URLs for slow ressources
Quand on vend une prestation de plusieurs mois, quelques petites erreurs de négociation peuvent occasionner des pertes financières qui se chiffrent en milliers voire dizaines de milliers d'euros.
À l'inverse, cinq minutes d'efforts et d’opiniâtreté peuvent rapporter gros ; on aurait tort de s'en priver.
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.
It is great to see Google create a new Page Experience signal using a brilliant object-oriented approach. I think it is smart, flexible, and scalable. That said, in my opinion, the signal must have teeth in order for it to be taken seriously by site owners, developers, and SEOs. If not, it can fall by the wayside.
A great way to get a RUM overview of a page’s performance, at low cost, very quickly.
We need an alternative to JPEG that a) is widely supported, b) has better compression efficiency and c) has a wider feature set. We believe AV1 Image File Format (AVIF) has the potential. Using the framework we have open sourced, AVIF compression efficiency can be seen at work and compared against a whole range of image codecs that came before it.
Already cached local assets like Google Fonts will no longer serve from cache again when loading from a 2nd site.
Being able to run Google’s Lighthouse analysis suite programmatically provides a lot of advantages, especially for larger or more complex web applications. Using Lighthouse programmatically allows engineers to set up quality monitoring for sites that need more customization than straightforward applications of Lighthouse (such as Lighthouse CI) allow.
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.
I was a initially sceptical of AVIF – I don't like the idea that the web has to pick up the scraps left by video formats. But wow, I'm seriously impressed with the results above.
Have you ever looked at the Network Panel in DevTools, or a waterfall in WebPageTest and wondered what determines the order of the resources, and how you can influence it?
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).
content-visibilityenables 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.
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.
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.
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!