There's been two really interesting videos released recently that use the "Local Overrides" feature of Chrome DevTools in order to play with web performance without even touching the original source code.
- Umar Hansa: Improving the performance of Soylent.com with local overrides and font-display
- Harry Roberts: Using Chrome’s ‘Local Overrides’ to Test Performance Hypotheses
The big idea is that you can literally edit CSS and reload the page and your changes stick. Meaning you can use the other performance testing tools inside DevTools to see if your changes had the effect you wanted them to have. Great for showing a client a change without them having to set up a whole dev environment for you.
There’s a lot of good news in the world of web fonts!
- The forthcoming version of Microsoft Edge will finally implement
unicode-range, the last modern browser to do so.
- Preload and
font-displayare landing in Safari and Firefox.
- Variable fonts are shipping everywhere.
Using custom fonts in a performant way is becoming far easier. Let’s take a peek at some things we can do when using custom fonts to make sure we’re being as performant as we can be.
My latest realization is that delivering a performant, accessible, responsive, scalable website isn’t enough: I also need to consider the impact of third-party scripts. No matter how solid I think my prototype is, it doesn’t absolve me from paying attention to what happens during implementation, specifically when it comes to the addition of these third-party scripts.
I recently had a conversation with a friend working on quite a high profile e-commerce site. They were hired to develop the site, but particularly with performance in mind. They were going the PWA route, but were immediately hamstrung by third-party scripts. One of them, apparently unavoidably, couldn't be HTTPS, meaning the site was immediately disqualified from being a PWA. They could still do a good job in many other areas, but right and left their great performance work was slaughtered by third-party scripts. I don't envy being in that position.
From Johnny's dev blog:
The challenge: Calculate the real percentage of unused CSS
Our goal is to create a script that will measure the percentage of unused CSS of this page. Notice that the user can interact with the page and navigate using the different tabs.
DevTools can be used to measure the amount of unused CSS in the page using the Coverage tab. Notice that the percentage of unused CSS after the page loads is ~55%, but after clicking on each of the tabs, more CSS rules are applied and the percentage drops down to just ~15%.
That's why I'm so skeptical of anything that attempts to measure "unused CSS." This is an incredibly simple demo (all it does is click some tabs) and the amount of unused CSS changes dramatically.
Vitaly Friedman swings wide with a massive list of performance considerations. It's a well-considered mix of old tactics (cutting the mustard, progressive enhancement, etc.) and newer considerations (tree shaking, prefetching, etc.). I like the inclusion of a quick wins section since so much can be done for little effort; it's important to do those things before getting buried in more difficult performance tasks.
Speaking of considering performance, Philip Walton recently dug into what interactive actually means, in a world where we throw around acronyms like TTI:
But what exactly does the term “interactivity” mean?
I think most people reading this article probably know what the word “interactivity” means in general. The problem is, in recent years the word has been given a technical meaning (e.g. in the metric “Time to Interactive” or TTI), and unfortunately the specifics of that meaning are rarely explained.
Also, if you're into front-end checklists, check out David Dias' Front-End Checklist.
That said, it isn’t as easy to get started with the API as it is to actually use it. Although I’ve seen extensions of it covered here and there in other posts, the big picture that ties everything together is hard to find.
Popular image file formats such as JPG, PNG, and GIF have been around for a long time. They are relatively efficient and web developers have introduced many optimization solutions to further compress their size. However, the era of JPGs, PNGs, and GIFs may be coming to an end as newer, more efficient image file formats aim to take their place.
We're going to explore these newer file formats in this post along with an analysis of how they stack up against one another and the previous formats. We will also cover optimization techniques to improve the delivery of your images.
With CSS filter effects and blend modes, we can now leverage various techniques for styling images directly in the browser. However, creating aesthetic theming isn't all that filter effects are good for. You can use filters to indicate hover state, hide passwords, and now—for web performance.
While playing with profiling performance wins of using blend modes for duotone image effects (I'll write up an article on this soon), I discovered something even more exciting. A major image optimization win! The idea is to reduce image contrast in the source image, reducing its file size, then boosting the contrast back up with CSS filters!
The breadth and depth of knowledge to absorb in the web performance space is ridiculous. At a minimum, I'm discovering something new nearly every week. Case in point: The
Save-Data header, which I discovered via a Google Developers article by Ilya Grigorik.
If you're looking for the tl;dr version of how
Save-Data works, let me oblige you: If you opt into data savings on the Android version of Chrome (or the Data Saver extension on your desktop device), every request that Chrome sends to a server will contain a
Save-Data header with a value of
On. You can then act on this header to change your site's content delivery in such a way that conserves data for the user. This is a very open-ended sort of opportunity that you're being given, so let's explore a few ways that you could act on the
Save-Data header to send less bytes down the wire!