Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
PR TIMESにおけるNext.jsとcacheの付き合い方
Search
Ryuya Yanagi
December 10, 2024
Technology
3
2.4k
PR TIMESにおけるNext.jsとcacheの付き合い方
Ryuya Yanagi
December 10, 2024
Tweet
Share
More Decks by Ryuya Yanagi
See All by Ryuya Yanagi
開発速度を上げつつ品質を保つためのフロントエンド開発
apple_yagi
1
770
Other Decks in Technology
See All in Technology
CNAPPから考えるAWSガバナンスの実践と最適化
nrinetcom
PRO
1
330
re:Invent Recap (January 2025)
scalefactory
0
340
バクラクの組織とアーキテクチャ(要約)2025/01版
shkomine
13
2.9k
横断SREの立ち上げと、AWSセキュリティへの取り組みの軌跡
rvirus0817
3
4.5k
20250125_Agent for Amazon Bedrock試してみた
riz3f7
2
110
private spaceについてあれこれ調べてみた
operando
1
160
Microsoft Ignite 2024 最新情報!Microsoft 365 Agents SDK 概要 / Microsoft Ignite 2024 latest news Microsoft 365 Agents SDK overview
karamem0
0
190
一人から始めたSREチーム3年の歩み - 求められるスキルの変化とチームのあり方 - / The three-year journey of the SRE team, which started all by myself
vtryo
7
5.7k
Women in Agile
kawaguti
PRO
2
170
[TechNight #86] Oracle GoldenGate - 23ai 最新情報&プロジェクトからの学び
oracle4engineer
PRO
1
170
GraphRAG: What I Thought I Knew (But Didn’t)
sashimimochi
1
220
Oracle Cloud Infrastructure:2025年1月度サービス・アップデート
oracle4engineer
PRO
0
180
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
366
19k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.8k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
520
Faster Mobile Websites
deanohume
305
30k
A better future with KSS
kneath
238
17k
A designer walks into a library…
pauljervisheath
205
24k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
Building Your Own Lightsaber
phodgson
104
6.2k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
3k
Transcript
PR TIMESにおける Next.js と cache の付き合い方
自己紹介 やなぎ(25歳) PR TIMES 開発部 フロントエンドエンジニア - X(Twitter): @apple_yagi
話すこと 1. PR TIMESのNext.js運用構成 2. 3つのキャッシュ戦略 3. Next.jsとの付き合い方 4. まとめ
PR TIMESのNext.js運用構成
Next.jsの運用構成 引用元:https://developers.prtimes.jp/2023/12/13/replace-press-release-page-with-nextjs/
Pages Router or App Router - PR TIMESではPages Routerを使用している -
そのため、Next.jsでキャッシュを持つことは一切していない
3つのキャッシュ戦略
PR TIMESでNext.jsから配信されているページ - トップページ - プレスリリース掲載ページ - キーワード検索ページ
PR TIMESでNext.jsから配信されているページ - トップページ - プレスリリース掲載ページ - キーワード検索ページ
トップページ(https://prtimes.jp)
トップページのキャッシュ戦略 - 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 にのみキャッシュが保存される
キャッシュTTLの設定について Surrogate-Control: max-age=5, stale-while-revalidate=10 - キャッシュは最大で15秒しか保持しない - max-age=5:5秒間はキャッシュを返す - stale-while-revalidate=10:5秒が過ぎた後の10秒間は古いキャッ
シュを返しつつ、新しいキャッシュを生成する
なぜ15秒しか保持しないのか PR TIMESのトップページには新着プレスリリースが表示されており、プレス リリースが配信されたら、できるだけ速く反映したい
キャッシュTTLが1つのコンテンツに引っ張られる問題 プレスリリースのランキングなど、データの更新頻度があまり高くない箇所も APIからデータを取得しHTMLを生成する必要がある 更新頻度:低 更新頻度:高
App Routerを使うことで解決できそう App Routerでコンポーネントをキャッシュをすることで解決することができそう - use cacheディレクティブ良さそう ただApp Routerがキャッシュを持つのは考えることが多い -
self hostingの場合、Next.jsのキャッシュをどこに置くかが難しい - 多段キャッシュになり挙動を正確に把握するのが困難になり、キャッシュを 簡単に削除することができなくなる - キャッシュは単一の箇所で行いたい(PR TIMESでいうとCDN層)
そもそもトップページのキャッシュヒット率は良い - キャッシュヒット率は90 ~ 99%で推移 - Lighthouseのパフォーマンスは100%(キャッシュHit時/通信環境による)
トップページのキャッシュ戦略まとめ - キャッシュTTLは短め(最大15秒) - ただキャッシュヒット率は良い - URLが単一( https://prtimes.jp )でかつ、リクエスト数が多 いからと考えている
- パフォーマンスも良い - 90%以上のリクエストをCDNで返せているため
PR TIMESでNext.jsから配信されているページ - トップページ - プレスリリース掲載ページ - キーワード検索ページ
プレスリリース掲載ページ
プレスリリース掲載ページのキャッシュ戦略 - Cache-Controlは no-cache, max-age=0, must-revalidate - トップページと変わらずブラウザキャッシュはしない - Surrogate-Controlは
max-age=60, stale-while-revalidate=120 - 最大で180秒キャッシュを保持する
キャッシュTTLについて - 一度配信されたプレスリリースの更新頻度はとても少ないが180sと短い - プレスリリースが更新された時にキャッシュをパージする処理をして いないため、更新された時のことを考えてこの設定にしている - 今後はプレスリリース更新時にCDN(Fastly)のキャッシュをパージする 処理を追加し、キャッシュTTLを伸ばす予定 -
Fastlyのキャッシュパージは高速(Instant Purge) - 150ms以内にグローバルに分散されたキャッシュを削除できる - また実行回数による課金はなく、回数制限もない
キャッシュヒット率とパフォーマンス - キャッシュヒット率は26 ~ 56%で推移 - Lighthouseのパフォーマンスは95%
プレスリリース掲載ページのキャッシュ戦略まとめ - キャッシュTTLは180秒 - URLがプレスリリースによって異なるため、キャッシュヒット率は トップページより低い - キャッシュヒットした時のパフォーマンスは良い - 今後キャッシュTTLを伸ばし、キャッシュヒット率の改善を行う予定
PR TIMESでNext.jsから配信されているページ - トップページ - プレスリリース掲載ページ - キーワード検索ページ
キーワード検索ページ
キーワード検索ページのキャッシュ戦略 - Cache-Controlは no-cache, max-age=0, must-revalidate - 変わらずブラウザキャッシュはしない - Surrogate-Controlは設定していない
なぜキーワード検索ページはキャッシュしないのか - 検索するキーワードが完全一致することは多くないと想定している - https://prtimes.jp/main/action.php?run=html&page=searchkey &search_word=PRTIMES - キャッシュをするとしても1分程度を考えているため、1分間の間に何 回同じキーワードが検索されるか?を考えるとする必要がなさそう
パフォーマンス - Lighthouseのパフォーマンスは100% - キャッシュがなくてもそもそもパフォーマンスが良かった
パフォーマンス以外でのキャッシュの有効性 - オリジンサーバーへの負荷を軽減 - リクエストを前段のCDNで返すことにより、そもそもNext.jsにリク エストを到達させなくできる - プレスリリース掲載ページはSNSからの流入で急激に高負荷になるこ とがあるため(バズった時)、キャッシュを用いてアクセスを捌く必 要がある
Next.jsとの付き合い方
Next.jsの機能をほぼ使っていない - getServerSidePropsのみしか使っていない - LinkコンポーネントやuseRouterなどは使わずにハードナビゲーション を行っている - PR TIMESはパフォーマンスが良いため、ハードナビゲーションでも 問題ない
- また、ソフトナビゲーションを行うとFastlyでキャッシュをパージ するときに問題が発生する可能性がある - next/imageも使用しておらず、FastlyのImage Optimizerで画像の最適 化を行っている
Next.jsに求めているもの - 開発者体験(DX)の良いテンプレートエンジン - Reactをサーバーでレンダリングしてくれる、それだけで良い - とは言いつつ、zero configやFile-Based Routingは嬉しい -
キャッシュはFastlyでやるのでwebpackをどうにかしてくれると。。 - Viteを使いたいのでReact Router v7(Remix)に移行しようか迷っ ている - ずっとPages Routerを使い続けるのは。。
まとめ
まとめ - Next.jsをセルフホスティングで運用しFastlyでキャッシュを行っている - キャッシュ戦略はページの特性によって都度変えている - CDNのキャッシュだけでも高パフォーマンスで高負荷に耐えることができ る - Next.jsの機能は最小限の利用に留めつつ、他のフレームワークへの乗り
換えも検討している