I quite like this change of terminology when it comes to making fast websites. After all, performance can sound like a process of addition, whereas efficiency can be a process of subtraction.
The term ‘performance’ brings to mind exotic super-cars suitable only for impractical demonstrations (or ‘performances’). ‘Efficiency’ brings to mind an electric car (or even better, a bicycle), making effective use of limited resources.
Spoiler: the answer to the question in the title is a resounding “hell yeah!”
Scott brings receipts.
A no-nonsense checklist of good performance advice from Karolina.
Following on from that excellent blog post about removing jQuery from gov.uk, here are the performance improvements in charts and numbers.
It may sound like 32 kb of JavaScript is nothing on today’s modern web with quick devices and fast broadband connections. But for a certain cohort of users, it makes a big difference to how they experience GOV.UK.
At the risk of grossly oversimplifying things, I propose that the core of the debate can be summed up by these truisms:
- The best SPA is better than the best MPA.
- The average SPA is worse than the average MPA.
Everything old is new again:
In our current “information age,” or so the story goes, we suffer in new and unique ways.
But the idea that modern life, and particularly modern technology, harms as well as helps, is deeply embedded in Western culture: In fact, the Victorians diagnosed very similar problems in their own society.
WebPageTest just got even better! Now you can mimic the results of what would’ve previously required actually shipping, like adding third-party scripts, switching from a client-rendered to a server-rendered architecture and other changes that could potentially have a big effect on performance. Now you can run an experiment to get the results before actual implementation.
This is a really excellent four-part series on web performance that really dives into the technical details and asks all the right questions:
The headline is a little misleading because if you follow this advice, your multi-page apps will be much much faster than single page apps, especially when you include that initial page load of a single page app.
Here’s a quick high-level summary of what I do…
That’s an excellent recipe for success right there!
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.
In Astro, you compose your website using UI components from your favorite JavaScript web framework (React, Svelte, Vue, etc). Astro renders your entire site to static HTML during the build. The result is a fully static website with all JavaScript removed from the final page.
YES!
When a component needs some JavaScript, Astro only loads that one component (and any dependencies). The rest of your site continues to exist as static, lightweight HTML.
That’s the way to do it! Make the default what’s best for users (unlike most JavaScript frameworks that prioritise developer convenience at the expense of the end user experience).
This is a tagline I can get behind:
Ship Less JavaScript
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).