Yusuke Utsunomiya on web.dev

Five ways AirSHIFT improved their React app's runtime performance

2019-11-06T00:00:00Z

Website performance is not just about load time. It is critical to provide a fast and responsive experience to users, especially for productivity desktop apps which people use everyday. The engineering team at Recruit Technologies went through a refactoring project to improve one of their web apps, AirSHIFT, for better user input performance. Here's how they did it.

Slow response, less productivity #

AirSHIFT is a desktop web application that helps store owners, like restaurants and cafes, to manage the shift work of their staff members. Built with React, the single page application provides rich client features including various grid tables of shift schedules organized by day, week, month and more.

As the Recruit Technologies engineering team added new features to the AirSHIFT app, they started seeing more feedback around slow performance. The engineering manager of AirSHIFT, Yosuke Furukawa, said:

In a user research study, we were shocked when one of the store owners said she would leave her seat to brew coffee after clicking a button, just to kill time waiting for the shift table to load.

After going through the research, the engineering team realized that many of their users were trying to load massive shift tables on low spec computers, such as a 1 GHz Celeron M laptop from 10 years ago.

Endless spinner on low end devices.

The AirSHIFT app was blocking the main thread with expensive scripts, but the engineering team didn't realize how expensive the scripts were because they were developing and testing on rich spec computers with fast Wi-Fi connections.

When loading the shift table, around 80% of the load time was consumed by running scripts.

After profiling their performance in Chrome DevTools with CPU and network throttling enabled, it became clear that performance optimization was needed. AirSHIFT formed a task force to tackle this issue. Here are 5 things they focused on to make their app more responsive to user input.

1. Virtualize large tables #

Displaying the shift table required multiple expensive steps: constructing the virtual DOM and rendering it on screen in proportion to the number of staff members and time slots. For example, if a restaurant had 50 working members and wanted to check their monthly shift schedule, it would be a table of 50 (members) multiplied by 30 (days) which would lead to 1,500 cell components to render. This is a very expensive operation, especially for low spec devices. In reality, things were worse. From the research they learned there were shops managing 200 staff members, requiring around 6,000 cell components in a single monthly table.

To reduce the cost of this operation, AirSHIFT virtualized the shift table. The app now only mounts the components within the viewport and unmounts the off-screen components.

Before: Rendering all the shift table cells.

After: Only rendering the cells within the viewport.

In this case, AirSHIFT used react-virtualized as there were requirements around enabling complex two dimensional grid tables. They are also exploring ways to convert the implementation to use the lightweight react-window in the future.

Results #

Virtualizing the table alone reduced scripting time by 6 seconds (on a 4x CPU slowdown + Fast 3G throttled Macbook Pro environment). This was the most impactful performance improvement in the refactoring project.

Before: Around 10 seconds of scripting after user input.

After: 4 seconds of scripting after user input.

2. Audit with User Timing API #

Next, the AirSHIFT team refactored the scripts that run on user input. The flame chart of Chrome DevTools makes it possible to analyze what's actually happening in the main thread. But the AirSHIFT team found it easier to analyze application activity based on React's lifecycle.

React 16 provides its performance trace via the User Timing API, which you can visualize from the Timings section of Chrome DevTools. AirSHIFT used the Timings section to find unnecessary logic running in React lifecycle events.

React's User Timing events.

Results #

The AirSHIFT team discovered that an unnecessary React Tree Reconciliation was happening right before every route navigation. This meant that React was updating the shift table unnecessarily before navigations. An unnecessary Redux state update was causing this issue. Fixing it saved around 750 ms of scripting time. AirSHIFT made other micro optimizations as well which eventually led to a 1 second total reduction in scripting time.

3. Lazy load components and move expensive logic to web workers #

AirSHIFT has a built-in chat application. Many store owners communicate with their staff members via the chat while looking at the shift table, which means that a user might be typing a message while the table is loading. If the main thread is occupied with scripts that are rendering the table, user input could be janky.

To improve this experience, AirSHIFT now uses React.lazy and Suspense to show placeholders for table contents while lazily loading the actual components.

The AirSHIFT team also migrated some of the expensive business logic within the lazily loaded components to web workers. This solved the user input jank problem by freeing up the main thread so that it could focus on responding to user input.

Typically developers face complexity in using workers but this time Comlink did the heavy lifting for them. Below is the pseudo code of how AirSHIFT workerized one of the most expensive operations they had: calculating total labor costs.

