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.
Okay, so I didn’t get many of the answers, but nonetheless these are excellent questions!
(Ah, how I long for the day when we can once more engage in quizzo and picklebacks at National Mechanics.)
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.
As a resident of Brighton—home to the most beautiful of bandstands—this bit of background to their history is fascinating.
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.
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.
When you stop to consider all the implications of poor performance, it’s hard not to come to the conclusion that poor performance is an ethical issue.