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

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

Transcript

1. レスポンス速度UPに向けた取り組み
   2022/09/07 LT会
   

   View Slide

2. 本⽇お話する内容
   2
   1. なぜ、toC向けサービスではレスポンス速度が⼤事か︖
   2. レスポンス速度UPに向けた取り組みの例
   • 不動産ポータルサイトの詳細ページをNext.jsでSSRしてCDNでキャッシュしてみた話
   

   View Slide

3. 3
   1. なぜ、toC向けサービスではレスポンス速度が⼤事か︖
   

   View Slide

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)
   

   View Slide

5. 5
   2. レスポンス速度UPに向けた取り組みの例
   → 不動産ポータルサイトの詳細ページをNext.jsでSSRしてCDNでキャッシュしてみた話
   

   View Slide

6. 取り組みの背景
   6
   ポータル
   反響 物件掲載
   ユーザー
   不動産会社
   とある不動産ポータルサイトの フルリニューアル を実施中
   不動産ポータルサイトとは︖ 不動産ポータルサイトの特徴
   買いたい
   借りたい
   売りたい
   貸したい
   特徴1. 取り扱う商材（物件）の数がとにかく⼤量
   特徴3. 取り扱う商材（物件）の情報を1⽇に数回更新
   ・複数の連動先からバッチ処理で連携される
   ・連携元ごとに interface が異なる
   特徴2. 取り扱う商材（物件）の情報量が多い
   ・詳細ページに表⽰する項⽬数がめちゃめちゃ多い
   ・表⽰内容に関するルールもたくさん
   ・詳細ページの数は数⼗万件〜数百万件とかのオーダーに
   → 詳細ページを移⾏するときにレスポンス速度の観点で⼀番肝となった
   レンダリング⽅式 + キャッシュ⽅式 についてお話します
   

   View Slide

7. レンダリングやキャッシュの⽅式が寄与する対象範囲
   7
   ① HTTPリクエスト ② サーバー側の動的処理 ③ HTTPレスポンス ④ ブラウザレンダリング
   DNS + TCP
   Response
   ここが対象︕
   DBアクセス
   処理
   APIアクセス
   処理
   処理
   Loading
   Rendering
   FCP LCP
   TTFB
   Request
   

   View Slide

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時間
   

   View Slide

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
   

   View Slide

10. やってみて良かったこと
    10
    SSRでも⼗分なパフォーマンス︕実⽤上まったく問題がないレベル
    1. キャッシュヒットすれば 数10ms オーダーで返却されて爆速︕
    ※キャッシュがヒットしなくても物件の詳細ページであれば
    99%tileが400ms台なのでヒットしなくても遅いわけではない
    (平均200ms〜)
    2. Google Search Console / CWV Assesment においても問題がない状態を維持︕
    

    View Slide

11. やってみて悪かったこと（⽣じた課題）
    11
    パフォーマンスにおいては問題がないが、キャッシュについて下記の2つの課題が⽣じた
    ① どのキャッシュが問題になっているか特定が困難
    ② リリース時などのキャッシュ削除に⼿間がかかる
    

    View Slide

12. ① どのキャッシュが問題になっているか特定が困難
    12
    ブラウザ CDN GraphQL Redis DB
    Next.js
    キャッシュヒット
    キャッシュヒット
    →キャッシュが１段増えるだけで問題が⽣じたときの切り分けが
    思ったよりも難しくなった
    ▼CDNからキャッシュをパージしても、何故か解決しない︕的な問題が発⽣
    原因は下層のキャッシュ層だった。
    これらが上位のキャッシュと複合してどこに問題があるか特定が難しくなった
    

    View Slide

13. ② リリース時などのキャッシュ削除に⼿間がかかる
    13
    ・キャッシュの削除はキャッシュと同じ単位でできるとは限らない
    ※URL構成やCDNに⼤きく依存する
    ・キャッシュの削除のタイミングには依存関係が存在するため、
    ⼯夫しないとキャッシュを消せない
    キャッシュの単位 CDNで削除するクエリ例 ⼿間
    /properties/${物件ID}/ /properties/* なし
    /${都道府県}/${住所ID}/hoge/
    /${都道府県}/${住所ID}/fuga/
    /${都道府県}/*
    △
    （キャッシュした単位以上にしか
    消せない）
    ブラウザ CDN GraphQL Redis DB
    Next.js
    

    View Slide

14. SSR でも CDNでキャッシュ すると⼗分なパフォーマンスを発揮︕
    まとめ
    14
    ただし、キャッシュは劇薬なのでご注意を
    

    View Slide

15. ⼀緒にWebサービスつくる仲間を探しています︕
    15
    Next.js や GraphQL での開発にご興味のある⽅、ぜひ︕︕︕
    

    View Slide

16. END OF
    PRESENTATION
    ご清聴ありがとうございました
    

    View Slide