Framerサイトがインタラクティブになる方法は？

ウェブサイトは基本的にHTMLで構成されており、ここにJavaScriptが加わることでボタンのクリックやテキスト入力といったインタラクションが可能になります。初期の高速読み込みのために、FramerはまずHTMLをサーバーサイドレンダリングで提供します。これにより、ユーザーと検索エンジンはすぐに画面を見ることができます。

同時にプロセスに必要なJavaScriptもロードされますが、これがハイドレーション（hydration）というプロセスです。ReactはHTMLを受け取り、イベントリスナーを追加する段階で、ここからサイトはクリックやスクロールといった動作に反応できるようになります。つまり、このとき初めてサイトが「インタラクティブ」になると言えます。

一部のJavaScriptベースの要素は、これによりサーバーからデータを取得する必要があります。例えばFramerのホームページでは、赤で表示されたエリアのユーザーのログイン情報をサーバーから取得する必要があるようにです。

他のサイトではレビュー、最新のブログ記事、天気予報などが必要になるかもしれません。これを毎回取得するには時間がかかります。特に、一度データを取得する際にさらに別のデータを取得するというリクエストが連鎖することがあり、このすべての作業はハイドレーション中に処理されることになります。

これからはもう少し技術的な内容を通じて、実際に何が起こるのかをお見せします。技術的な詳細を飛ばしたい場合は、最後の章に直接移ってください。

React: SuspenseとHydrationの関係

ハイドレーション中にデータを取得するときReactのSuspense機能を使用します。Suspenseは「このコンポーネントは今何かを待っている」とReactに知らせるデバイスです。

従来はこれにSuspenseインスタンスを1つだけ使用していました。例は次のとおりです。

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

つまり、「blog」や「footer」データを取得するたびに単一のSuspenseタグ「Suspense boundary」が発動します。(これを「suspending」とも呼びます)。Reactはこれら2つのコンポーネントのデータリクエストを並列に開始しますが、問題はその動作の詳細にあります。

ハイドレーション中にあるコンポーネントがsuspendされ、その後データを受け取って再びunsuspendされると、ReactはそのコンポーネントをキャッチしたSuspense境界から再びハイドレーションを始めます。

このため、例で見ると、データをリクエストするたびにReactが<App>の下にある単一のSuspenseタグから再度レンダリングを開始することを意味します。例として「blog」データを取得する際、Reactは<Header>と2つの<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のMacBookで100Mbit/sのネットワークを使用してテストしたときも、ハイドレーション完了の時点が目に見えて早まりました。

(左: 以前、右: 以後、最新のChromeプロファイルを適用し100MBit/sのインターネット接続を持つM2 Pro Macで録画されました。)

Framerのユーザーであれば、この変更は別段の作業無しに自動で適用されます。サイトを再パブリッシュするだけでこの向上したパフォーマンスを体験できます。特に問題解決をし原因を見つけたパフォーマンスエンジニアのIvan Akulovに感謝します。

パフォーマンスに関連する質問や懸念事項があれば、コミュニティフォーラムでパフォーマンスチームにお問い合わせください。

この記事はFramer公式ブログの「Sites now become interactive 50% faster」を翻訳・アダプトしたコンテンツです。