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.
Alex posted a follow-up to a prior post on avoiding scrollbar jumping when using content-visibility.
It’s clever stuff—the combination of ResizeObservers and IntersectionObservers helping to avoid the shifting around that would occur otherwise.
This doesn’t do much though to eliminate the reservations I have about content-visibility. In theory, it’s a great addition, but the fact that it seems to need so much supporting scaffolding to make it usable for a relatively simple use-case makes me feel like it may be missing a few other pieces of native plumbing before it’s really ready for primetime.
Sad, but true words:
For a few months, those who will buy M1 machines will enjoy great responsiveness and blazing start-up time. Some once bloated applications will again behave like most tools should. But soon these metrics will start to degrade. Responsiveness and start-up time will progressively revert to what they used to be and old “non-M1” machines will become even slower than they used to.
For every cycle a hardware engineer saves, a software engineer will add two instructions.
Imagine that situation. You buy a computer. It comes with one web browser pre-installed. You can’t install a different web browser on your computer.
You wouldn’t stand for it! I mean, Microsoft got fined for anti-competitive behaviour when they pre-bundled their web browser with Windows back in the 90s. You could still install other browsers, but just the act of pre-bundling was seen as an abuse of power. Imagine if Windows never allowed you to install Netscape Navigator?
And yet that’s exactly the situation in 2020.
You buy a computing device from Apple. It might be a Macbook. It might be an iPad. It might be an iPhone. But you can only install your choice of web browser on one of those devices.
Super clever stuff from Andy about how he’s using Cloudflare Workers and WebPageTest to test performance optimizations. I’ve done a little of this, but there’s a bunch here I haven’t played with. Going to have to change that for sure!
I’ve been super keen on getting some sort of way to measure when the accessibility tree is ready ever since first chatting about it with Marcy Sutton 5 years ago or so. Scott has a great post here about why it’s important. He’s also filed issues on WebPageTest and Lighthouse to get something added. Hopefully we’ll see something soon!