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
780
Other Decks in Technology
See All in Technology
スキルだけでは満たせない、 “組織全体に”なじむオンボーディング/Onboarding that fits “throughout the organization” and cannot be satisfied by skills alone
bitkey
0
130
Visualize, Visualize, Visualize and rclone
tomoaki0705
9
75k
ビジネスモデリング道場 目的と背景
masuda220
PRO
9
690
システム・ML活用を広げるdbtのデータモデリング / Expanding System & ML Use with dbt Modeling
i125
1
310
依存パッケージの更新はコツコツが勝つコツ! / phpcon_nagoya2025
blue_goheimochi
3
200
Reading Code Is Harder Than Writing It
trishagee
2
120
偏光画像処理ライブラリを作った話
elerac
1
150
NFV基盤のOpenStack更新 ~9世代バージョンアップへの挑戦~
vtj
0
320
PHPで印刷所に入稿できる名札データを作る / Generating Print-Ready Name Tag Data with PHP
tomzoh
0
180
RemoveだらけのPHPUnit 12に備えよう
cocoeyes02
0
130
Pwned Labsのすゝめ
ken5scal
0
190
わたしがEMとして入社した「最初の100日」の過ごし方 / EMConfJp2025
daiksy
13
3.6k
Featured
See All Featured
The Language of Interfaces
destraynor
156
24k
Rails Girls Zürich Keynote
gr2m
94
13k
Become a Pro
speakerdeck
PRO
26
5.2k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
12
980
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Navigating Team Friction
lara
183
15k
Large-scale JavaScript Application Architecture
addyosmani
511
110k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.1k
Designing for humans not robots
tammielis
250
25k
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の機能は最小限の利用に留めつつ、他のフレームワークへの乗り
換えも検討している