In App.js, use React.lazy and Suspense to show fallback content while loading

/** App.js */
import React, { lazy, Suspense } from 'react'

// Lazily loading the Cost component with React.lazy
const Hello = lazy(() => import('./Cost'))

const Loading = () => (
  <div>Some fallback content to show while loading</div>
)

// Showing the fallback content while loading the Cost component by Suspense
export default function App({ userInfo }) {
   return (
    <div>
      <Suspense fallback={<Loading />}>
        <Cost />
      </Suspense>
    </div>
  )
}

In the Cost component, use comlink to execute the calc logic

/** Cost.js */
import React from 'react';
import { proxy } from 'comlink';

// import the workerlized calc function with comlink
const WorkerlizedCostCalc = proxy(new Worker('./WorkerlizedCostCalc.js'));
export default async function Cost({ userInfo }) {
  // execute the calculation in the worker
  const instance = await new WorkerlizedCostCalc();
  const cost = await instance.calc(userInfo);
  return <p>{cost}</p>;
}

Implement the calculation logic that runs in the worker and expose it with comlink

// WorkerlizedCostCalc.js
import { expose } from 'comlink'
import { someExpensiveCalculation } from './CostCalc.js'

// Expose the new workerlized calc function with comlink
expose({
  calc(userInfo) {
    // run existing (expensive) function in the worker
    return someExpensiveCalculation(userInfo);
  }
}, self);

Results #

Despite the limited amount of logic they workerized as a trial, AirSHIFT shifted around 100 ms of their JavaScript from the main thread to the worker thread (simulated with 4x CPU throttling).

AirSHIFT is currently exploring whether they can lazy load other components and offload more logic to web workers to further reduce jank.

4. Setting a performance budget #

Having implemented all of these optimizations, it was critical to make sure that the app remains performant over time. AirSHIFT now uses bundlesize to not exceed the current JavaScript and CSS file size. Aside from setting these basic budgets, they built a dashboard to show various percentiles of the shift table loading time to check whether the application is performant even in non-ideal conditions.

The script completion time for every Redux event is now measured
Performance data is collected in Elasticsearch
10th, 25th, 50th, and 75th percentile performance of each event is visualized with Kibana

AirSHIFT is now monitoring the shift table loading event to make sure it completes in 3 seconds for the 75th percentile users. This is an unenforced budget for now but they are considering auto-notifications via Elasticsearch when they exceed their budget.

The Kibana dashboard showing daily performance data by percentiles.

Results #

From the graph above, you can tell that AirSHIFT is now mostly hitting the 3 seconds budget for 75th percentile users and also loading the shift table within a second for 25th percentile users. By capturing RUM performance data from various conditions and devices, AirSHIFT can now check whether a new feature release is actually affecting the application's performance or not.

5. Performance hackathons #

Even though all of these performance optimization efforts were important and impactful, it's not always easy to get engineering and business teams to prioritize non-functional development. Part of the challenge is that some of these performance optimizations can't be planned. They require experimentation and a trial-and-error mindset.

AirSHIFT is now conducting internal 1-day performance hackathons to let engineers focus only on performance related work. In these hackathons they remove all constraints and respect the engineers' creativity, meaning any implementation that contributes to speed is worth considering. To accelerate the hackathon, AirSHIFT splits the group into small teams and each team competes to see who can get the biggest Lighthouse performance score improvement. The teams get very competitive! 🔥

Results #

The hackathon approach is working well for them.

Performance bottlenecks can be easily detected by actually trying out multiple approaches during the hackathon and measuring each with Lighthouse.
After the hackathon, it's rather easy to convince the team which optimization they should be prioritizing for production release.
It's also an effective way of advocating the importance of speed. Every participant can understand the correlation between how you code and how it results in performance.

A good side effect was that many other engineering teams within Recruit got interested in this hands-on approach and the AirSHIFT team is now facilitating multiple speed hackathons within the company.

Summary #

It was definitely not the easiest journey for AirSHIFT to work on these optimizations but it certainly paid off. Now AirSHIFT is loading the shift table within 1.5 sec in median which is a 6x improvement from their performance before the project.

After the performance optimizations launched, one user said:

Thank you so much for making the shift table load fast. Arranging the shift work is so much more efficient now.

Hands-on with Portals: seamless navigation on the web

2019-05-06T00:00:00Z

