I’d maybe simplify this people problem a bit: the codebase is easy to change, but the incentives within a company are not. And yet it’s the incentives that drive what kind of code gets written — what is acceptable, what needs to get fixed, how people work together. In short, we cannot be expected to fix the code without fixing the organization, too.
Did you know there’s an
imagesrcset attribute you can put on
link rel="preload" as="image" (along with an
I didn’t. (Until Amber pointed this out.)
There’s a new image format on the browser block and it’s very performant indeed. Jake has all the details you didn’t ask for.
The problem is that most websites will adapt to the ever faster connections, which makes them gradually inaccessible for people with slower connections. Today, most websites are impossible to download with a dial-up connection, because they have become too corpulent.
This speaks to me:
Everything we do to make it harder to create a website or edit a web page, and harder to learn to code by viewing source, promotes that consumerist vision of the web.
Pretending that one needs a team of professionals to put simple articles online will become a self-fulfilling prophecy. Overcomplicating the web means lifting up the ladder that used to make it possible for people to teach themselves and surprise everyone with unexpected new ideas.
There’s a list of links at the end of this piece to help you reach this goal:
It is vital that the web stay participatory. That means not just making sites small enough so the whole world can visit them, but small enough so that people can learn to build their own, by example. Bloat makes the web inaccessible.
This is a really good description of the role of a front-end developer.
That’s front end, not full stack.
As a web designer or developer burnout comes calling when you try to do good work, but you’re not allowed.
- You want to make the app more performant; your boss wants to fill it full of third party trackers
- You want to make the app more accessible; your boss wants you to focus on the ‘able market’ instead
- You want to word the app more clearly; your boss wants to trick users with misleading language
If you are a good developer, and a good person, asked to do shit work, you will burn out.
So, why would you want to use a service worker? Here are some cool things you can do with it.
Chris lists some of the ways a service worker can enhance user experience.
Smashing Podcast Episode 21 With Chris Ferdinandi: Are Modern Best Practices Bad For The Web? — Smashing Magazine
I really enjoyed this interview between Drew and Chris. I love that there’s a transcript so you can read the whole thing if you don’t feel like huffduffing it.
This is an interesting project to try to rank web hosts by performance:
Real-world server response (Time to First Byte) latencies, as experienced by real-world users navigating the web.
A heartfelt look at progressive enhancement:
Some look at progressive enhancement like a thing from the past of which the old guard just can’t let go. But to me, progressive enhancement is the future of the Web. It is the basis for building resilient, performant, interoperable, secure, usable, accessible, and thus inclusive experiences. Not only for the Web of today but for the ever-growing complexity of an ever-changing and ever-evolving Web.
Google could have approached the “be better on mobile” problem, search optimization and revenue sharing any number of ways, obviously, but the one they’ve chosen and built out is the one that guarantees that either you let them middleman all of your traffic or they cut off your oxygen.
There’s also this observation, which is spot-on:
Google has managed to structure this surveillance-and-value-extraction machine entirely out of people who are convinced that they, personally, are doing good for the world. The stuff they’re working on isn’t that bad – we’ve got such beautiful intentions!
Good point. When we talk about perceived performance, the perception in question is almost always visual. We should think more inclusively than that.
But if I were going to bet on a web technology, it’s HTML. Always bet on HTML.
If you’re in a group of people being chased by a bear, you only need to be faster than the slowest person in the group. But that’s not how websites work: being faster than at least one other website, or even faster than the ‘average’ website, is not a great achievement when the average website speed is frustratingly slow.
This is excellent news for sites that were strong-armed into creating AMP pages just to get into the Top Stories carousel:
As part of this update, we’ll also incorporate the page experience metrics into our ranking criteria for the Top Stories feature in Search on mobile, and remove the AMP requirement from Top Stories eligibility.
This update doesn’t arrive until next year, but the message is clear: fast websites will be rewarded in search. I’ll be glad to see an end to AMP’s blackmail tactics.
Chris has put together one of his indispensable deep dives, this time into responsive images. I can see myself referring back to this when I need to be reminded of the syntax of
Scott is brilliant, therefore by the transitive property, his course on web performance must also be brilliant.
- Opted out experiences are ~35% faster
- Opted in repeat views are twice as slow as opted out