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
1.9k
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
750
Other Decks in Technology
See All in Technology
OCI技術資料 : ファイル・ストレージ 概要
ocise
3
12k
CDKのコードレビューを楽にするパッケージcdk-mentorを作ってみた/cdk-mentor
tomoki10
0
140
The future we create with our own MVV
matsukurou
0
1.8k
KMP with Crashlytics
sansantech
PRO
0
190
Godot Engineについて調べてみた
unsoluble_sugar
0
290
「隙間家具OSS」に至る道/Fujiwara Tech Conference 2025
fujiwara3
6
4.4k
AI×医用画像の現状と可能性_2024年版/AI×medical_imaging_in_japan_2024
tdys13
1
1.3k
商品レコメンドでのexplicit negative feedbackの活用
alpicola
1
220
東京Ruby会議12 Ruby と Rust と私 / Tokyo RubyKaigi 12 Ruby, Rust and me
eagletmt
2
720
20241125 - AI 繪圖實戰魔法工作坊 @ 實踐大學
dpys
1
460
20240513 - 框裡框外_文學院學生如何在AI世代安身立命 @ 淡江大學
dpys
0
640
0→1事業こそPMは営業すべし / pmconf #落選お披露目 / PM should do sales in zero to one
roki_n_
PRO
1
290
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
950
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
19
2.3k
Adopting Sorbet at Scale
ufuk
74
9.2k
Designing Experiences People Love
moore
139
23k
How GitHub (no longer) Works
holman
312
140k
RailsConf 2023
tenderlove
29
970
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
172
50k
Bash Introduction
62gerente
610
210k
Scaling GitHub
holman
459
140k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.4k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.7k
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の機能は最小限の利用に留めつつ、他のフレームワークへの乗り
換えも検討している