Oh, nice! A version of the classic Proxima Nova that’s a variable font that allows you to vary weight, width, and slant.
mediasupport from HTML video was a mistake.
Damn right! It was basically Hixie throwing a strop, trying to sabotage responsive images. Considering how hard it is usually to remove a shipped feature from browsers, it’s bizarre that a good working feature was pulled out of production.
There’s no browser support yet but that doesn’t mean we can’t start adding
prefers-reduced-data to our media queries today. I like the idea of switching between web fonts and system fonts.
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.
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.
Garrett’s observation is spot-on here:
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!
This is the transcript of a brilliant presentation by Scott—read the whole thing! It starts with a much-needed history lesson that gets to where we are now with the dismal state of performance on the web, and then gives a whole truckload of handy tips and tricks for improving performance when it comes to styles, scripts, images, fonts, and just about everything on the front end.
Testing on a <$100 Android device on a 3G network should be an integral part of testing your website. Not everyone is on a brand-new device or upgrades often, especially with the price point of a high-end phones these days.
When we design and build our websites with the outliers in mind, whether it’s for performance or even user experience, we build an experience that can be easy for all to access and use — and that’s what the web is about, access and information for all.
The Jevons Paradox in action:
Even if folks are on a new fast network, they’re very likely choking on the code we’re sending, rendering the potential speed improvements of 5G moot.
The longer I spend in this field, the more convinced I am that web performance is not a technical problem; it’s a people problem.
Get an idea of how much your website is contributing to the climate crisis.
In total, the internet produces 2% of global carbon emissions, roughly the same as that bad boy of climate change, the aviation industry.
If you treat data as a constraint in your design and development process, you’ll likely be able to brainstorm a large number of different ways to keep data usage to a minimum while still providing an excellent experience. Doing less doesn’t mean it has to feel broken.
I would very much like this to become a reality.
Never-Slow Mode (“NSM”) is a mode that sites can opt-into via HTTP header. For these sites, the browser imposes per-interaction resource limits, giving users a better user experience, potentially at the cost of extra developer work. We believe users are happier and more engaged on fast sites, and NSM attempts to make it easier for sites to guarantee speed to users. In addition to user experience benefits, sites might want to opt in because browsers could providing UI to users to indicate they are in “fast mode” (a TLS lock icon but for speed).
The title is somewhat misleading—currently it’s about native lazy-loading for Chrome, which is not (yet) the web.
I’ve just been adding
loading="lazy" to most of the iframes and many of the images on adactio.com, and it’s working a treat …in Chrome.
If you ignore the slightly insulting and condescending clickbaity title, this is a handy run-down of eight browser features with good support:
- extra arguments in
- extra arguments in
defaultCheckedproperty for checkboxes,
wholeTextfor strings of text,
Page web bloat score (WebBS for short) is calculated as follows:
WebBS = TotalPageSize / PageImageSize
Yes, this is a tongue-in-cheek somewhat arbitrary measurement, but it’s well worth reading through the rationale for it.
How can the image of a page be smaller than the page itself?
loading attribute for images and iframes is coming to Chrome. The best part:
You can also use
loadingas a progressive enhancement. Browsers that support the attribute can get the new lazy-loading behavior with
loading=lazyand those that don’t will still have images load.
I like Tim’s definition here:
A performance budget is a clearly defined limit on one or more performance metrics that the team agrees not to exceed, and that is used to guide design and development.
And I agree about the four attributes required for a performance budget to succeed. It must be:
The point is not to let the performance budget try to stand on its own, somewhere hidden in company documentation collecting dust. You need to be proactive about making the budget become a part of your everyday work.
If you really, really have to add Google Analytics to a sites, here’s a way to do it in a more performant way, without the odious Google Tag Manager.
Following on from that proposal for a browser feature that I linked to yesterday, Tim thinks through all the permutations and possibilities of user agents allowing users to throttle resources:
If a limit does get enforced (it’s important to remember this is still a big if right now), as long as it’s handled with care I can see it being an excellent thing for the web that prioritizes users, while still giving developers the ability to take control of the situation themselves.