Reasoning about Speed

rail

One challenging aspect of web performance is that it is often addressed once it has become a problem already; this can be referred to as a “reactive approach to handling performance”. A reactive approach is challenging because the symptoms of the problem emerge way after they were introduced early on during the initial design/implementation phases of the a project; and it is often very difficult, if not impossible, to change design/implementation decisions that have pervasively percolated through the whole system.

Another challenging aspect is that we are trying to achieve globally-optimal results (i.e. good overall performance), from a collection of local optimization decisions (e.g. defer the evaluation of a JS file, etc).

Performance models are one approach to mitigate these challenges and enable us to reason about performance. The use of performance models during the process of designing and implementing applications provides guidance to our decision making process; they provide a framework for reasoning about how design/implementation decisions affect performance and user experience and to strike the proper tradeoffs at every step along the way.

Another benefit of defining and using performance models is that they provide a Lingua Franca, a common language for teams to talk about performance and ensure that they are all looking at the reality of the app from the same perspective.

Two specific performance models/patterns relevant for designing/implementing websites are: (1) the Response, Animation, Idle Load (RAIL) model; and (2) the Push, Render, Pre-cache, Lazy-load (PRPL) pattern.

The RAIL Performance Model

The RAIL model seeks to capture the four major areas of a web app life cycle; it stands for: Response, Animation, Idle, Load. If we look at them in chronological order, we would read the acronym backwards:

  • Load. We want our initial load and rendering to happen in about one second.
  • Idle. An app is usually idle while waiting for the user to interact; idle time is divided into chunks of fifty ms each, and they offer a great opportunity to squeeze work that the app needs to do.
  • Animation. This part of the model relates to one of the most challenging aspects of the performance of web apps: the need to achieve animations that render at 60fps (frames per second). This means that we have about 16 ms to render one frame; or even less since in reality, browsers have to squeeze other tasks in that time budget, leaving us with an actual budget of  about 10 ms. Check this reference for more detailed information.
  • Response. This responsiveness corresponds to how quickly the app reacts to user interactions; that is, how quickly the app becomes interactive. Research has shown that there is a limit of about 100 ms from when a user interacts with the application (e.g. tap a button, scroll) and when she gets the desired response.

In practical terms, the RAIL model translates into this :

  • Focus on the user; the ultimate goal is to make users happy
  • Respond to users immediately; acknowledge user input in under 100ms.
  • Animate smoothly. When animating or scrolling, produce a frame in under 10ms.
  • Be efficient. Maximize main thread idle time.
  • Load fast (keep users engaged). Deliver interactive content in under 1000ms.

The PRPL Pattern

The acronym PRLP refers to a pattern for structuring and serving Progressive Web Apps (PWAs), with an emphasis on the performance of app delivery and launching. The pattern comprises the following elements:

  • Push critical resources for the initial route.
  • Render initial route.
  • Pre-cache remaining routes.
  • Lazy-load and create remaining routes on demand.

In a nutshell, PRPL seeks to optimize three aspects of the development, launching, and performance of a web app:

  • Minimize the Time-to-Interactive (TTI) metric: especially on first use (regardless of entry point), and on real-world mobile devices
  • Maximize caching efficiency: Simplify app development and deployment

The PRPL pattern is less about specific technologies or techniques that can be used, and more about a mindset and a long-term vision for improving the performance of the mobile web applications. The goal is to keep the PRPL pattern in mind when planning for performance.

So…

If there is one takeaway from this post, is this: web performance is more than technique; it is a mindset. A mindset that should encompass every aspect involved in the development of our products: designers, developers, decision makers. And for that mindset to be effective, we need to be able to reason about performance. Performance models are your tools to do that and harness control of the performance of your sites and apps.

One thought on “Reasoning about Speed

  1. Interesting points, we are currently dealing with the struggles of a reactive approach to performance on our ecommerce site but are looking at a a RAIL based approach with an overhaul where we can focus on putting user experience first.

    The struggle is real.

Leave a Reply