React 18's Concurrent Rendering for Stress Testing: A 3D Rendering Case Studyā€‚by@dawchihliou

React 18's Concurrent Rendering for Stress Testing: A 3D Rendering Case Study

šŸš€ Concurrent rendering addresses the performance problem with rendering large UI updates while keeping the UI responsive. šŸ§‘ā€šŸ”¬ We'll use 3D rendering in the browser to stress test React 18. āš–ļø We'll look at the typical approaches alongside concurrent rendering and discuss their pros and cons.
image
Daw-Chih Liou HackerNoon profile picture

Daw-Chih Liou

I write for engineers. I write about web technology, coding patterns, and best practices from my learnings.

github social icontwitter social iconlinkedin social icon

TL;DR

  • šŸš€Ā Concurrent rendering addresses the performance problem with rendering large UI updates while keeping the UI responsive.
  • šŸ§‘ā€šŸ”¬Ā We'll use 3D rendering in the browser to stress test React 18.
  • āš–ļøĀ We'll look at the typical approaches alongside concurrent rendering and discuss their pros and cons.

In this article, we are diving into a 3D visualization and discuss how to optimize its performance step by step with React 18's concurrent rendering. Here's the sneak peek.

Concurrent Rendering with useTransition

React 18 introduces the concurrent features. The core idea is to classify state updates into two categories:

  • Urgent updates: they provide responsive feedback to user interactions, like typing and clicking.
  • Transition updates: they provide non-urgent UI transitions, like displaying dataset.

The purpose is to create a snappier and more responsive experience for the users.

Before React 18, all updates are considered urgent, and a simple click or typing can cause the screen to freeze when there's a larger rending. So in React 18, by deferring non-urgent updates to urgent updates, users are able to receive immediate feedback from their interaction while React is working on the non-urgent updates in the background and reflect the result when ready.

According to the working group, the concurrent rendering is able to perform the following things:

  • Yielding: React will periodically stop working and let the browser fire one or more side effects.
  • Interrupting: When React detects new urgent updates, it will interrupt and pause non-urgent updates and start working on incoming urgent updates so the page can stay responsive.
  • Skipping old results: React will discard outdated transition updates and only render with the newest state.

Weā€™ll use the format and methods from the articles to test the 3D rendering demo and observe the impact on the performance and user experience.

3D Rendering Demo Overview

In order to create heavy computations for rendering, I built a 3D visualization to show the connections between a GitHub user and the users she's connected with on GitHub.

The technology includes:

The UI looks like this:

image

The components we will be discussing today includes:

  • Search Bar: to search for a GitHub username and fetch the user info from the GitHub GraphQL API.
  • Scene: to visualize the connections between the user and her connections in on a 3D globe.

You can findĀ the repository on GitHubĀ andĀ the demo on Netlify.

Please note that the demo might crash due to a task timeout. The timeout is caused by the slow experimental API call to fetch the coordinates of the cities. If you'd like to interact with the demo, it's recommended to fork the repository and run the development server locally.

As we type into the search bar, you'll see an increasing amount of stars in the scene to simulate the high rendering demand on the UI. The amount of stars isĀ 

100,000 * inputValue.length
. We'll use it to stress test concurrent rendering.

The Problem

Let's start with our base case with the most basic implementation. The outcome looks like this:

You can see my typing on the bottom left corner of the video.

As I was typing, the search bar was frozen. It didn't display the input value until the very end. Not just the search bar, the scene was frozen too. The stars didn't get rendered until I finished typing. Ideally, we want to be able to observe immediate feedback from our typing.

Let's look into the performance together. We'll slow down the CPU by 4x and run a performance profiling.

image

You can see the big chunks of tasks with keypress event in the flame chart. With each keypress, React computes the next rendering for the SearchBar and the Scene. As we see in the chart, the longest task takes almost 0.8 seconds to complete. That's why the page feels so slow.

So, what's happening?

In the Home page component, the SearchBar listens to the keypress event and update theĀ usernameĀ when changes happens.

const Home: NextPage = () => {
  const [username, setUsername] = useState<string>('')

  const vertices = useMemo(() => computeVertices(username.length), [username])

  const handleChange = (username: string) => {
    setUsername(username)
  }

  return (
    <>
      <SearchBar value={username} onChange={handleChange} />
      <Scene vertices={vertices} />
    </>
  )
}

Whenever there's aĀ usernameĀ update, React recomputesĀ verticesĀ by callingĀ computeVertices()Ā and pass the result in to the Scene component to render the stars. Since the number of vertices isĀ 100,000 * username.length, coupling the two state updates together is a very expensive rendering cycle.

How Did We Fix It Before React 18?

Ideally, we want to see what we typed in the search bar immediately. Knowing that updating both states in the same rendering cycle takes too long, we can simply split the two updates so that SearchBar and Scene gets rendered separately.

Let's first add a new state for the SearchBar:

type FastSearchBarProps = {
  defaultValue: string
  onChange: (value: string) => void
}

function FastSearchBar({ defaultValue, onChange }: FastSearchBarProps) {
  // new state designated to SearchBar
  const [value, setValue] = useState(defaultValue)

  const handleChange = (value: string) => {
    // update input value
    setValue(value)

    // update vertices
    onChange(value)
  }

  return <SearchBar value={value} onChange={handleChange} />
}

