I was darn impressed by Scott Jehl’s personal charge to bring back an idea known as “responsive video”. If you’ve seen the <picture> element, and how you can provide multiple <source>s with different @media queries allowing for only the best match to be shown, you already get it. It turns out that browsers, at one time, sensibly thought that was a good idea and it made it to browsers, then it got ripped out for not-great reasons, and Scott wanted it back.
Instead of just writing snarky blog posts like I would do, or using my best pretty please eyes on people I think could help, Scott just rolled up his sleeves and did it.
First, he had to kick it back up in the working group, the WhatWG as it’s called, and get conversation going. Conversation did get going, but then it died away. For years. That’s just how it goes sometimes. But by some stroke of luck, it kicked back up again and the spark moment happened:
… representatives from Firefox and Chrome chimed in to say that they agreed and intend to reinstate their support! Following that, implementation bugs were filed in the Chromium and Firefox trackers.
You might think first things get into “the spec” then browsers agree to implement them. But it’s actually the other way around. Now that the agreement to implement was in, the spec was appended to put responsive video back in.
Phew! That’s a lot!
But wait!
Just because browsers agree and the spec is updated still doesn’t mean it’s actually going to happen anytime soon. Because someone still needs to roll up their sleeves and actually do it. As an aside, I assume that’s why Igalia is so successful and involved in so many things like this — because they do the doing.
In this case, the doer of the doing was… Scott.
The tricky part is that writing code for web sites and web browsers is very different. Scott tackled Firefox, which is C++.
Following the initial steps, it took my aging Macbook Pro at least a few hours to clone and build Firefox Nightly, but I was pleased to see it all work without any trouble. After that, I moved on to reinstating the C++ code that would enable media attribute support in video
sourceelements.
Fortunately, by the good graces of open source, Scott was able to find the old commits where these features were added/removed, so he had a starting point. But there ended up being a lot more to it, and I think through Scott’s intelligence, enthusiasm, and sheer will, he got it all pushed through! He was about the do Chrome but they ended up doing it themselves. Cool!
Well! I accidentally re-blogged Scott’s blog post. Oops. Sorry Scott. But that tees us up for a few more performance related links.
Rick Viscomi has a good overview of web performance, how to think about it, and whats going on as we start 2024. Unlike the accessibility world where status quo or regressions are sadly common, there is some slow movement forward:
At the start of 2023, 40.1% of websites passed the Core Web Vitals assessment for mobile user experiences. Since then, we’ve seen steady growth. As of September 2023, we’re at 42.5% of websites passing the Core Web Vitals assessment, an improvement of 2.4 percentage points, or 6.0%. This is a new high, representing an incredible amount of work by the entire web ecosystem.
2.4% movement of the entire web seems pretty darn good to me.
The post is loaded with more data and information. I found this bit about image performance interesting.
The slowest part is actually the resource load delay. Therefore, the biggest opportunity to speed up slow LCP images is to load them sooner. To reiterate, the problem is less about how long the image takes to load, it’s that we’re not loading it soon enough.
We often think so much about the image size and format as being so vital to image performance, but them not loading soon enough is like a 4× bigger issue overall. There are all sorts of things hurting this. Entirely clienet-side rendered apps hurt this. Using loading="lazy" on an image included in the “Largest Contentful Paint” hurts this, too. You can fight back with a rel="preload" thing, but better to avoid the problem at all if you can.
Speaking of image performance, Tim Severien asks: Should AVIF be the dominant image format on the web? It’s very complicated, ultimately a little subjective, and varies with type of image and your goals. My brain loves declaring a winner, but I’m afraid that’s not going to happen here. This didn’t get into stuff like the computational cost, which I always understood to be much higher with AVIF. I like the idea of tools that make the call based on individual images.
There are so many “why”s of web performance. They are all good, like it’s good for business because it makes the site feel more reliable and trustworthy, and people don’t get distracted waiting for things, meaning less abandonment. It’s good for the planet (less carbon emissions). It’s good for accessibility (more people can use the site on slow connections).
It’s also just… in our brains. Tammy Everts says:
If you don’t consider time a crucial usability factor, you’re missing a fundamental aspect of the user experience.
Her research, and citing the research of others, shows just about important all this is. We’re just impatient beings, and it hasn’t changed over time, and isn’t likely to.
The internet may change, and web pages may grow and evolve, but user expectations are constant. The numbers about human perception and response times have been consistent for more than 45 years. These numbers are hard-wired. We have zero control over them. They are consistent regardless of the type of device, application, or connection we are using at any given moment.
A lot of us have some locked-in knowledge that document.write() is bad and should never be used. It must be some maxim from the early days of people taking web performance seriously. Harry Roberts dug into that and explains exactly why, as it’s still definitely true.
Bonus:
1MB Club is a growing collection of performance-focused web pages weighing less than 1 megabyte.