He concludes with some simple, reasonable things to consider when building for the web:
- Is there a lighter alternative (Preact, Svelte, etc.) that gets you 90% of the way there?
- If you’re going with a framework, does anything exist that provides better, more opinionated defaults (ex: Nuxt.js instead of Vue.js, Next.js instead of React, etc.)?
There was a lot of praise for Tim’s article. But unsurprisingly, there was some pushback from the “we build apps, not websites” crowd.
Apps aren’t held to a different standard
The main point of contention:
Apps are different. Performance is still important, but web performance metrics need to be different/slower/worse for web apps than a “static website.”
I get it.
Making complex web apps performant is hard. Making them as performant as a static website is even harder (some might say impossible, but like most things, it depends).
But a user’s frustration and annoyance and tendency to just leave and never come back doesn’t suddenly lessen because you’ve built an “app” and not a “website.”
Your convenience as a developer isn’t more important than your users’ ability to access your app on low bandwidth internet connections and older, underpowered devices.
Time to interactive > fully loaded
Your app should be interactive in three seconds or less on a broadband connection, and five seconds or less on 3g.
That doesn’t mean it has to be fully featured.
It just means that people need to be able to start moving around and interacting with content. Perceived performance is more important than “this thing is fully loaded.”
It’s a bit like being stuck in bumper-to-bumper traffic versus moving slowly on side roads. Even if it takes you longer to get there with side roads, it’s less frustrating to be moving than at a total stop.
How can you make web apps faster?
There are a lot of different approaches you can take, depending on your app and what it’s supposed to do.
- You could load the never-changing stuff like your logo and navigation menu immediately, and asynchronously pull in dynamic or API-driven content once it arrives (for example, dashboard content).
- You cache API data in
localStorageto minimize API calls (and the latency they introduce).
- You can push your API data out through a CDN network so that responses take less time (because they originate from closer to where the visitor is).
- You create a progressive web app that loads some content from a cache, even if the user is offline. You could, for example, load data from their last visit on initial load, and refresh it with fresh data as soon as an API call returns the new stuff.
- You can follow Tim’s recommendations, and use vanilla JS instead of frameworks, or lighter weight alternatives like Reef or Preact.
- You can use a CSS strategy that results in smaller stylesheets.
I’m not saying its always easy. But that’s not the point. Building a complex web app isn’t easy either.
I’m saying it’s your job as a web professional to build fast, accessible things that work for as many people as possible.
Just because you built “an app” doesn’t mean you get a free pass on web performance.