const Home: NextPage = () => {
  const [username, setUsername] = useState<string>('')

  const vertices = useMemo(() => computeVertices(username.length), [username])

  const handleChange = (username: string) => {
    setUsername(username)
  }

  return (
    <>
      <FastSearchBar defaultValue={username} onChange={handleChange} />
      <Scene vertices={vertices} />
    </>
  )
}

Now we have aĀ valueĀ state for SearchBar and aĀ usernameĀ state for computingĀ vertices. We'll need additional work to separate the renderings because React will batch the state updates together in the same event to avoid additional rendering. Let's take a look at some of the typical approaches.

Approach #1: setTimeout

We can simply defer the slower update by adding setTimeout to put the it in the event loop.

function FastSearchBar({ defaultValue, onChange }: FastSearchBarProps) {
  const [value, setValue] = useState(defaultValue)

  const handleChange = (value: string) => {
    setValue(value)

    setTimeout(() => {
      onChange(value)
    }, 0)
  }

  return <SearchBar value={value} onChange={handleChange} />
}

Now even with the 4x slowdown, the SearchBar looks more responsive. We also observed that the stars are getting rendered while we were typing.

If you take a look at the performance profile, you can see that we were able to separate the keypress events from the expensive tasks.

image

However, we noticed that the Scene was rendered twice after the last keypress event. That's because the renderings were still scheduled with outdated state when theĀ setTimeouts were fired.

Approach #2: Debouncing

We can actually cancel the rendering schedule by implementing debouncing.

function FastSearchBar({ defaultValue, onChange }: FastSearchBarProps) {
  const [value, setValue] = useState(defaultValue)
  const timeout = useRef<NodeJS.Timeout>()

  const handleChange = (value: string) => {
    // cancel the schedule if `value` changed within 100ms.
    clearTimeout(timeout.current)

    setValue(value)

    // schedule a new update if input value hasn't changed for 100ms.
    timeout.current = setTimeout(() => {
      onChange(value)
    }, 100)
  }

  return <SearchBar value={value} onChange={handleChange} />
}

The user experience looks better now. The SearchBar stays fairly responsive with 4x slowdown and the redundant update on the Scene after the last keypress event was gone.

However, the shortcoming of debouncing in this case is that the Scene update will always be delayed by 100ms. With faster CPU, the delay is most likely redundant and it makes the page feel slow.

image

React 18's Concurrent Rendering: startTransition

The page feel more responsive with either adding setTimeout or debouncing, but they introduces different problems:

setTimeout: results in additional UI updates with outdated statesdebouncing: results in artificial delay in UI updates

Let's take a look at how React 18 solves the problems with concurrent rendering:

import { startTransition } from 'react'

type FastSearchBarProps = {
  defaultValue: string
  onChange: (value: string) => void
}

function FastSearchBar({ defaultValue, onChange }: FastSearchBarProps) {
  const [value, setValue] = useState(defaultValue)

  const handleChange = (value: string) => {
    setValue(value)
    onChange(value)
  }

  return <SearchBar value={value} onChange={handleChange} />
}

const Home: NextPage = () => {
  const [username, setUsername] = useState<string>('')

  const vertices = useMemo(
    () => computeCoordinates(username.length),
    [username]
  )

  const handleChange = (username: string) => {
    // defer username update in a less urgent UI transition
    startTransition(() => {
      setUsername(username)
    })
  }

  return (
    <Container>
      <FastSearchBar defaultValue={username} onChange={handleChange} />
      <Scene vertices={vertices} />
    </Container>
  )
}

We callĀ setUsernameĀ inside ofĀ startTransitionĀ function. It tells React to deferĀ setUsernameĀ to the other urgent updates.

As you can see, we are able to separate the rendering of SearchBar and Scene without any asynchronous functions. If we take a look at the performance profile, we can observe a few things:

  • The keypress events are separated from the long rendering function calls.
  • The keypress events are grouped. It aligns with theĀ yieldingĀ behavior in concurrent rendering.
  • There's only one rendering call after the last group of keypress events. It aligns with theĀ skipping old resultsĀ behavior in concurrent rendering.

TheĀ interruptingĀ behavior is not very straight forward to observe. If you know how to analyze it from the performance profile, please feel free toĀ !

image

Let's remove the slowdown and see the final result:

Final Thoughts

In the past, adding debouncing was the go-to solution for rendering large UI updates while keeping pages responsive. Based on this experiment, concurrent rendering makes the UI more responsive without the shortcoming of debouncing. Even for the heavy computation with at least 100,000 3D objects, concurrent rendering still helped the page to be snappy.

Here's the side-by-side comparisons:

UI Comparison with 4x CPU Throttling

Basic implementation without concurrent rendering:

Optimized implementation with concurrent rendering:

UI Comparison with No CPU Throttling

Basic implementation without concurrent rendering:

Optimized implementation with concurrent rendering:

References

This article is originally posted on Daw-Chih's website.

react to story with heart
react to story with light
react to story with boat
react to story with money
L O A D I N G
. . . comments & more!