React Windowing

🔖 Before Start

하이킹덤 프로젝트가 정신없이 마무리되고 실시간 채팅을 구현하며 아쉬운 점이 계속해서 맴돌았다. 멤버 데이터가 실시간으로 업데이트 되었을 때 채팅 내역 전체를 렌더링 해야하는 문제를 해결하지 못했기 때문이다. 이미 모든 서버가 내려간 마당에 어떻게 해야할지 막막한 부분도 있었지만 혼자 프로젝트를 만들어 windowing을 적용해보고 렌더링 성능을 비교한 후, 기존 하이킹덤 코드에 적용하는 방식으로 진행했다. 메인에 머지는 하지 않았다. 혹시 모르니...

1. 윈도잉 (Windowing)

리액트 공식문서를 보면 엄청나게 긴 리스트를 렌더링하는 경우 가상화 windowing을 권장한다고 나와있다. 리스트 전체가 아닌 부분을 렌더링해 생성되는 DOM 요소의 수를 줄이고 재렌더링 하는 시간을 줄일 수 있다고 한다.

react-virtualized VS react-window

리액트에 윈도잉 기법을 적용할 수 있는 대표적인 라이브러리는 react-window와 react-virtualized가 있다. 둘 다 똑같은 개발자가 만들었는데, react-virtualized에 불필요한 기능과 컴포넌트가 많아 더 빠르고 용량이 작은 react-window를 만들었다고 한다. 그래서 나는 react-window를 사용했다. 공식문서도 잘 나와있어 쉽게 적용할 수 있다.

우선 10000개의 더미 데이터를 생성하고 멤버 데이터가 변경되었을 때를 재현하고자 버튼을 눌렀을 때 전부 다른 데이터로 교체되게끔 만들었다.

📍 기존 코드

{
// 생략
   return (
    <div>
      <div className="chat-list">
        {chatList.map((chat) => {
          return <ListItem chat={chat} key={chat.key} />
        })}
      </div>
      <button onClick={handleClick}>멤버 변경</button>
    </div>
  )
}

📍 windowing 적용

import { FixedSizeList as List } from 'react-window'
// 생략
  return (
    <>
      <div className="chat-list">
        <List
          height={300}
          itemCount={chatList.length}
          itemSize={20}
          itemData={chatList}
        >
          {Column}
        </List>
      </div>
      <button onClick={handleClick}>멤버 변경</button>
    </>
  )
}


 const Column = (props) => {
  return (
    <div className={props.index % 2 ? 'odd' : 'even'} style={props.style}>
      {props.index}
      {props.data[props.index].content}
    </div>
  )
}

export default App

2. Lighthouse

Lighthouse 공식문서에 각 지표별 설명이 자세하게 나와있다. Lighthouse 10을 기준으로 성능 측정 기준을 보면 다음과 같다.

Metric	설명
First Contentful Paint	페이지 처음 로드된 시점부터 페이지 콘텐츠의 일부가 화면에 렌더링되는 시점까지의 시간
Speed Index	페이가 로드될 때 콘텐츠가 얼마나 빨리 표시되는지의 시간
Largest Contentful Paint	페이지가 처음 로드된 시점을 기준으로 가장 큰 이미지 또는 텍스트 블록의 렌더링 시간
Total Blocking Time	사용자가 페이지와 상호작용할 수 있을 때까지 걸리는 시간
Cumulative Layout Shift	사용자가 예상치 못한 레이아웃 변경을 경험하는 빈도

[FCP와 Speed Index의 차이]

FCP
- 첫 번째 콘텐츠가 브라우저 화면에 그려지기 시작하는 시간.
- 사용자는 웹페이지가 로드되고 있는지 인식할 수 있다.

Speed Index
- 페이지가 로드되고 화면이 얼마나 빠르게 채워지는지 측정한 시간.
- 사용자는 페이지 전체를 인식하고 상호작용할 수 있다.

Lighthouse 결과

📍 기존 코드

📍 windowing 적용

TBT (Total Blocking Time)

TBT와 Speed Index에서 가장 큰 차이가 났다. TBT는 화면이 로드되고 난 이후에 사용자가 실질적으로 페이지와 상호작용할 수 있을 때까지의 시간을 측정한 것이다. Lighthouse 성능 측정에서 가장 많은 점수를 차지하고 있다.

TBT는 결국 FCP와 TTI의 시간 차이를 계산한 것이다. 첫 콘텐츠가 화면에 그려지고(FCP) 사용자가 그것을 클릭했을 때(TTI) 아무런 반응이 없는 시간이 길어질 수록 TBT는 길어지고 성능 점수는 낮아진다. 내 코드에서는 렌더링하는 노드의 개수가 다르다보니 TBT 점수에서 차이가 난다고 판단했다. 렌더링 해야하는 요소가 많아질 수록 사용자의 입력을 감지할 수 있는 시간이 늦춰지기 때문이다. 멤버 데이터가 실시간으로 변경되고, 변경을 반영해 렌더링하는 동안 사용자가 채팅 전송 버튼을 누른다면 아무런 반응도 하지 않을 가능성이 높다.

[ TTI (Time To Interative) ]

사용자가 페이지와 상호작용할 수 있는 시간

TBT 점수는 어떻게 개선할 수 있을까? TBT 공식문서를 보면 불필요한 자바스크립트 코드를 줄이라고 나온다. 메인 스레드가 페이지를 로드하는 것과 상관 없는 불필요한 작업을 하도록 만들기 때문이다. 그리고 비효율적인 자바스크립트 코드를 줄여야한다고 권장한다.

3. Profiler

React Profiler로도 렌더링 성능을 측정해봤다.

📍 기존 코드

📍 windowing 적용

4. Chrome Performance

유휴 상태는 브라우저가 작업을 수행하지 않는 상태를 말한다. 유휴 시간이 길 수록 사용자 입력에 빠르게 반응할 수 없어 사용자 경험이 떨어진다. 앞서 말한 TBT와 같다고 볼 수 있겠다.

📍 기존 코드

📍 windowing 적용

비판은 환영이지만 비난은 마음 아파요.