2022年9月7日

1. 不動産ポータルサイトの
レスポンス速度UPに向けた取り組み
2022/09/07 LT会

2. ⾃⼰紹介
2
■ 職業
• Webエンジニア
• 最近はフロントエンド開発が多め（React / GraphQL と格闘中）
■ その他
• LT会はじめてなのでお⼿柔らかにお願いします。
■ 名前
• ⽯⼭ 雄⼤（いしやま たけひろ）

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

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

5. toC向けサービスでレスポンス速度が⼤事な理由は⼤きく２つ
5
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)

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

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

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

9. 今回実装した構成について
9
ブラウザ 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時間

10. SSRしてCDNキャッシュさせることに⾄った経緯
10
① 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

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

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

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

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

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

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

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

18. 18
Appendix.

19. Appendix1. SSRしてCDNキャッシュさせることに⾄った経緯（詳細版）
19
CSR (Client Side Rendering) SSR (Server Side Rendering) SSG (Static Site Generation) ISR (Incremental Static Regeneration)
概要
雛形HTMLだけをサーバー側で⽣
成して、動的な部分はクライアン
ト側でJSを実⾏してレンダリング
する⽅式
リクエストごとにサーバー側で
HTMLを動的に⽣成して返却する⽅
式
バッチ等で事前にサーバー側で
HTMLを動的に⽣成しておいて、⽣
成済みの静的ファイルをそのまま返
却する⽅式
指定した有効期限が経過したら、裏側で新しい
HTMLを動的に⽣成して次からそのHTMLを返
却する⽅式
メリット
・コンポーネント内で全てが完結
するので実装がシンプル
・SEOに強い
・リアルタイム性が⾼い
・SEOに強い
・パフォーマンスは抜群
・SEOにやや強い
・SSRに⽐べるとリアルタイム性が低い（有効
期限が切れた後の初回レスポンスは古いものな
ので）
デメリット ・SEOにとびっきり弱い
・リクエストごとに処理するコスト
がかかる
・レスポンス速度が遅くなる
・リアルタイム性が低い
・ページ数が多いとビルドに時間が
かかる
・実現するための環境構築に難あり（Vercelに
のっかるか、独⾃に仕組みを作る必要あり）
コメント
・SEOが必要なサービスではこの
選択肢は取れない（回避策である
Dynamic Rendering も Google
が明確に⾮推奨に）
・SSR単体だとパフォーマンスに問
題あるが、CDNと組み合わせればな
んとかなりそう
・数⼗万件の詳細ページをリリース
ごとや更新タイミングでビルドする
のは現実的でない
・SSGが適さないサイトはISRの恩恵も少ない。
積極的に採⽤する理由がない
Next.js で取りうるレンダリング⽅式は以下の4つ
→ 結論: SSR + CDNでキャッシュする形を選択