Making sure your pages load fast is key to delivering a good user experience. But one area we often overlook is page transitions—what our users see when they move between pages.

A new web platform API proposal called Portals aims to help with this by streamlining the experience as users navigate across your site.

See Portals in action:

Seamless embeds and navigation with Portals. Created by Adam Argyle.

What Portals enable #

Single Page Applications (SPAs) offer nice transitions but come at the cost of higher complexity to build. Multi-page Applications (MPAs) are much easier to build, but you end up with blank screens between pages.

Portals offer the best of both worlds: the low complexity of an MPA with the seamless transitions of an SPA. Think of them like an <iframe> in that they allow for embedding, but unlike an <iframe>, they also come with features to navigate to their content.

Seeing is believing: please first check out what we showcased at Chrome Dev Summit 2018:

With classic navigations, users have to wait with a blank screen until the browser finishes rendering the destination. With Portals, users get to experience an animation, while the <portal> pre-renders content and creates a seamless navigation experience.

Before Portals, we could have rendered another page using an <iframe>. We could also have added animations to move the frame around the page. But an <iframe> won't let you navigate into its content. Portals close this gap, enabling interesting use cases.

Try out Portals #

Enabling via about://flags #

Try out Portals in Chrome 85 and later versions by flipping an experimental flag:

Enable the about://flags/#enable-portals flag for same-origin navigations.
For testing out cross-origin navigations, enable the about://flags/#enable-portals-cross-origin flag in addition.

During this early phase of the Portals experiment, we also recommend using a completely separate user data directory for your tests by setting the --user-data-dir command line flag. Once Portals are enabled, confirm in DevTools that you have the new shiny HTMLPortalElement.

Implement Portals #

Let's walk through a basic implementation example.

// Create a portal with the wikipedia page, and embed it
// (like an iframe). You can also use the <portal> tag instead.
portal = document.createElement('portal');
portal.src = 'https://en.wikipedia.org/wiki/World_Wide_Web';
portal.style = '...';
document.body.appendChild(portal);

// When the user touches the preview (embedded portal):
// do fancy animation, e.g. expand …
// and finish by doing the actual transition.
// For the sake of simplicity, this snippet will navigate
// on the `onload` event of the Portals element.
portal.addEventListener('load', (evt) => {
   portal.activate();
});

It's that simple. Try this code in the DevTools console, the wikipedia page should open up.

If you wanted to build something like we showed at Chrome Dev Summit which works just like the demo above, the following snippet will be of interest.

// Adding some styles with transitions
const style = document.createElement('style');
style.innerHTML = `
  portal {
    position:fixed;
    width: 100%;
    height: 100%;
    opacity: 0;
    box-shadow: 0 0 20px 10px #999;
    transform: scale(0.4);
    transform-origin: bottom left;
    bottom: 20px;
    left: 20px;
    animation-name: fade-in;
    animation-duration: 1s;
    animation-delay: 2s;
    animation-fill-mode: forwards;
  }
  .portal-transition {
    transition: transform 0.4s;
  }
  @media (prefers-reduced-motion: reduce) {
    .portal-transition {
      transition: transform 0.001s;
    }
  }
  .portal-reveal {
    transform: scale(1.0) translateX(-20px) translateY(20px);
  }
  @keyframes fade-in {
    0%   { opacity: 0; }
    100% { opacity: 1; }
  }
`;
const portal = document.createElement('portal');
// Let's navigate into the WICG Portals spec page
portal.src = 'https://wicg.github.io/portals/';
// Add a class that defines the transition. Consider using
// `prefers-reduced-motion` media query to control the animation.
// https://developers.google.com/web/updates/2019/03/prefers-reduced-motion
portal.classList.add('portal-transition');
portal.addEventListener('click', (evt) => {
  // Animate the portal once user interacts
  portal.classList.add('portal-reveal');
});
portal.addEventListener('transitionend', (evt) => {
  if (evt.propertyName == 'transform') {
    // Activate the portal once the transition has completed
    portal.activate();
  }
});
document.body.append(style, portal);

It is also easy to do feature detection to progressively enhance a website using Portals.

if ('HTMLPortalElement' in window) {
  // If this is a platform that have Portals...
  const portal = document.createElement('portal');
  ...
}

If you want to quickly experience what Portals feel like, try using uskay-portals-demo.glitch.me. Be sure you access it with Chrome 85 or later versions and turn on the experimental flag!

