Link tags: performance

492

sparkline

How and why we removed jQuery from GOV.UK - Inside GOV.UK

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!

Removing jQuery means that 32Kb of JavaScript has been removed from the majority of pages on GOV.UK. GOV.UK is already quite fast to load and for many users this will make no noticeable difference. However, the change for users on a low bandwidth connection or lower specification device will be much more noticeable, resulting in significantly improved page download speed and performance.

10 Years of Meteor

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:

  1. Data on the Wire. Don’t send HTML over the network. Send data and let the client decide how to render it.

Verdict: 👎

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.

SPAs: theory versus practice | Read the Tea Leaves

At the risk of grossly oversimplifying things, I propose that the core of the debate can be summed up by these truisms:

  1. The best SPA is better than the best MPA.
  2. The average SPA is worse than the average MPA.

Introducing Opportunities & Experiments: Taking the Guesswork out of Performance - WebPageTest Blog

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.

The Demise of the Mildly Dynamic Website

It me:

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:

Suppose a company makes a webpage for looking up products by their model number. If this page were made in 2005, it would probably be a single PHP page. It doesn’t need a framework — it’s one SELECT query, that’s it. If this page were made in 2022, a conundrum will be faced: the company probably chose to use a statically generated website. The total number of products isn’t too large, so instead their developers stuff a gigantic JSON file of model numbers for every product made by the company on the website and add some client-side JavaScript to download and query it. This increases download sizes and makes things slower, but at least you didn’t have to spin up and maintain a new application server. This example is fictitious but I believe it to be representative.

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.

Picture perfect images with the modern img element - Stack Overflow Blog

Addy takes a deep dive into making sure your images are performant. There’s a lot to cover here—that’s why I ended up splitting it in two for the responsive design course: one module on responsive images and one on the picture element.

Make it boring — jlwagner.net

People are propelled by their interests, and web developers have a lot of space to be interested in all sorts of stuff. For you, it may be JavaScript ‘n Friends, or HTML and CSS. Maybe it’s all that stuff, but put aside your preferences for a moment and answer me this: what are you helping people to do? If the answer involves any remotely routine or crucial purpose, consider putting aside your personal desire for excitement. Instead, make boring things that are usable, accessible, and fast. Ours is a job done by people for people, not a glamorous rockstar gig.

Excellent advice from Jeremy who wants us to build fast, reliable, resilient websites …even if the technologies involved in doing that don’t feel exciting.

Central to that endeavor is recognizing that the browser gives you a ton of stuff for free. Relying on those freebies requires a willingness to not npm install a solution for every problem — especially those that are best solved with CSS and HTML. Those technologies may seem boring, but boring is fast. Boring is usable. Boring is resilient and fault tolerant. Boring is accessible. When we rely wholesale on JavaScript to build for the web, we’re inevitably reinventing things. At worst, our reinventions of rock-solid HTML features — such as client-side form validation  — break in unexpected ways despite our carefully written tests. At best, a flawless reimplementation of those features adds unnecessary code to applications, and depends on a technology less fault-tolerant than CSS and HTML.

How to make MPAs that are as fast as SPAs | Go Make Things

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…

  1. Serve pre-rendered, mostly static HTML.
  2. Inline everything, including CSS and JavaScript.
  3. Use mostly platform-native JavaScript, and as little of it as possible.
  4. Minify and gzip all the things.
  5. Lean heavily on service workers.

That’s an excellent recipe for success right there!

SPAs were a mistake | Go Make Things

Browsers give you a ton of stuff for free, built right in, out-of-the-box. SPAs break all that, and force you to recreate it yourself with JavaScript. Most developers do it wrong, and for the ones who do it right, it results in a ton of extra code to recreate features the browser already gave you for free.

Canned web development — Jeremy Wagner

Our mental model for how we build for the web is too reliant on canned solutions to unique problems.

This is very perceptive indeed.

Compounding this problem is that too few boot camps are preparing new web developers to think critically about what problems are best solved by JavaScript and which aren’t — and that those problems that are best solved by JavaScript can be solved without engaging in frivolous framework whataboutism. The question developers should ask more often when grappling with framework shortcomings shouldn’t be “what about that other framework?”, but rather “what’s best for the user experience?”.

The baseline for web development in 2022

A thoroughly researched look at what our baseline criteria should be for making websites today:

The baseline for web development in 2022 is:

  • low-spec Android devices in terms of performance,
  • Safari from two years before in terms of Web Standards,
  • and 4G in terms of networks.

The web in general is not answering those needs properly, especially in terms of performance where factors such as an over-dependence on JavaScript are hindering our sites’ performance.

It’s somewhat damning to Safari to see it as a baseline browser, but with Internet Explorer out of the picture, something has to be the lowest common denominator. In this case, Safari is quite literally the new IE.

Unveiling the new WebPageTest UI - WebPageTest Blog

If you haven’t seen it yet, the new redesign of WebPageTest is lovely!

Ban embed codes

Prompted by my article on third-party code, here’s a recommendation to ditch any embeds on your website.

Add Less | CSS-Tricks - CSS-Tricks

Let the power of the browser work for you, and use less stuff!

Amen!

Your websites start fast until you add too much to make them slow. Do you need any framework at all? Could you do what you want natively in the browser?

Add a Service Worker to Your Site | CSS-Tricks - CSS-Tricks

Damn, I wish I had thought of giving this answer to the prompt, “What is one thing people can do to make their website better?”

If you do nothing else, this will be a huge boost to your site in 2022.

Chris’s piece is a self-contained tutorial!

Test Your Product on a Crappy Laptop - CSS-Tricks

Eric’s response to Chris’s question—“What is one thing people can do to make their website better?”—dovetails nicely with my own answer:

The two real problems here are:

  1. Third-party assets, such as the very analytics and CRM packages you use to determine who is using your product and how they go about it. There’s no real control over the quality or amount of code they add to your site, and setting up the logic to block them loading their own third-party resources is difficult to do.
  2. The people who tell you to add these third-party assets. These people typically aren’t aware of the performance issues caused by the ask, or don’t care because it’s not part of the results they’re judged by.