It was a few years before I realized that worry stones had a name, that they were borrowed from cultures other and older than mine. Heck, it’s been more than a few years since I’ve even held one. But in the last few weeks, before and after launching the redesign, I’ve kept working away at this website, much as I’d distractedly run my fingers over a smooth, flat stone.
The minimum dependency for a web site should be an internet connection and the ability to parse HTML.
In my experience, 99% of the time Web Performance boils down to two problems:
- “You have unoptimized images.”
But as Dave points out, the real issue is this:
I find that Web Performance isn’t particularly difficult once you understand the levers you can pull; reduce kilobytes, reduce requests, unblock rendering, defer scripts. But maintaining performance that’s a different story entirely…
Performance matters …especially when the chips are down:
If you are in charge of a web site that provides even slightly important information, or important services, it’s time to 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.
This is a great walkthough of making a common form pattern accessible. No complex code here: some HTML is all that’s needed.
A history of typesetting from movable type to variable fonts.
Garrett’s observation is spot-on here:
Some solid research here. Turns out that using
input type=”text” inputmode=”numeric” pattern="[0-9]*" is probably a better bet than using
How and when did I get to the point where I would consider a page weight of 4 MB on a large page and 500 KB on a small page normal?
This isn’t just a well-earned rant from Manuel. I mean, it *is that, but it’s also packed with practical performance advice.
I’ve really come to appreciate that performance isn’t just some property of a tool independent from its functionality or its feature set. Performance — in particular, being notably fast — is a feature in and of its own right, which fundamentally alters how a tool is used and perceived.
This is a fascinating look into how performance has knock-on effects beyond the obvious:
It’s probably fairly intuitive that users prefer faster software, and will have a better experience performing a given task if the tools are faster rather than slower.
What is perhaps less apparent is that having faster tools changes how users use a tool or perform a task.
This observation is particularly salient for web developers:
We have become accustomed to casually giving up factors of two or ten or more with our choices of tools and libraries, without asking if the benefits are worth it.
Pages are often designed so that they’re hard or impossible to read if some dependency fails to load. On a slow connection, it’s quite common for at least one depedency to fail.
Fire up Reader Mode and read this excellent article informed by data from using a typically slow connection in rural USA today. Two findings are:
- A large fraction of the web is unusable on a bad connection. Even on a good (0% packetloss, no ping spike) dialup connection, some sites won’t load.
- Some sites will use a lot of data!
The characteristica universalis and the calculus racionator of Leibniz.
The beautiful 19th century data visualisations of Emma Willard unfold in this immersive piece by Susan Schulten.
Chris takes two side-by-side deep dives; one into the
a element, the other into the
Even if you think you already know those elements well, I bet there’ll be something new here for you. Like, did you know that the
button element can have form over-riding attributes like
This is going to be so useful for client work at Clearleft—instant snapshots of performance metrics across industries and regions!
See Tammy’s blog post for me details.
It’s now easier than ever to style form controls without sacrificing semantics and accessibility:
The reason is that we can finally style the ::before and ::after pseudo-elements on the
<input>tag itself. This means we can keep and style an
<input>and won’t need any extra elements. Before, we had to rely on the likes of an extra
<span>, to pull off a custom design.
The demo is really nice. And best of all, you can wrap all of these CSS enhancements in a feaure query:
Hopefully, you’re seeing how nice it is to create custom form styles these days. It requires less markup, thanks to pseudo-elements that are directly on form inputs. It requires less fancy style switching, thanks to custom properties. And it has pretty darn good browser support, thanks to
I’ve come to accept that our current approach to remedy poor performance largely consists of engineering techniques that stem from the ill effects of our business, product management, and engineering practices. We’re good at applying tourniquets, but not so good at sewing up deep wounds.
It’s becoming increasingly clear that web performance isn’t solely an engineering problem, but a problem of people.
I can’t decide if this is industrial sabotage or political protest. Either way, I like it.
99 second hand smartphones are transported in a handcart to generate virtual traffic jam in Google Maps.Through this activity, it is possible to turn a green street red which has an impact in the physical world by navigating cars on another route to avoid being stuck in traffic
The many ways of improving a single form field in HTML.
I love these kinds of deep dives into markup!