レスポンス速度UPに向けた取り組み

レスポンス速度UPに向けた取り組みについて

Transcript

1. レスポンス速度UPに向けた取り組み 2022/09/07 LT会
2. 本⽇お話する内容 2 1. なぜ、toC向けサービスではレスポンス速度が⼤事か︖ 2. レスポンス速度UPに向けた取り組みの例 • 不動産ポータルサイトの詳細ページをNext.jsでSSRしてCDNでキャッシュしてみた話
3. 3 1. なぜ、toC向けサービスではレスポンス速度が⼤事か︖
4. toC向けサービスでレスポンス速度が⼤事な理由は⼤きく２つ 4 1. ユーザー体験が向上する → 離脱率 / CVR などのKPIに寄与 （ベタな例ですいません、、、） 2. SEO対策につながる → 流⼊数 のKPIに寄与 • Core Web Vitals という指標が鍵 • 最近 Google Search Console のレポート機能を強化 するぐらいGoogle先⽣の⼤切にしていくぞ感がすごい ※2 → 具体的な改善事例は、なかなか世に出てこない、、 • @Google: +500ms → -20% traffic • @Amazon: +100ms → -1% sales ※1 ※1 初出は当時Amazonに所属していた Greg Linden⽒が2008年のプレゼンで⽰した数値とのこと （Web担の記事 https://webtan.impress.co.jp/e/2022/02/04/42291より） ※2 2022年8⽉22⽇ Google Search Central のTweetより (https://twitter.com/googlesearchc/status/1561727623734169600?cxt=HHwWgMC4ifu_r6wrAAAA)
5. 5 2. レスポンス速度UPに向けた取り組みの例 → 不動産ポータルサイトの詳細ページをNext.jsでSSRしてCDNでキャッシュしてみた話
6. 取り組みの背景 6 ポータル 反響 物件掲載 ユーザー 不動産会社 とある不動産ポータルサイトの フルリニューアル を実施中 不動産ポータルサイトとは︖ 不動産ポータルサイトの特徴 買いたい 借りたい 売りたい 貸したい 特徴1. 取り扱う商材（物件）の数がとにかく⼤量 特徴3. 取り扱う商材（物件）の情報を1⽇に数回更新 ・複数の連動先からバッチ処理で連携される ・連携元ごとに interface が異なる 特徴2. 取り扱う商材（物件）の情報量が多い ・詳細ページに表⽰する項⽬数がめちゃめちゃ多い ・表⽰内容に関するルールもたくさん ・詳細ページの数は数⼗万件〜数百万件とかのオーダーに → 詳細ページを移⾏するときにレスポンス速度の観点で⼀番肝となった レンダリング⽅式 + キャッシュ⽅式 についてお話します
7. レンダリングやキャッシュの⽅式が寄与する対象範囲 7 ① HTTPリクエスト ② サーバー側の動的処理 ③ HTTPレスポンス ④ ブラウザレンダリング DNS + TCP Response ここが対象︕ DBアクセス 処理 APIアクセス 処理 処理 Loading Rendering FCP LCP TTFB Request
8. 今回実装した構成について 8 ブラウザ CDN APIサーバー 結論: Next.js で SSR して CDN でキャッシュする構成に ① HTTPリクエスト ② キャッシュが なければフェッチ ③ GraphQLクエリを 叩いてデータ取得 ④ SSR (Sever Side Rendering) ⑦ HTTPレスポンス ⑤ SSRした結果 （HTML / JS / CSS）を返却 ⑥ エッジサーバー にキャッシュ ① HTTPリクエスト ② キャッシュを そのまま返却 CDNのエッジサーバーに キャッシュがない場合 CDNのエッジサーバーに キャッシュがある場合 Webサーバー リリース時に キャッシュパージ CI/CD環境等 レスポンスヘッダーに s-maxage を付与 ※ + ※ s-maxage とは、CDN層にだけ キャッシュ時間を伝えるヘッダー → 1⽇数回ある物件の次回更新開始⽇時を付与 1回⽬ 2回⽬ リクエスト s-maxage: 8時間
9. SSRしてCDNキャッシュさせることに⾄った経緯 9 ① CSR (Client Side Rendering) → ❌: Googleさんが正しく評価してくれないのでSEO観点でNG （回避策である Dynamic Rendering も Google が明確に⾮推奨に ※1） ② SSG (Static Site Generation) → ❌: 数⼗万件の詳細ページをリリースごとや更新タイミングでビルドするのは現実的でない ③ SSR (Server Side Rendering) → ⭕: SSR単体だとパフォーマンスに問題あるが、CDNと組み合わせればなんとかなりそう ※1 https://developers.google.com/search/docs/advanced/javascript/dynamic-rendering?hl=ja Google検索セントラルのページより ※1
10. やってみて良かったこと 10 SSRでも⼗分なパフォーマンス︕実⽤上まったく問題がないレベル 1. キャッシュヒットすれば 数10ms オーダーで返却されて爆速︕ ※キャッシュがヒットしなくても物件の詳細ページであれば 99%tileが400ms台なのでヒットしなくても遅いわけではない (平均200ms〜) 2. Google Search Console / CWV Assesment においても問題がない状態を維持︕
11. やってみて悪かったこと（⽣じた課題） 11 パフォーマンスにおいては問題がないが、キャッシュについて下記の2つの課題が⽣じた ① どのキャッシュが問題になっているか特定が困難 ② リリース時などのキャッシュ削除に⼿間がかかる
12. ① どのキャッシュが問題になっているか特定が困難 12 ブラウザ CDN GraphQL Redis DB Next.js キャッシュヒット キャッシュヒット →キャッシュが１段増えるだけで問題が⽣じたときの切り分けが 思ったよりも難しくなった ▼CDNからキャッシュをパージしても、何故か解決しない︕的な問題が発⽣ 原因は下層のキャッシュ層だった。 これらが上位のキャッシュと複合してどこに問題があるか特定が難しくなった
13. ② リリース時などのキャッシュ削除に⼿間がかかる 13 ・キャッシュの削除はキャッシュと同じ単位でできるとは限らない ※URL構成やCDNに⼤きく依存する ・キャッシュの削除のタイミングには依存関係が存在するため、 ⼯夫しないとキャッシュを消せない キャッシュの単位 CDNで削除するクエリ例 ⼿間 /properties/${物件ID}/ /properties/* なし /${都道府県}/${住所ID}/hoge/ /${都道府県}/${住所ID}/fuga/ /${都道府県}/* △ （キャッシュした単位以上にしか 消せない） ブラウザ CDN GraphQL Redis DB Next.js
14. SSR でも CDNでキャッシュ すると⼗分なパフォーマンスを発揮︕ まとめ 14 ただし、キャッシュは劇薬なのでご注意を
15. ⼀緒にWebサービスつくる仲間を探しています︕ 15 Next.js や GraphQL での開発にご興味のある⽅、ぜひ︕︕︕
16. END OF PRESENTATION ご清聴ありがとうございました