[아티클요약] 리액트 렌더링의 미래

리액트 18 부터 도입된 Suspence 를 사용하면서 비동기처리가 이전보다 용이해졌습니다. 로딩 범위를 Suspence 로 묶은 영역에만 적용할 수 있다니. 속이 다 시원해졌습니다. 이런 변화가 개발 편의성에만 있는 것은 아닌가 봅니다. 이 글은 리액트 18을 전 후로 리액트 패턴 변화로 인해 상당한 성능향상을 보이고 있음을 서술합니다. 각각의 동작을 영상으로 쉽게 표현했으니 이해가 잘 되지 않는 부분은 본글 링크로 확인하면 좋겠습니다. [요약] 1. 리액트 18 전 렌더링 패턴 (1) Client-Side Rendering(CSR) - 페이지 로드에 필요한 js script 태그와 link 태그를 포함한 간단한 HTML 을 전달받으면 필요한 모든 js 파일을 다운로드 후 화면을 그리기 시작 - TTFB(콘텐츠 첫 바이트를 수신하는 데 걸리는 시간) 이 빠름 => 이유는 간단한 HTML - js 파일을 다운로드하는 시간과 마운트 시점에 요청한 API 응답 처리 시간으로 인해 로더가 연속적으로 오래 지속함 - SEO 에 적합하지 않음 => js 파일 다운로드 후 화면 그리기 전까지 빈 화면이기 때문에 크롤링할 콘텐츠를 찾지 못할 가능성이 높음 2. 리액트 18 전 렌더링 패턴 (2) Server-Side Rendering(SSR) - 서버에서 정적인 콘텐츠를 미리 생성하여 HTML에 포함시키고 동적인 콘텐츠는 클라이언트에서 그리도록 함 (Hydration) - CSR 보다 TTFB 가 느림 => HTML 크기가 큼, NextJS 와 같은 프레임워크에서는 페이지 캐싱 기능으로 보완했음 - 콘텐츠가 일부 미리 생성되어있기 때문에 FCP(첫 콘텐츠가 표시되는 데 걸린 시간), LCP(페이지 주요 콘텐츠가 표시되는 데 걸리는 시간) 는 빠름 - 동적인 콘텐츠는 CSR 과 마찬가지로 모든 js 파일을 다운로드하므로, 동적인 콘텐츠 비중이 많은 웹사이트라면 여전히 상호작용할 수 있는 시간(TTI)은 느림 3. 리액트 18 렌더링 패턴 - 스트리밍 SSR - SSR 단계를 독립적으로 수행가능한 더 작은 단위로 쪼개서 로딩, 페인팅, 상호작용을 병렬적으로 처리함 - HTTP 스트리밍으로 로드 시간이 오래 걸리는 콘텐츠를 제외한 HTML을 먼저 받고 이후 동일한 스트림에 제외한 콘텐츠를 추가하는 최소한의 HTML을 보내줌 - Suspence 를 사용해 js 다운로드와 API 응답이 빠른 컴포넌트부터 페인팅과 상호작용 상태로 변경 4. 알파단계인 서버 컴포넌트 - 서버사이드렌더링의 병렬처리 : 최상위 페이지에서 서버데이터에 접근하여 처리하는 기존 방식과 달리 각 컴포넌트별로 수행 - 기존 SSR 보다 훨씬 더 클라이언트 사이드 번들이 작아짐