Suspense/StreamingパターンにおけるCLSの課題と対策

課題

でComponentごとにDataFetching/Renderingする。

その際に、課題になるのが、React Server Components RSCを非同期で読み込む前後で、CLS Cumulative Layout Shiftが発生してしやすい問題がある。

イメージ

https://gyazo.com/e97169c2d7533bc6c34fa93a36bc7031

上記のような複数のReact Server Components RSCをそれぞれ別に読み込んでいる際に、各componentが入る分の高さの余白を確保していないと、そのコンポーネントの下に配置されている情報などが先に表示されていて、各componentが読み込み完了した際に位置がズレてガタつく。

対策としては、Skeleton screen スケルトンスクリーン UIによって、Componentが表示されるまでスペースを確保しつつ、ユーザーに読み込みを示すことである。

ただ、画像のCLS対策と違って、ComponentのCLS Cumulative Layout Shift対策は、手間暇がかかる。

Data Fetchingが必要なDataの自由度が高いComponentの高さを明示的にする必要がある。

Skeleton screen スケルトンスクリーン UIのデザイン及び実装が追加で必要になる。

両方とも、デザイナーとも調整が必要である。

コストがかかるため、FirstView ファーストビューに入っているComponentのみ、最低限考慮する。

FirstView ファーストビューに入っていないComponentは、処理が大きくないComponentであれば、閲覧中に読み込み完了するため、Skeleton screen スケルトンスクリーン UIは不要になる可能性も高い。

これもあって、手を抜きたくなる。

ただし、以下のケースではFirstView ファーストビューに入っていないComponentも考慮が必要になる。

スクロールして、途中の導線で別ページに遷移した後、ブラウザバックでスクロール後の位置に戻ってきたケース。

例

初期遷移時

あるページにアクセスする。

スクロールして、途中の導線で別ページに遷移する。

再遷移時

別ページに遷移した後、ブラウザの戻るボタンを押して、前のページのスクロール位置に戻って来る。

すると、Suspense/Streamingパターンで読み込まれているComponentが存在し、FirstView ファーストビューに含まれていない箇所だったので、Skeleton screen スケルトンスクリーン UIを実装していない場合、読み込み前後でCLS Cumulative Layout Shiftが発生する。

※ Router Cache Next.jsといったキャッシュはopt outしているものとする。

対策

2. Router Cache Next.jsなどを利用する。

上記の例外ケースを見ると、一度FirstView ファーストビューと想定されている箇所にアクセスし、その後スクロールして閲覧しているため、該当componentのデータは読み込みが終わっている。

そのため、再度戻ってきた際は、client cacheであるRouter Cache Next.jsを利用すれば、読み込み処理が発生しないはずである。

3. 該当箇所のSuspense/Streamingパターンを辞める。

Time to First Byte TTFBがその分増える。

個人的意見

1は負担が結構大きく、3はTime to First Byte TTFBがその分増えるのが許容しにくい。うまくキャッシュを活用した2が、開発チームや各computerの処理量にも優しいと思っている。

とりあえず、キャッシュをopt outする戦略であったが、うまく使ったほうが良いのかもしれない。

FETeamで議論した結果

一旦、3にして、気になる箇所があれば、Streaming with Suspenseパターンを利用する。