​​​🗜️​ performance
​​or, the “fine-tune the machine” part.
​​
​​prev: debugging
​​table of contents
​​next: testing

​​tl;dr

  • ​​intro: poor performance is a bug.
  • ​​speed at runtime:
  • ​​CSS: *​ selector, descendant/child selectors, transform: translateZ(0), contain, will-change
  • ​​usage analytics: clicks, navigation patterns, user agent, location
​​
​​

​​intro

​​if your performance is poor, it should be considered Bug #1 and a huge reason people won’t use your product. if your page takes more than a couple seconds to load, people will abandon it and potentially never come back again. a speedy app shows shows consideration for your user’s time — the faster they can get what they need done and move on with their life, the more they will consider it a indispensable tool.
​​
​​make sure you measure how your app is actually behaving in the wild! just because it “works for you” in the lab of your home or office doesn’t mean it actually works for the wide variety of people using your app with a wide variety of connection speeds, browsers, and usage patterns.
​​
​​

​​speed at load

​​there are a lot of facets to attaining performance gains. Google puts out a model called RAIL as a helpful mental model when thinking about prioritizing work here. in general, Google dominates in this area of knowledge — most of the resources below are from them. here’s a list of approaches to consider.
​​

​​bundling assets

​​one of the simplest things you can do is reduce the number of HTTP requests to your server. by bundling together your assets (JS, CSS, and traditionally your icons into a sprite file) you can reduce the number of round-trip requests from client↔server and improve speed drastically. you can get this for free basically via your bundler.
​​
​​JS at the bottom
​​place JS <script>​ tags at the bottom of your HTML (near the </body>​ closing tag) whenever possible to improve page load. JS blocks page execution so saving it for the end makes your page more usable faster. additionally, one can use the async​ or defer​ attributes on a <script>​ tag to make execution faster of other parts of the page. async​ will download the file asynchronously and pause HTML execution once it’s received, and not necessarily in order. defer​ on the other hand waits until HTML execution is done, but it will execute in order.
​​

​​HTTP2

​​however, on the other hand, HTTP2 turns the previous item in this list on its head and says, “no need to bundle assets anymore!” in practice, i’ve found that you shouldn’t go whole hog and unbundling everything — the right balance is needed. it will take playing with your app and it’s particular needs a little bit to see what things can be unbundled vs. not to see what works best.
​​

​​placeholders

​​ahh, this falls into the perceptual speed, or “fake it ‘til you make it” ​🙂​. here, we add visual assets that load quickly on page load to give the user the impression that something is happening. here are some examples of this looks like in practice.
​​

​​Progressive Web App (PWA) with Service Worker

​​gives your app offline capability and faster loading times.
​​
​​PRPL pattern
​​related to Service Workers is the standard being put out to:
  • ​​Push critical resources for the initial URL route.
  • ​​Render initial route.
  • ​​Pre-cache remaining routes.
  • ​​Lazy-load and create remaining routes on demand.
​​