본 문서는 Framer를 배우는 국내 사용자들이 한글 자료의 부족으로 겪는 어려움을 해결하고자, 공식 블로그의 내용을 한국어로 번역하고 실무에 유용한 정보를 추가했습니다. 프레이머를 사용하는 여러분께 작게나마 도움이 되길 바랍니다.

Framer 사이트가 인터랙티브해지는 방법?

웹사이트는 기본적으로 HTML로 이루어지고, 여기에 JavaScript가 더해져야 버튼 클릭이나 텍스트 입력 같은 상호작용이 가능해집니다. 빠른 초기 로딩을 위해 Framer는 먼저 HTML을 서버 측 렌더링으로 전달합니다. 이렇게 하면 사용자와 검색 엔진이 화면을 바로 볼 수 있지요.

동시에 프로세스에 필요한 JavaScript도 로드되는데, 이것이 바로 하이드레이션(hydration)이라는 과정입니다. React가 HTML을 받아 이벤트 리스너를 붙여주는 단계로, 여기서부터 사이트가 클릭이나 스크롤 같은 동작에 반응할 수 있습니다. 즉, 이때 비로소 사이트가 ‘인터랙티브’해진다고 말할 수 있습니다.

일부 JavaScript 기반 요소는 이를 위해 서버에서 데이터를 가져와야만 인터랙티브해질 수 있습니다. 예를 들어 Framer 홈페이지에서는 빨간색으로 표시된 영역에 사용자의 로그인 상태를 서버에서 가져와야 하는 것처럼요.

다른 사이트에서는 리뷰, 최신 블로그 글, 날씨 등이 필요할 수 있습니다. 이를 매번 가져오는데는 시간이 좀 걸리는데요. 특히 데이터를 한번 가져올 때 또 다른 데이터를 가져와야 한다는 요청은 연쇄적으로 이어질 수 있고, 이 모든 작용은 하이드레이션 도중에 모두 처리되게 됩니다.

이제부터는 좀 더 기술적인 내용을 통해, 실제로 어떤 일이 일어나는지 보여드리겠습니다. 기술적인 세부 사항을 건너뛰고 싶으시다면 바로 마지막 장으로 넘어가셔도 됩니다.

React: Suspense와 Hydration의 관계

하이드레이션 도중 데이터를 불러올 때 React의 Suspense 기능을 사용합니다. Suspense는 “이 컴포넌트는 지금 뭔가를 기다리고 있다”라고 React에 알려주는 장치입니다.

기존에는 이를 위해 Suspense 인스턴스를 하나만 사용했는데요, 예시는 다음과 같습니다.

<App>
  <Suspense>
    <Page>
      <Header />
      <DataFetching content="blog" /> {/* ⬅️ Suspense 발생 */}
      <DataFetching content="footer" /> {/* ⬅️ Suspense 발생 */}
    </Page>
  </Suspense>
</App>

즉, ‘blog’와 ‘footer’ 데이터를 가져올 때마다 단일 Suspense 태그 “Suspense boundary”가 발동합니다. (이를 ‘suspending’이라고도 합니다.) React는 이 두 컴포넌트의 데이터 요청을 병렬 조합으로 시작하지만, 문제는 세부적인 동작에 있습니다.

하이드레이션 도중에 어떤 컴포넌트가 suspend 되었다가 데이터를 받아 다시 unsuspend 되면, React는 해당 컴포넌트를 잡은 Suspense 경계부터 하이드레이션을 다시 시작합니다.

이 말은 위 예시에서 데이터를 요청할 때마다 React가 <App> 아래의 단일 Suspense 태그부터 다시 렌더링을 시작한다는 뜻입니다. 예를 들어 ‘blog’ 데이터를 가져올 때 React는 <Header>와 두 개의 <DataFetching> 자식 컴포넌트를 모두 다시 렌더링합니다. ‘footer’ 데이터를 가져올 때도 같은 일이 일어나게 되는 겁니다.

즉, 한 번만 렌더링해도 될 부분이 여러 번 반복되는 것이죠.각 데이터가 페칭되있는 컴포넌트가, 해당 부모 컴포넌트를 다시 렌더링하게 만드는 것이죠. 예시에서 각 데이터 페처에 자식 컴포넌트가 있다고 가정하면 총 12번의 렌더링이 발생합니다. <Page>와 <Header>는 3번, blog 데이터 페처와 그 자식 컴포넌트들은 2번, footer 데이터 페처와 그 자식 컴포넌트들은 1번 렌더링되는 계산입니다 (= 6 + 4 + 2).

