Mat has written this free course for you all about images on the web. Covering image formats, responsive images, and workflows, this is one to keep on speed dial.
- Make the right thing easy
- Always answer “so what”?
- Close the gap between “something is wrong” to “we fixed it”
A person seeking help in a time of crisis does not care about TypeScript, tree shaking, hot module replacement, A/B tests, burndown charts, NPS, OKRs, KPIs, or other startup jargon. Developer experience does not count for shit if the person using the thing they built can’t actually get what they need.
Imagine the web is a storefront, React is a hot dog car, and here’s Create React App dressed as a hot dog:
HTML is the cornerstone of the web — so why does creating a “React app” produce an empty HTML file? Why are we not taking advantage of the most basic feature of the web—the ability to see content quickly before all the interactive code loads? Why do we wait to start loading the data until after all the client-side code has finished loading?
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.
Over the past 10 years or so, we’ve slowly but very surely transitioned to a state where frameworks are the norm, and I think it’s a problem.
The whole article is great, and really charmingly written, with some golden nuggets embedded within, like:
- You’ll find that spending more time getting HTML right reveals or even anticipates and evades accessibility issues. It’s just easier to write accessible code if it’s got semantic foundations.
- In my experience, you will almost always spend more time overriding frameworks or compromising your design to fit the opinions of a framework.
- Always style from the absolute smallest screen your content will be rendered on first, and use
@media (min-width)queries to break to layouts that allow for more real estate as it becomes available.
- Always progressively enhance your apps, especially when you’re fucking with something as browser-critical as page routing.
Strong—and true—words from Alex.
Frontend’s failure to deliver in today’s mostly-mobile, mostly-Android world is shocking, if only for the durability of the myths that sustain the indefensible. We can’t keep doing this.
If you disagree, I encourage you to dive into the data that Alex shares.
Spoiler: the answer to the question in the title is a resounding “hell yeah!”
Scott brings receipts.
But is it always the case that faster websites are greener websites? We reluctantly have to consider another facet: if making a website for a car manufacturer faster leads to an increase in the number of cars sold, can we really say that our website is greener?
This is very timely for me, given that Clearleft is currently engaged on a project that’s making me decidedly queasy for this exact reason—the success metrics of the project would be net negative for the world.
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.
This is a great thorough description of the process of migrating gov.uk away from jQuery. It sounds like this guide was instrumental in the process—I love that they’re sharing it openly!
While I’ve always been bothered by the downsides of SPAs, I always thought the gap would be bridged sooner or later, and that performance concerns would eventually vanish thanks to things like code splitting, tree shaking, or SSR. But ten years later, many of these issues remain. Many SPA bundles are still bloated with too many dependencies, hydration is still slow, and content is still duplicated in memory on the client even if it already lives in the DOM.
Yet something might be changing: for whatever reason, it feels like people are finally starting to take note and ask why things have to be this way.
Interesting to see a decade-long perspective. I especially like how Sacha revisits and reasseses design principles from ten years ago:
- Data on the Wire. Don’t send HTML over the network. Send data and let the client decide how to render it.
It’s since become apparent that you often do need to send HTML over the network, and things seem to be moving back towards handling as much as possible of your HTML compilation on the server, not on the client.
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.
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.
Broadly, these are websites which are still web pages, not web applications; they’re pages of essentially static information, personal websites, blogs, and so on, but they are slightly dynamic. They might have a style selector at the top of each page, causing a cookie to be set, and the server to serve a different stylesheet on every subsequent page load.
This rings sadly true to me:
Also, I never thought about “serverless” like this:
Recently we’ve seen the rise in popularity of AWS Lambda, a “functions as a service” provider. From my perspective this is literally a reinvention of CGI, except a) much more complicated for essentially the same functionality, b) with vendor lock-in, c) with a much more complex and bespoke deployment process which requires the use of special tools.
We’re all LARPing on LinkedIn.
This is very convincing.
This is a really excellent four-part series on web performance that really dives into the technical details and asks all the right questions: