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.
Monday, June 1st, 2020
Friday, May 29th, 2020
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
Saturday, May 23rd, 2020
Scott is brilliant, therefore by the transitive property, his course on web performance must also be brilliant.
Tuesday, May 19th, 2020
- Opted out experiences are ~35% faster
- Opted in repeat views are twice as slow as opted out
Monday, May 18th, 2020
Hard to break
I keep thinking about some feedback that Cassie received recently.
She had delivered the front-end code for a project at Clearleft, and—this being Cassie we’re talking about—the code was rock solid. The client’s Quality Assurance team came back with the verdict that it was “hard to break.”
Hard to break. I love that. That might be the best summation I’ve heard for describing resilience on the web.
If there’s a corollary to resilient web design, it would be brittle web design. In a piece completely unrelated to web development, Jamais Cascio describes brittle systems:
When something is brittle, it’s susceptible to sudden and catastrophic failure.
That sounds like an inarguably bad thing. So why would anyone end up building something in a brittle way? Jamais Cascio continues:
Things that are brittle look strong, may even be strong, until they hit a breaking point, then everything falls apart.
Ah, there’s the rub! It’s not that brittle sites don’t work. They work just fine …until they don’t.
Brittle systems are solid until they’re not. Brittleness is illusory strength. Things that are brittle are non-resilient, sometimes even anti-resilient — they can make resilience more difficult.
Kilian Valkhof makes the same point when it comes to front-end development. For many, accessibility is an unknown unknown:
When you start out it’s you, notepad and a browser against the world. You open up that notepad, and you type
<div onclick="alert('hello world');">Click me!</div>
You fire up your browser, you click your div and …it works! It just works! Awesome. You open up the devtools. No errors. Well done! Clearly you did a good job. On to the next thing.
At the surface level, there’s no discernable difference between a resilient solution and a brittle one:
For all sorts of reasons, both legitimate and, as always, weird browser legacy reasons, a clickable
divwill mostly work. Well enough to fool someone starting out anyway.
If everything works, how would they know it kinda doesn’t?
Killian goes on to suggest ways to try to make this kind of hidden brittleness more visible.
Furthermore we could envision a browser that is much stricter when developing.
This something I touched on when I was talking about web performance with Gerry on his podcast:
There’s a disconnect in the process we go through when we’re making something, and then how that thing is experienced when it’s actually on the web, which is dependent on network speeds and processing speeds and stuff.
I spend a lot of time wondering why so many websites are badly built. Sure, there’s a lot can be explained by misaligned priorities. And it could just be an expression of Sturgeon’s Law—90% of websites are crap because 90% of everything is crap. But I’ve also come to realise that even though resilience is the antithesis to brittleness, they both share something in common: they’re invisible.
We have a natural bias towards what’s visible. Being committed to making sure something is beautiful to behold is, in some ways, the easy path to travel. But being committed to making sure something is also hard to break? That takes real dedication.
Monday, May 11th, 2020
I’m at the point where you look at where the field is and what the alternatives are – taking a second look at unloved, unpopular, uncool things like Django, Rails, Laravel – and think what the heck is happening. We’re layering optimizations upon optimizations in order to get the SPA-like pattern to fit every use case, and I’m not sure that it is, well, worth it.
Spot-on analysis of what React is and isn’t good for. And lest you think this is blasphemy, Dan Abramov agrees.
Friday, May 8th, 2020
Trys describes the backend architecture of the excellent Sofa Conf website. In short, it’s a Jamstack dream: all of the convenience and familiarity of using a database-driven CMS (Craft), combined with all the speed and resilience of using a static site generator (Eleventy).
I love the fact that anyone on the Clearleft events team can push to production with a Slack message.
I also love that the site is Lighthousetastically fast.
Tuesday, May 5th, 2020
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.
Friday, May 1st, 2020
Some great practical examples of progressive enhancement on one website:
- using grid layout in CSS,
- using the
pictureelement to provide
webpimages in HTML.
All of those enhancements work great in modern browsers, but the underlying functionality is still available to a browser like Opera Mini on a feature phone.
Thursday, April 30th, 2020
This is a great case study of the excellent California COVID-19 response site. Accessibility and performance are the watchwords here.
Want to know their secret weapon?
A $20 device running Android 9, with no contract commitment has been one of the most useful and effective tools in our effort to be accessible.
Leaner, faster sites benefit everybody, but making sure your applications run smoothly on low-end hardware makes a massive difference for those users.
Tuesday, April 28th, 2020
Great typography on the web should be designed in layers. The web is an imperfect medium, consumed by countless different devices over untold numbers of network connections—each with their own capabilities, limitations, and peculiarities. To think that you can create one solution that will look and work the same everywhere is a fantasy. To make this more than just one nice book website, the whole project and process needs to embrace this reality.
Monday, April 27th, 2020
The cost of “modern” web development:
We’re dealing with the results of bad defaults, deployed at a terrible scale.
Frankly, it’s hard for me not to see this as a failure of governance. Our industry is, by and large, self-regulated. And right now, producing quality work relies on teams electing to adopt best practices.
Last week I wrote about the great work that Matthew did and now he’s written up his process:
Saturday, April 25th, 2020
At the beginning of the year, Remy wrote about extracting Goodreads metadata so he could create his end-of-year reading list. More recently, Mark Llobrera wrote about how he created a visualisation of his reading history. In his case, he’s using JSON to store the information.
This kind of JSON storage is exactly what Tom Critchlow proposes in his post, Library JSON - A Proposal for a Decentralized Goodreads:
Thinking through building some kind of “web of books” I realized that we could use something similar to RSS to build a kind of decentralized GoodReads powered by indie sites and an underlying easy to parse format.
His proposal looks kind of similar to what Mark came up with. There’s a title, an author, an image, and some kind of date for when you started and/or finished reading the book.
Matt then points out that RSS gets close to the data format being suggested and asks how about using RSS?:
Rather than inventing a new format, my suggestion is that this is RSS plus an extension to deal with books. This is analogous to how the podcast feeds are specified: they are RSS plus custom tags.
Like Matt, I’m in favour of re-using existing wheels rather than inventing new ones, mostly to avoid a 927 situation.
But all of these proposals—whether JSON or RSS—involve the creation of a separate file, and yet the information is originally published in HTML. Along the lines of Matt’s idea, I could imagine extending the
h-entry collection of class names to allow for books (or films, or other media). It already handles images (with
u-photo). I think the missing fields are the date-related ones: when you start and finish reading. Those fields are present in a different microformat,
h-event in the form of
dt-end. Maybe they could be combined:
<article class="h-entry h-event h-review"> <h1 class="p-name p-item">Book title</h1> <img class="u-photo" src="image.jpg" alt="Book cover."> <p class="p-summary h-card">Book author</p> <time class="dt-start" datetime="YYYY-MM-DD">Start date</time> <time class="dt-end" datetime="YYYY-MM-DD">End date</time> <div class="e-content">Remarks</div> <data class="p-rating" value="5">★★★★★</data> <time class="dt-published" datetime="YYYY-MM-DDThh:mm">Date of this post</time> </article>
That markup is simultaneously a post (
h-entry) and an event (
h-event) and you can even throw in
h-card for the book author (as well as
h-review if you like to rate the books you read). It can be converted to RSS and also converted to
.ics for calendars—those parsers are already out there. It’s ready for aggregation and it’s ready for visualisation.
I publish very minimal reading posts here on adactio.com. What little data is there isn’t very structured—I don’t even separate the book title from the author. But maybe I’ll have a little play around with turning these h-entries into combined h-entry/event posts.
Thursday, April 23rd, 2020
It’s been fascinating to see how television programmes have adapted to The Situation. It’s like there’s been a weird inversion with the YouTube asthetic. Instead of YouTubers doing their utmost to emulate the look of professional television, now everyone on professional television looks like a YouTuber.
No more lighting or audio technicians. No more studio audiences. Heck, no more studios.
There are some kinds of TV programmes that are showing the strain. A lot of comedy formats just fall flat without the usual production values. But a lot of programmes work just fine. In fact, some of them might be better. Watching Mary Beard present Front Row Late from her house is an absolute delight. It feels more direct and honest without the artiface of a television studio. It kind of makes you wonder whether expensive production costs are really necessary when what you really care about is the content.
All of this is one big belaboured metaphor for websites.
In times of crisis, informational websites sometimes offer a “lite” version. Max has even made an emergency website kit:
The site contains only the bare minimum - no webfonts, no tracking, no unnecessary images. The entire thing should fit in a single HTTP request. It’s basically just a small, ultra-lean blog focused on maximum resilience and accessibility. The Service Worker takes it a step further from there so if you’ve visited the site once, the information is still accessible even if you lose network coverage.
Eric emphasises the importance of performance in his post Get Static:
I’m thinking here of sites for places like health departments (and pretty much all government services), hospitals and clinics, utility services, food delivery and ordering, and I’m sure there are more that haven’t occurred to me. As much as you possibly can, get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and pare away every byte you can.
Tom Loosemore offers this advice to teams building new coronavirus services:
- Get a 4 year-old Android phone, and use it as your test/demo device.
- https://design-system.service.gov.uk is your friend.
- Full React isn’t your friend if it makes your service slow & inaccessible
Remember: This is for everyone.
Indeed, Gov.uk are usually a paragon of best practices in just about any situation. But they dropped the ball recently, as Matthew attests:
One sign that your website isn’t meeting the needs of all your users is when Matthew Somerville gets sufficiently grumpy about it to do a proper version himself.
It’s true enough that Matthew excels at creating lightweight, accessible versions of services that are too bloated or buggy to use. His accessible Odeon project from back in the day is legendary. And I use his slimline version of the National Rail website all the time: traintimes.org.uk—it’s a terrificly performant progressive web app.
Maybe now, with this rush to make lightweight versions of valuable services, we might stop and reflect on whether we ever really needed all those added extras in the first place.
Hope springs eternal.
Update: Matthew has written about his process in Looking at coronavirus.data.gov.uk.
Excellent in-depth research by Tim on how the major frameworks affect performance. There are some surprising (and some unsurprising) findings in here.
I wish with all my heart that this data would have some effect but I fear there’s an entire culture of “modern” web development that stick its fingers in its ears and say “La, la, la, I can’t hear you.”
A great little mini case-study from Eric—if you’re exporting transparent PNGs from a graphic design tool, double-check the colour-depth settings!
I’d been saving the PNGs with no bit depth restrictions, meaning the color table was holding space for 224 colors. That’s… a lot of colors, roughly 224 of which I wasn’t actually using.
I never thought of combining the
datalist element with
input type="color"—it’s pretty cool that it just works!
Monday, April 20th, 2020
I think a lot about Danielle’s talk at Patterns Day last year.
Gaps are where hidden complexity live. If we don’t have a category to cover it, in effect it becomes invisible. But that doesn’t mean it’s not there. Unidentified gaps cause inconsistency and confusion.
Overlaps occur when two separate categories encompass some of the same areas of responsibility. They cause conflict, duplication of effort, and unnecessary friction.
This is the bit I keep thinking about. It’s such an insightful lens to view things through. On just about any project, tensions are almost due to either gaps (“I thought someone else was doing that”) or overlaps (“Oh, you’re doing that? I thought we were doing that”).
When I was talking to Gerry on his new podcast recently, we were trying to figure out why web performance is in such a woeful state. I mused that there may be a gap. Perhaps designers think it’s a technical problem and developers think it’s a design problem. I guess you could try to bridge this gap by having someone whose job is to focus entirely on performance. But I suspect the better—but harder—solution is to create a shared culture of performance, of the kind Lara wrote about in her book:
Performance is truly everyone’s responsibility. Anyone who affects the user experience of a site has a relationship to how it performs. While it’s possible for you to single-handedly build and maintain an incredibly fast experience, you’d be constantly fighting an uphill battle when other contributors touch the site and make changes, or as the Web continues to evolve.
I suspect there’s a similar ownership gap at play when it comes to the ubiquitous obtrusive overlays that are plastered on so many websites these days.
Kirill Grouchnikov recently published a gallery of screenshots showcasing the beauty of modern mobile websites:
There are two things common between the websites in these screenshots that I took yesterday.
- They are beautifully designed, with great typography, clear branding, all optimized for readability.
- I had to install Firefox, Adblock Plus and uBlock Origin, as well as manually select and remove additional elements such as subscription overlays.
The web can be beautiful. Except it’s not right now.
How is this dissonance possible? How can designers and developers who clearly care about the user experience be responsible for unleashing such user-hostile interfaces?
I get that. But surely the solution can’t be to shrug our shoulders, pass the buck, and say “not my job.” Somebody designed each one of those obtrusive overlays. Somebody coded up each one and pushed them into production.
It’s clear that this is a problem of communication and understanding, rather than a technical problem. As always. We like to talk about how hard and complex our technical work is, but frankly, it’s a lot easier to get a computer to do what you want than to convince a human. Not least because you also need to understand what that other human wants. As Danielle says:
Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.
Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.
So let’s say it is someone in the marketing department who is pushing to have an obtrusive newsletter sign-up form get shoved in the user’s face. Talk to them. Figure out what their goals are—what outcome are they hoping to get to. If they don’t seem to understand the user-experience implications, talk to them about that. But it needs to be a two-way conversation. You need to understand what they need before you start telling them what you want.
I realise that makes it sound patronisingly simple, and I know that in actuality it’s a sisyphean task. It may be that genuine understanding between people is the wickedest of design problems. But even if this problem seems insurmoutable, at least you’d be tackling the right problem.
Because the web can’t survive like this.