더 빠른 Hydration: 세분화된 Suspense

위의 예시는 작은 예제에서는 빠르게 돌아갈 수 있지지만, 실제 수백·수천 개의 컴포넌트가 있는 웹사이트라면 속도가 크게 느려지게 될 겁니다. 또한 렌더링 속도는 기기(특히 CPU)에 따라 달라집니다. 사용자에 따라 기기 속도가 다를 수 있으며, 사용자들이 동일하게 빠른 경험을 누릴 수 있도록 하는 게 관건이겠죠.

처음에는 메모이제이션( React.memo)으로 이를 해결하려 했는데요, 만약 이렇게 한다면 React가 해당 컴포넌트들을 다시 렌더링하지 않을까요? 아쉽지만, React는 Suspense 경계의 자식 컴포넌트들을 위해 다시 렌더링을 예약하기 때문에 이는 별로 효과가 없습니다.

이 문제를 해결하기 위해서는 데이터를 가져오는 구성 요소 주변에 세분화된 Suspense 경계를 추가해야 합니다.

<App>
  <Suspense>
    <Page>
      <Header />
      <Suspense><DataFetching content="blog" /></Suspense> {/* 🎉 독립된 바운더리 */}
      <Suspense><DataFetching content="footer" /></Suspense> {/* 🎉 독립된 바운더리 */}
    </Page>
  </Suspense>
</App>

이제 각 Suspense 경계는 그 아래의 트리 구조에서 멈춘 컴포넌트를 포착할 수 있습니다. React는 멈춘 컴포넌트를 포착한 지점부터 바로 하이드레이션을 재개하므로, 전체 렌더링을 반복할 필요가 없게 되겠죠. 실제로 Framer 홈페이지는 기존 1개에서 무려 151개의 세분화된 바운더리로 경계를 확장했습니다.

이렇게 하면 모든 컴포넌트가 하이드레이션 중에 한 번씩만 렌더링되므로 하이드레이션 과정이 (n구성 요소 트리의 노드 수에 따라) O(n) 선형 속도로 정리됩니다. 빠르고 선형적인 프로세스가 된다는 거죠, 트리 안에 데이터 페처가 몇 개가 있는지는 중요하지 않습니다.

Framer 사이트에 주는 의미

베타 테스트 결과, 이 변화로 많은 기기에서 하이드레이션 속도가 50~80% 빨라졌고, 하이드레이션 중 사이트에 필요한 데이터 양에 따라, 느린 기기에서의 속도는 최대 200%까지 향상될 수 있다는 겁니다. 덕분에 스크롤 애니메이션이 더 빨리 작동하고, 사용자가 사이트와 상호작용할 수 있는 시점이 크게 앞당겨졌습니다.

(왼쪽: 이전, 오른쪽: 이후, 최신 Chrome 프로필에서 6배 CPU 스로틀링과 4G 속도를 적용한 M2 Pro에서 녹화되었습니다.)

결론적으로, 스크롤 애니메이션이 더 빨리 작동하기 시작하고 사용자가 Framer 사이트와 더 빨리 상호작용할 수 있게 되었습니다. 또한 SVG가 많은 페이지에서도 개선이 있었습니다. SVG 로딩과 동시에 하이드레이션을 시작하는데요. 모바일 기기에서 방문하는 모든 Framer 사이트에서 측정한 결과, 쿠키 배너 같은 요소가 평균 42% 더 빠르게 나타납니다.

빠른 기기에서도 이 변화를 체감할 수 있습니다. M2 Pro 맥북에서 100Mbit/s 네트워크로 테스트했을 때도 하이드레이션 완료 시점이 눈에 띄게 앞당겨졌습니다.

(왼쪽: 사용 전, 오른쪽: 사용 후, 최신 Chrome 프로필을 적용하고 100MBit/s 인터넷 연결을 갖춘 M2 Pro Mac에서 녹화되었습니다.)

Framer 사용자라면 이번 변경은 별도의 작업 없이 자동으로 적용됩니다. 사이트를 다시 퍼블리시하면 바로 이러한 향상된 성능을 경험할 수 있습니다. 특별히 문제를 조사하고 원인을 찾아낸 성능 엔지니어 Ivan Akulov에게 감사드립니다.

성과와 관련된 질문이나 우려 사항이 있으시면 커뮤니티 포럼에서 성과팀에 문의해 주시기 바랍니다.

본 글은 Framer 공식 블로그의 ‘Sites now become interactive 50% faster’를 번역·각색한 콘텐츠입니다.