PR TIMESにおけるNext.jsとcacheの付き合い方

Transcript

1. PR TIMESにおける Next.js と cache の付き合い方
2. 自己紹介 やなぎ（25歳） PR TIMES 開発部 フロントエンドエンジニア - X（Twitter）： @apple_yagi
3. 話すこと 1. PR TIMESのNext.js運用構成 2. 3つのキャッシュ戦略 3. Next.jsとの付き合い方 4. まとめ
4. PR TIMESのNext.js運用構成
5. Next.jsの運用構成 引用元：https://developers.prtimes.jp/2023/12/13/replace-press-release-page-with-nextjs/
6. Pages Router or App Router - PR TIMESではPages Routerを使用している - そのため、Next.jsでキャッシュを持つことは一切していない
7. 3つのキャッシュ戦略
8. PR TIMESでNext.jsから配信されているページ - トップページ - プレスリリース掲載ページ - キーワード検索ページ
9. PR TIMESでNext.jsから配信されているページ - トップページ - プレスリリース掲載ページ - キーワード検索ページ
10. トップページ（https://prtimes.jp)
11. トップページのキャッシュ戦略 - Cache-Controlヘッダーは no-cache, max-age=0, must-revalidate - ブラウザにはキャッシュを持たせない - ただBFCacheは有効にしたいので no-store はつけない - Surrogate-Controlヘッダーは max-age=5, stale-while-revalidate=10 - Surrogate-ControlヘッダーはFastly独自のヘッダーで Cache-Controlと同じ内容を渡すことができる - FastlyはCache-ControlよりもSurrogate-Controlを優先し、Fastly にのみキャッシュが保存される
12. キャッシュTTLの設定について Surrogate-Control: max-age=5, stale-while-revalidate=10 - キャッシュは最大で15秒しか保持しない - max-age=5：5秒間はキャッシュを返す - stale-while-revalidate=10：5秒が過ぎた後の10秒間は古いキャッ シュを返しつつ、新しいキャッシュを生成する
13. なぜ15秒しか保持しないのか PR TIMESのトップページには新着プレスリリースが表示されており、プレス リリースが配信されたら、できるだけ速く反映したい
14. キャッシュTTLが1つのコンテンツに引っ張られる問題 プレスリリースのランキングなど、データの更新頻度があまり高くない箇所も APIからデータを取得しHTMLを生成する必要がある 更新頻度：低 更新頻度：高
15. App Routerを使うことで解決できそう App Routerでコンポーネントをキャッシュをすることで解決することができそう - use cacheディレクティブ良さそう ただApp Routerがキャッシュを持つのは考えることが多い - self hostingの場合、Next.jsのキャッシュをどこに置くかが難しい - 多段キャッシュになり挙動を正確に把握するのが困難になり、キャッシュを 簡単に削除することができなくなる - キャッシュは単一の箇所で行いたい（PR TIMESでいうとCDN層）
16. そもそもトップページのキャッシュヒット率は良い - キャッシュヒット率は90 ~ 99%で推移 - Lighthouseのパフォーマンスは100%（キャッシュHit時/通信環境による）
17. トップページのキャッシュ戦略まとめ - キャッシュTTLは短め（最大15秒） - ただキャッシュヒット率は良い - URLが単一（ https://prtimes.jp ）でかつ、リクエスト数が多 いからと考えている - パフォーマンスも良い - 90%以上のリクエストをCDNで返せているため
18. PR TIMESでNext.jsから配信されているページ - トップページ - プレスリリース掲載ページ - キーワード検索ページ
19. プレスリリース掲載ページ
20. プレスリリース掲載ページのキャッシュ戦略 - Cache-Controlは no-cache, max-age=0, must-revalidate - トップページと変わらずブラウザキャッシュはしない - Surrogate-Controlは max-age=60, stale-while-revalidate=120 - 最大で180秒キャッシュを保持する
21. キャッシュTTLについて - 一度配信されたプレスリリースの更新頻度はとても少ないが180sと短い - プレスリリースが更新された時にキャッシュをパージする処理をして いないため、更新された時のことを考えてこの設定にしている - 今後はプレスリリース更新時にCDN（Fastly）のキャッシュをパージする 処理を追加し、キャッシュTTLを伸ばす予定 - Fastlyのキャッシュパージは高速（Instant Purge） - 150ms以内にグローバルに分散されたキャッシュを削除できる - また実行回数による課金はなく、回数制限もない
22. キャッシュヒット率とパフォーマンス - キャッシュヒット率は26 ~ 56%で推移 - Lighthouseのパフォーマンスは95%
23. プレスリリース掲載ページのキャッシュ戦略まとめ - キャッシュTTLは180秒 - URLがプレスリリースによって異なるため、キャッシュヒット率は トップページより低い - キャッシュヒットした時のパフォーマンスは良い - 今後キャッシュTTLを伸ばし、キャッシュヒット率の改善を行う予定
24. PR TIMESでNext.jsから配信されているページ - トップページ - プレスリリース掲載ページ - キーワード検索ページ
25. キーワード検索ページ
26. キーワード検索ページのキャッシュ戦略 - Cache-Controlは no-cache, max-age=0, must-revalidate - 変わらずブラウザキャッシュはしない - Surrogate-Controlは設定していない
27. なぜキーワード検索ページはキャッシュしないのか - 検索するキーワードが完全一致することは多くないと想定している - https://prtimes.jp/main/action.php?run=html&page=searchkey &search_word=PRTIMES - キャッシュをするとしても1分程度を考えているため、1分間の間に何 回同じキーワードが検索されるか？を考えるとする必要がなさそう
28. パフォーマンス - Lighthouseのパフォーマンスは100% - キャッシュがなくてもそもそもパフォーマンスが良かった
29. パフォーマンス以外でのキャッシュの有効性 - オリジンサーバーへの負荷を軽減 - リクエストを前段のCDNで返すことにより、そもそもNext.jsにリク エストを到達させなくできる - プレスリリース掲載ページはSNSからの流入で急激に高負荷になるこ とがあるため（バズった時）、キャッシュを用いてアクセスを捌く必 要がある
30. Next.jsとの付き合い方
31. Next.jsの機能をほぼ使っていない - getServerSidePropsのみしか使っていない - LinkコンポーネントやuseRouterなどは使わずにハードナビゲーション を行っている - PR TIMESはパフォーマンスが良いため、ハードナビゲーションでも 問題ない - また、ソフトナビゲーションを行うとFastlyでキャッシュをパージ するときに問題が発生する可能性がある - next/imageも使用しておらず、FastlyのImage Optimizerで画像の最適 化を行っている
32. Next.jsに求めているもの - 開発者体験（DX）の良いテンプレートエンジン - Reactをサーバーでレンダリングしてくれる、それだけで良い - とは言いつつ、zero configやFile-Based Routingは嬉しい - キャッシュはFastlyでやるのでwebpackをどうにかしてくれると。。 - Viteを使いたいのでReact Router v7（Remix）に移行しようか迷っ ている - ずっとPages Routerを使い続けるのは。。
33. まとめ
34. まとめ - Next.jsをセルフホスティングで運用しFastlyでキャッシュを行っている - キャッシュ戦略はページの特性によって都度変えている - CDNのキャッシュだけでも高パフォーマンスで高負荷に耐えることができ る - Next.jsの機能は最小限の利用に留めつつ、他のフレームワークへの乗り 換えも検討している