Enter a URL you want to preview.
The page will then be embedded as a <portal> element.
Click on the preview.
The preview will be activated after an animation.

Check out the spec #

We are actively discussing the Portals spec in the Web Incubation Community Group (WICG). To quickly get up to speed, take a look at some of the key scenarios. These are the three important features to familiarize yourself with:

The <portal> element: The HTML element itself. The API is very simple. It consists of the src attribute, the activate function and an interface for messaging (postMessage). activate takes an optional argument to pass data to the <portal> upon activation.
The portalHost interface: Adds a portalHost object to the window object. This lets you check if the page is embedded as a <portal> element. It also provides an interface for messaging (postMessage) back to the host.
The PortalActivateEvent interface: An event that fires when the <portal> is activated. There is a neat function called adoptPredecessor which you can use to retrieve the previous page as a <portal> element. This allows you to create seamless navigations and composed experiences between two pages.

Let's look beyond the basic usage pattern. Here is a non-exhaustive list of what you can achieve with Portals along with sample code.

Customize the style when embedded as a `<portal>` element #

// Detect whether this page is hosted in a portal
if (window.portalHost) {
  // Customize the UI when being embedded as a portal
}

Messaging between the `<portal>` element and `portalHost` #

// Send message to the portal element
const portal = document.querySelector('portal');
portal.postMessage({someKey: someValue}, ORIGIN);

// Receive message via window.portalHost
window.portalHost.addEventListener('message', (evt) => {
  const data = evt.data.someKey;
  // handle the event
});

Activating the `<portal>` element and receiving the `portalactivate` event #

// You can optionally add data to the argument of the activate function
portal.activate({data: {somekey: 'somevalue'}});

// The portal content will receive the portalactivate event
// when the activate happens
window.addEventListener('portalactivate', (evt) => {
  // Data available as evt.data
  const data = evt.data;
});

Retrieving the predecessor #

// Listen to the portalactivate event
window.addEventListener('portalactivate', (evt) => {
  // ... and creatively use the predecessor
  const portal = evt.adoptPredecessor();
  document.querySelector('someElm').appendChild(portal);
});

Knowing your page was adopted as a predecessor #

// The activate function returns a Promise.
// When the promise resolves, it means that the portal has been activated.
// If this document was adopted by it, then window.portalHost will exist.
portal.activate().then(() => {
  // Check if this document was adopted into a portal element.
  if (window.portalHost) {
    // You can start communicating with the portal element
    // i.e. listen to messages
    window.portalHost.addEventListener('message', (evt) => {
      // handle the event
    });
  }
});

By combining all of the features supported by Portals, you can build really fancy user experiences. For instance, the demo below demonstrates how Portals can enable a seamless user experience between a website and third party embed content.

Use cases and plans #

We hope you liked this brief tour of Portals! We can't wait to see what you can come up with. For instance, you might want to start using Portals for non-trivial navigations such as: pre-rendering the page for your best-seller product from a product category listing page.

Another important thing to know is that Portals can be used in cross-origin navigations, just like an <iframe>. So, if you have multiple websites that cross reference one another, you can also use Portals to create seamless navigations between two different websites. This cross-origin use case is very unique to Portals, and can even improve the user experience of SPAs.

Feedback welcome #

Portals are ready for experimentation in Chrome 85 and later versions. Feedback from the community is crucial to the design of new APIs, so please try it out and tell us what you think! If you have any feature requests or feedback, please head over to the WICG GitHub repo.

Yusuke Utsunomiya on web.dev

Five ways AirSHIFT improved their React app's runtime performance

Slow response, less productivity #

1. Virtualize large tables #

Results #

2. Audit with User Timing API #

Results #

3. Lazy load components and move expensive logic to web workers #

Results #

4. Setting a performance budget #

Results #

5. Performance hackathons #

Results #

Summary #

Hands-on with Portals: seamless navigation on the web

What Portals enable #

Try out Portals #

Enabling via about://flags #

Implement Portals #

Check out the spec #

Customize the style when embedded as a <portal> element #

Messaging between the <portal> element and portalHost #

Activating the <portal> element and receiving the portalactivate event #

Retrieving the predecessor #

Knowing your page was adopted as a predecessor #

Use cases and plans #

Feedback welcome #

Customize the style when embedded as a `<portal>` element #

Messaging between the `<portal>` element and `portalHost` #

Activating the `<portal>` element and receiving the `portalactivate` event #