리액트 서버 컴포넌트는 정말 성능을 개선할까요?

SSR 은 LCP 를 빠르게 만들지만, HTML 은 보이는데 JS 가 아직 로드 안 된 시간이 생긴다. 이 동안 버튼 클릭이 무반응이라 고장난 페이지처럼 보인다.

시간:  HTML 파싱 → CSS → LCP → JS 다운로드 → JS 실행 → hydrate → 인터랙티브
        ↑                  ↑                                          ↑
        TTFB              LCP 기록                                 토글 작동
                                  ←———— 상호작용 불가능 간극 ————→

이 간극을 줄이는 유일한 방법은 초기 로드에 필요한 JS 를 줄이는 것 — 코드 스플리팅, 서버 컴포넌트, 또는 더 작은 진입점.

RSC 의 streaming 은 컴포넌트 단위 가 아니라 Suspense 경계 단위 로 청크가 나눠진다. Suspense 없이 비동기 컴포넌트만 쓰면 React 는 전체 트리 await 후 한 번에 응답한다.

// ❌ Suspense 없음 → 전체가 한 청크
export default async function Page() {
  const fast = await fetchFast();  // 100ms
  const slow = await fetchSlow();  // 1000ms
  return <Layout><Sidebar data={fast}/><Messages data={slow}/></Layout>;
}

// ✅ Suspense 경계 → 빠른 부분 먼저 stream
export default function Page() {
  return (
    <Layout>
      <Suspense fallback={<SidebarSkeleton/>}><Sidebar/></Suspense>
      <Suspense fallback={<MessagesSkeleton/>}><Messages/></Suspense>
    </Layout>
  );
}

첫 청크가 즉시 나가고, 사이드바가 100ms 에 도착, 메시지는 1초 뒤 도착 — 체감 속도는 동일하게 빠름.

Pages Router → App Router 로 데이터 패칭은 그대로 두고 옮기기만 하면 본 글의 측정에서 결과는 다음과 같다.

App Router 가 CSS 로드 후로 JS 를 지연시켜 LCP 는 좋아지지만, 그 대가로 모든 인터랙션이 늦어진다. 진짜 이득은 데이터 패칭 재작성 + Suspense 까지 했을 때만 나온다.

[감점 답변] '설정이 잘못됐다'. [좋은 답변] 대부분의 실제 앱은 상태/이벤트 핸들러 가 페이지 상단까지 거슬러 올라가 'use client' 가 트리 대부분을 덮는다. 이 경우 서버 컴포넌트의 코드는 클라이언트 번들에 그대로 포함 되므로 번들이 줄지 않는다. 데이터 패칭을 서버로 옮기는 것 + Suspense 경계 까지 함께 해야 진짜 이득이 시작된다.

[감점 답변] 'fallback 을 보여준다' 만. [좋은 답변] React 의 renderToPipeableStream 은 Suspense 경계마다 청크를 끊는다. 경계가 없으면 전체 트리를 await 한 뒤 하나의 청크로 보내므로 가장 느린 데이터를 끝까지 기다려야 HTML 이 시작된다. 즉 Suspense 가 없으면 기존 SSR 과 동일하게 동작.

[감점 답변] '다른 메트릭은 신경 안 써도 된다'. [좋은 답변] INP(Interaction to Next Paint) 와 상호작용 가능 시간 을 봐야 한다. LCP 는 시각적 도착, INP 는 클릭/입력 반응성. App Router lift-shift 처럼 LCP 가 좋아지면서 인터랙션이 느려지는 케이스가 흔하다.