Speed for the sake of speed means nothing. If our design systems don’t ultimately lead to better quality experiences, we’re doing it wrong.
When we rush to release one-size-fits-all components, without doing the work to understand different contexts before curating and consolidating solutions, we sacrifice quality at the hands of speed.
The irony? In the long run, this will slow us down. We end up having to undo the work we’ve done to fix the problems we’ve created.
Ultimately, when we prioritise speed over quality, we end up with neither.
The paradox of performance:
This era of incredibly fast hardware is also the era of programs that take tens of seconds to start from an SSD or NVMe disk; of bloated web applications that take many seconds to show a simple list, even on a broadband connection; of programs that process data at a thousandth of the speed we should expect. Software is laggy and sluggish — and the situation shows little signs of improvement. Why is that?
Because we prioritise the developer experience over the user experience, that’s why:
Although our job is ostensibly to create programs that let users do stuff with their computers, we place a greater emphasis on the development process and dev-oriented concerns than on the final user product.
We would do well to heed Craig’s observations on Fast Software, the Best Software.
This is a tagline I can get behind:
CSS-in-JS can have a noticeable impact on your webpage. Mainly for low-end devices and regions with a slower internet connection or more expensive data. So maybe we should think better about what and how we use our tooling. Great developer experience shouldn’t come at the expense of the user experience.
Modern web development:
Imagine you went to a restaurant, took a seat, and 20 minutes later you still haven’t been given a menu. You ask where it is, and you’re told “oh, we’re currently cooking you everything you might possibly ask for. Then we’ll give you the menu, you’ll pick something, and we’ll be able to give you it instantly, because it’ll all be ready”.
Single page apps, ladies and gentlemen.
I hadn’t come across this before—run Lighthouse tests on your pages from six different locations around the world at once.
My current score is one minute and 18 seconds. Can you beat it?
This is terrific! Jeremy shows how you can implement a fairly straightforward service worker for performance gains, but then really kicks it up a notch with a recipe for turning a regular website into a speedy single page app without framework bloat.
Developers, particularly in Silicon Valley firms, are definitionally wealthy and enfranchised by world-historical standards. Like upper classes of yore, comfort (“DX”) comes with courtiers happy to declare how important comfort must surely be. It’s bunk, or at least most of it is.
As frontenders, our task is to make services that work well for all, not just the wealthy. If improvements in our tools or our comfort actually deliver improvements in that direction, so much the better. But we must never forget that measurable improvement for users is the yardstick.
This could give a big boost to web performance!
You don’t have to use web fonts—there are some pretty nice options if you stick to system fonts (like Georgia, Charter, and Palatino).
A terrific in-depth look at improving the performance of web fonts.
This is great! The folks at Basecamp are releasing the front-end frameworks they use to build Hey. There’s Turbo—the successor to Turbolinks:
It offers a simpler alternative to the prevailing client-side frameworks which put all the logic in the front-end and confine the server side of your app to being little more than a JSON API.
With Turbo, you let the server deliver HTML directly, which means all the logic for checking permissions, interacting directly with your domain model, and everything else that goes into programming an application can happen more or less exclusively within your favorite programming language. You’re no longer mirroring logic on both sides of a JSON divide. All the logic lives on the server, and the browser deals just with the final HTML.
Yes, this is basically Hijax (which is itself simply a name for progressive enhancement applied to Ajax) and I’m totally fine with that. I don’t care what it’s called when the end result is faster, more resilient websites.
Compare and contrast the simplicity of the Hotwire/Turbo approach to the knots that React is tying itself up in to try to get the same performance benefits.
Good news: as of May 2021, page speed (or core web vitals, if you must) will be a ranking factor in Google Search.
Even better news: at the same time, Google AMP will lose its unfairly privileged position in the top stories carousel. Hopefully this marks the beginning of the end for Google’s failed experiment in forcing publishers to use their tech.
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 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.
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.
I think Simon is onto something here. While the word “performance” means something amongst devs, it’s too vague to be useful when communicating with other disciplines. I like the idea of using the more descriptive “page speed” or “site speed” in those situations.
Web Performance and Web Performance Optimization are still valid and descriptive terms for our industry, but we might benefit from a change to our language when working with others. The language we use could be critical to the success of making the web a faster and more accessible place.