Boris' Bookmarks
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!
Now that you know these metrics, we can use them to understand what’s happening on our sites and to ask better questions.
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.
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 [ ] ^ \ × ÷
… ~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.
Results show that enabling TLS 1.3 is a good idea. It offers more security and better performance for your users. It’s also worth noting that TLS 1.3 will be a requirement to use the QUIC transport layer network protocol in the future. This will pave the way to HTTP/3. And once 0-RTT becomes more prevalent, for repeat website visits the purple on the graphs displayed above will disappear completely. Even faster connections for all (at least for those that use a browser that supports it anyway).
Un précis de vocabulaire pour se rappeler des termes CSS.