Very good overview of the preload issue from Shubhie. This bit in particular is important to take to heart, I think:
Preload can be avoided in many cases, with alternative strategies such as inlining of critical CSS and inlining font-css.
Most of the time, preload gets used as a (not particularly efficient) band-aid for an underlying issue that is probably better solved in other ways.
Also, this is probably a personal hang-up, but whenever someone from the Chrome team shares a Google Doc full of interesting research and ideas (which is super often) I always feel a little anxiety. I just don’t trust these docs to stick around as long as a blog post.
Adding a ‘show password’ option to GOV.UK Accounts seemed like a straightforward task, but the more we looked into it the more complicated and interesting it became. This is how we did it and some of the challenges we faced.
More fodder for my firm belief that the closer you look at anything, the more interesting it becomes.
Apple’s iOS browser (Safari) and engine (WebKit) are uniquely under-powered. Consistent delays in delivery of important features ensure the web can never be a credible alternative to its proprietary tools and App Store.
Heckuva leading assertion from Alex, but he brings some serious data to back it up, including some pretty compelling results from the Web Platform Tests.
There’s a lot of criticism levied at Chrome and how they move through the standards process (or don’t). Some of that criticism is fair, some of it isn’t.
But it’s pretty clear, I think, that we have a mismatch of resources creating an imbalance. On the one hand, we have Google funding the heck out of their web-focused efforts. On the other hand, we have Apple that just never seems willing to invest in it much.
The result isn’t particularly healthy for the web or for anyone who uses it. Alex’s point here rings true:
It’s perverse that users and developers everywhere pay a subsidy for Apple’s under-funding of Safari/WebKit development.
The 95th percentile of RUM data is a great place to assess the slowest experiences. In this case, we see that the streaming Service Worker confers a 40% and 51% improvement in FCP and LCP, respectively, over no Service Worker at all. Compared to the “standard” Service Worker, we see a reduction in FCP and LCP by 19% and 43%, respectively.
What a fantastic article from Jess Peck on Cumulative Layout Shift. It’s approachable to folks new to the metric, detailed and in-depth and wildly entertaining (more entertaining than a post this informative has any right to be).
An in-depth, well researched guide to measuring Core Web Vitals from Barry (par for the course for him).
I love it when someone takes a specific problem (in this case, adding text labels to buttons in an accessible way, and then digs deep into solving it.
This is a terrific post by Sara, where she dives into making “Add to Cart” (and other generic text labels) more accessible to both screen readers and dictation services.
Huh. So Stefan’s today I learned is now my today I learned. Apparently links have a ping attribute that you can tell the browser to send a POST request to when a link is clicked.
Again, if you’re certain that you’re speaking to peers, that’s fine. But if you’re trying to communicate even a little more widely, then initialisms and abbreviations are obstacles to overcome. And once you’re in the habit of using the short forms, it gets harder and harder to apply context-shifting in your language. So the safest habit to form is to generally avoid using acronyms and initialisms.
This is a good reminder from Jeremy. He mentions performance in particular (we do love our acronyms). I try to avoid this, but I know I’ve been guilty of it many times. Something to improve on for sur.
A smart little list of optimizations for loading images efficiently. Using the bytes if the image as a hash for automatic cache busting if the image changes is particularly clever.