Jamstack でリニューアルするグリーグループのメディア

GREE Tech Conference 2024で発表された資料です。
https://techcon.gree.jp/2024/session/TrackA-3

Transcript

1. Jamstack でリニューアルする グリーグループのメディア Glossom株式会社 岡﨑 俊樹
2. 岡﨑 俊樹 / Toshiki Okazaki 2019年にグリー株式会社に新卒入社。 ブラウザゲームのバックエンドエンジニアを経て 2022年以降はメディア開発全般を担当している。 ビールが大好き。 Glossom株式会社 サービス統括本部 エンジニア 2 @cakegaly
3. サービス紹介 3 GREEニュースグルメ 映えグルメメディア ゲームギフトナビ ゲームアプリ紹介メディア
4. グリーグループが展開する記事メディア 4 2007/12 2015/11 2016/6 2017/2 2017/3 芸能ニュース中心の キュレーションメディア 派生メディア 「GREEニュースプラス」 住まい・暮らし メディア 美容メディア ファッション メディア おでかけ情報 メディア 「ゲームギフトナビ」 おすすめ商品情報 メディア おすすめグルメ情報 メディア 2021/6 2024/7 2023/4 おすすめゲーム情報 メディア 派生メディア 「GREEニュースグルメ」
5. グリーグループが展開する記事メディア 5 2007/12 2015/11 2016/6 2017/2 2017/3 芸能ニュース中心の キュレーションメディア 住まい・暮らし メディア 美容メディア ファッション メディア おでかけ情報 メディア 「ゲームギフトナビ」 おすすめゲーム情報 メディア 2021/6 2024/7 2023/4 派生メディア 「GREEニュースプラス」 おすすめ商品情報 メディア おすすめグルメ情報 メディア 派生メディア 「GREEニュースグルメ」
6. グリーグループが展開する記事メディア 6 「ゲームギフトナビ」 おすすめゲーム情報 メディア 2021/6 2024/7 2023/4 派生メディア 「GREEニュースプラス」 おすすめ商品情報 メディア おすすめグルメ情報 メディア 派生メディア 「GREEニュースグルメ」 2021/6 「GREEニュースプラス」運用開始 • SEO に知見があるメンバーが集まって立ち上げ • wordpress.com サイトとして構築 ◦ 自作のカスタムテーマで運用 2023/4 「ゲームギフトナビ」運用開始 • 「GREEニュースプラス」をベースに、 wordpress.com サイトとして構築 ◦ 自作のカスタムテーマで運用
7. グリーグループが展開する記事メディア 7 「ゲームギフトナビ」 おすすめゲーム情報 メディア 2021/6 2024/7 2023/4 派生メディア 「GREEニュースプラス」 おすすめ商品情報 メディア おすすめグルメ情報 メディア 派生メディア 「GREEニュースグルメ」 2023/12 リニューアル検討開始 • メディア規模の拡大にともない、WordPress 以外の構成を検討 2024/7 「GREEニュースグルメ」運用開始 • リニューアルで検討していた新たな構成で構築 2024/9 「ゲームギフトナビ」リニューアル • wordpress.com サイト運用をやめて、 新たな構成でリニューアルして運用開始
8. リニューアルを決めた経緯 8
9. • wordpress.com サイトとして運用していた ◦ プラグイン利用なしで、自作のカスタムテーマのみでメディアとしての機能を実現 ◦ 低コストで立ち上げられる反面、メディア規模の拡大にともない、課題が見えてきた リニューアル前の構成 9 ユーザ レスポンス (HTML, CSS, JS) リクエスト (URL) コンテンツ 編集者 管理画面 ページ生成 コンテンツ (記事データ)
10. リニューアル前の課題 1. WordPress テーマの保守が大変すぎる 2. 機能開発の要望に応えづらい 3. ページ表示が遅く、見づらい 10
11. 1. WordPress テーマの保守が大変すぎる • WordPress の急な更新で、サイトの表示が崩れることがある ◦ ボタンパーツ、カラムレイアウトなどが予期せず崩れる ◦ プラグインを使わずにカスタムテーマで運用していても、 Gutenberg ブロックエディタとの互換性の問題により、 完全に防ぐことは難しい 11 表示が崩れたボタン 意図した表示のボタン
12. 1. WordPress テーマの保守が大変すぎる • ブロックエディタが使いづらい ◦ 細かいデザイン調整が難しい ▪ ブロック構造の制約が多い ▪ テーマファイルだけでは制御に限界がある ◦ ライターが効率的に記事を執筆できない ▪ 特に、画像を多く挿入する記事では、 編集画面のパフォーマンスが不安定になる ▪ カスタム HTML の挿入 → 記事フォーマットの不一致 12 WordPress 時代に Gutenberg ブロックエディタで 「ゲームギフトナビ」記事を編集している例
13. リニューアル前の課題 1. WordPress テーマの保守が大変すぎる 2. 機能開発の要望に応えづらい 3. ページ表示が遅く、見づらい 13
14. 2. 機能開発の要望に応えづらい プラグインなし、カスタムテーマ運用の限界が見えてくる • カスタム投稿タイプ、カスタムフィールドを柔軟に制御できない • 特に、wp_posts, WP_Query の範囲を超えた検索はきつい 14 記事で紹介している ゲームアプリの情報を 細かい条件で検索する機能 つくってほしい！ カスタムフィールドを 管理画面で柔軟に操作… WP_Query を魔改造… ごめん、厳しいかも… 記事の編集担当 エンジニア
15. リニューアル前の課題 1. WordPress テーマの保守が大変すぎる 2. 機能開発の要望に応えづらい 3. ページ表示が遅く、見づらい 15
16. 3. ページ表示が遅く、見づらい • フロントエンド起因の課題がたくさん ◦ ユーザビリティ↓ アクセシビリティ↓ ◦ レスポンシブ表示も考慮されていない • サイトの表示が遅い ◦ 不要な JS, CSS を大量に読み込んでいる ◦ 画像/動画が表示最適化されていない 16 WordPress 時代の「ゲームギフトナビ」記事ページで Lighthouse スコアを測定したときの結果
17. リニューアルに向けた技術選定 17
18. 技術選定の方針整理 18 • 社内で開発実績がある構成を検討する？ ◦ 特に Laravel, Rails は、社内での知見が多い ◦ CDN で 他プロダクトへの相乗り もできる • 新しい技術の導入を検討する？ ◦ Jamstack なら すべての課題を解決できそう ◦ 社内での前例がないため、 導入にあたって調査することが多く出てくる 管理画面の保守が負担になるため 今回は課題の根本解決にはならない Laravel で作成した管理画面のデモ
19. Jamstack とは？ 19 J a m s t a c k • プリレンダリング ページの内容は (なるべく) 事前に生成 → 表示速度アップ • デカップリング フロントエンドとバックエンドを分離 → 柔軟に、安定した運用が可能 JavaScript APIs (Pre-Rendered) Markup
20. プリレンダリング - ユーザからの見え方 20 ユーザ レスポンス (HTML, CSS, JS) リクエスト (URL) CSS JS HTML CDN 事前に静的ページを生成して CDN にキャッシュしておく ホスティングサービスと CDN Web サーバ キャッシュ された 静的ページ API サーバ データベース コンテンツ 編集者 事前に生成された HTML を 受け取って表示するため 初期表示がとても速い
21. プリレンダリング - ユーザからの見え方 21 ユーザ レスポンス (HTML, CSS, JS) リクエスト (URL) CSS JS HTML CDN 事前に静的ページを生成して CDN にキャッシュしておく ホスティングサービスと CDN Web サーバ キャッシュ された 静的ページ API サーバ データベース コンテンツ 編集者 ユーザの手元 (ブラウザ) では、 必要最小限の JS を実行する 例: カルーセルの自動再生
22. プリレンダリング - 静的ページの事前生成 22 ユーザ レスポンス (HTML, CSS, JS) リクエスト (URL) CSS JS HTML CDN 事前に静的ページを生成して CDN にキャッシュしておく ホスティングサービスと CDN Web サーバ キャッシュ された 静的ページ API サーバ データベース コンテンツ 編集者 データベースから取得した コンテンツ情報を HTML に埋め込む (ビルド) JSON
23. データベースと API サーバ → ヘッドレス CMS 23 ユーザ レスポンス (HTML, CSS, JS) リクエスト (URL) CSS JS HTML CDN 事前に静的ページを生成して CDN にキャッシュしておく ホスティングサービスと CDN Web サーバ キャッシュ された 静的ページ API サーバ データベース コンテンツ 編集者 ヘッドレス CMS
24. 技術選定 - ヘッドレス CMS 24 microCMS を利用する！ • シンプルでわかりやすい日本語 UI ◦ サポートも日本語で、手厚く対応してもらえる • 標準の管理機能が充実している ◦ ロール管理、操作権限を柔軟に設定できる ◦ エンジニアが事前に API スキーマを組んでおけば 安全かつ柔軟なコンテンツ編集を実現できる microCMS で作成した 「ゲームギフトナビ」の記事編集画面
25. 技術選定 - ヘッドレス CMS 25 microCMS を利用する！ • フロントエンドエンジニア向けの機能 ◦ 管理画面のインフラ管理が不要になる ◦ サクッと見れる API プレビュー機能 ◦ imgix を標準でサポートしている • みんなの作業領域を明確にできる ◦ 安全かつ柔軟に、CMS 内でコンテンツを更新 ◦ 非エンジニアに HTML, CSS, JS を意識させない microCMS の API プレビュー機能 返却される json の中身を手軽にチェック可能
26. 技術選定 - ヘッドレス CMS 26 「WordPress のヘッドレス CMS 化」ではダメなのか？ • リニューアル時の工数だけ考えると、microCMS に移行するよりも簡単 ◦ WP REST API や RSS Feed を使えば、簡単に実現できる ◦ データの移行作業がないため、フロントエンドの切り出し方だけを考えれば設計できる • 今回は、管理画面に関する課題の解決にはならない ◦ ブロックエディタ、ロール制御などの課題が残る ◦ 記事フォーマットの多様化を管理しきれない
27. (再掲) リニューアル前の課題 1. WordPress テーマの保守が大変すぎる 2. 機能開発の要望に応えづらい 3. ページ表示が遅く、見づらい 27 🙆 microCMS の採用で解決！ • 管理画面のメンテ工数を削減 • フロントエンドとバックエンドを きっちり分離
28. 静的サイト生成 (SG, Static Site Generation) 28 ユーザ レスポンス (HTML, CSS, JS) リクエスト (URL) CSS JS HTML CDN 事前に静的ページを生成して CDN にキャッシュしておく ホスティングサービスと CDN Web サーバ キャッシュ された 静的ページ コンテンツ 編集者 ヘッドレス CMS 静的サイトジェネレーター (メタフレームワーク)
29. 技術選定 - メタフレームワーク 29 Next.js を利用する！ • 圧倒的 No.1 のシェア数 ◦ コミュニティも活発 • App Router の採用事例が増えていた ◦ 検討はじめたとき、ちょうど stable になった ◦ layout コンポーネント、fetch API など、 SEO 観点で活用できそうな新機能もたくさん → 知見をためるため、積極的に使っていく メタフレームワーク(※) の人気度調査 ※ 2022 までは「レンダリングフレームワーク」 State of JS 2023 より引用
30. 技術選定 - ホスティングと CDN 30 Vercel を利用する！ • 利用することがそのまま Next.js のベストプラクティスになる ◦ 開発元が同じで、Next.js のために極限まで最適化されている ◦ デプロイ、CDN とキャッシュ管理などもやってくれる ◦ ISR でのレンダリングを実現してくれる • AWS, GCP などで、自前でホスティングするよりも割高になる ◦ Pro プランで $20〜 (従量課金制) ◦ 2024/10 現在では、キャッシュ制御の対応が拡大しているため、 Vercel 以外の選択肢もある
31. 静的サイト生成 (SG, Static Site Generation) 31 ユーザ レスポンス (HTML, CSS, JS) リクエスト (URL) CSS JS HTML コンテンツ 編集者 Vercel Edge Network CDN ヘッドレス CMS 事前に静的ページを生成して CDN にキャッシュしておく コンテンツに更新があると すべてのページを再生成 → ビルド時間が長くなる Web サーバ
32. インクリメンタル静的サイト再生成 (ISR, Incremental Static Regeneration) 32 ユーザ レスポンス (HTML, CSS, JS) リクエスト (URL) CSS JS HTML コンテンツ 編集者 Vercel Edge Network CDN ヘッドレス CMS 事前に静的ページを生成して 有効期限つきのキャッシュを CDN に配置 生成されたキャッシュを 一定時間ごとに再検証する ページごとに一定時間で キャッシュの内容を再検証 → ビルド時間を短縮 Web サーバ
33. (再掲) リニューアル前の課題 1. WordPress テーマの保守が大変すぎる 2. 機能開発の要望に応えづらい 3. ページ表示が遅く、見づらい 33 🙆 Next.js, Vercel 採用で解決！ • React ベースで きっちりとフロントエンドを開発 • ISR による記事の爆速表示
34. CMS データ移行 34
35. WordPress からデータをエクスポート • WordPress 標準のエクスポート機能を使う ◦ 投稿データは、WordPress 独自フォーマット XML である WXR で出力される 35
36. WXR のパースと整形 - サムネイル画像の対応づけ • WXR では、記事とサムネイル画像が別の item として出力される ◦ post_type が post であれば、記事データの出力 ◦ post_type が attachment であれば、メディアファイル情報の出力 → パースするときに post に対応する attachment を対応づける 36
37. WXR のパースと整形 - カスタム HTML による課題と影響 • カスタム HTML による課題と影響 ◦ 一部の記事で、HTML が直接入稿されていた ◦ css ではなく、style をベタ書き → エンジニアが把握していないスタイルは、 　 移行後にそのまま再現できない ◦ 閉じタグの入れ忘れ → ブラウザと WordPress が補完してくれるため 　 運用中には気付けなかった 37 WordPress 時代の「ゲームギフトナビ」記事編集画面 カスタム HTML でのテーブル挿入において、 style 属性がベタ書きされており、 閉じタグ </tr> の挿入がひとつ漏れている
38. WordPress → microCMS データ移行 • 記事本文と画像データの移行は、手動でチェックして対応 ◦ カスタム HTML 起因の例外パターンの洗い出しには時間がかかる ◦ 300 記事 (1000 アイテム) 程度であれば、手動でもいけると判断 → エンジニア 5人日程度の作業で解決 38
39. 工夫した点、苦労した点 39
40. 表示高速化のために工夫したこと ページ表示速度の主なボトルネック • 画像ファイル ◦ 多くの画像を扱う記事メディアでは、 画像の読み込み速度が課題となる • フォントファイル ◦ 文字数が多い日本語フォントの読み込みは、 特に重くなりやすい 40 WordPress 時代の「ゲームギフトナビ」記事で 1記事あたりの転送量を確認した例 画像だけで 48.6MB の読み込みが発生している
41. 表示高速化 - 画像を最適化する • next/image 画像最適化を活用する ◦ Accept ヘッダを見て、フォーマットを最適化 ▪ ブラウザが対応していれば webp で表示 ◦ デフォルトで lazy load される ◦ 画像の数が多いと、Vercel 従量課金の対象 に ▪ Pro プランでは、5,000 枚(/月) 以上で課金 ▪ 画像多めのメディアでは、1週間もたない → Custom Loader で対策可能 41 「GREEニュースグルメ」に30記事入稿して 社内で表示をテストしたときの記録
42. 表示高速化 - 画像を最適化する • next/image 画像最適化をもっと活用する ◦ microCMS の画像 API と組み合わせる ▪ microCMS にホスティングした画像は、imgix で操作できる ▪ <Image> コンポーネントのカスタムローダーとして設定しておけば、 Vercel のリソース (従量課金の対象) を節約できる 42 Image コンポーネントの loader に customImageLoader を設定する例
43. 表示高速化 - 画像を最適化する • next/image 画像最適化をもっと活用する ◦ priority の props を使い分ける ▪ 記事のサムネイル、カルーセルの1枚目 → priority true にする ▪ 記事の本文終わり、カルーセルの2枚目 → priority false (デフォルト) 43
44. 表示高速化 - フォント読み込み • next/font でフォントを最適化する ◦ ビルド時にフォントファイルを 静的ファイルとしてダウンロードしてくれる ◦ 必要なウェイトのみを読み込む ◦ ページを表示するとき、 フォントの配布先にアクセスしなくてもよい 44 「GREEニュースグルメ」記事ページで フォントファイルの転送量を確認したときの例 ビルド時に Google フォントを読み込んでいるため 高速にフォントを読み込める
45. 表示高速化 - 結果 (Lighthouse) • WordPress 時代に測定したものよりも、大幅に改善 45
46. その他、保守性を高めるために採用した技術と取り組み 46 1人でも、コーディングに集中しながらでも無理なくできることを中心に • Tailwind CSS ◦ 使われない CSS が残りにくい ◦ フレームワークに依存しない • shadcn/ui ◦ ライブラリ非依存の ヘッドレス UI ◦ 後方互換性、メンテナンスコストも安心 • ESLint + Prettier (-> Biome) ◦ TypeScript 採用のメリットを 最大限まで高める • Storybook + Vitest (試験的に導入中) ◦ メディア間で共通する UI 管理のため • Bundle Analyzer (試験的に導入中) ◦ コンポーネント境界をより明確にする • GitHub Actions 経由でのデプロイ ◦ Vercel のリポジトリ連携を使いたいけど 節約のため、自作して対応
47. まとめ 47
48. まとめと感想 48 • まとめ ◦ Next.js を採用した Jamstack 構成での運用は、多くの記事メディアと相性がいい ◦ HTML, CSS, JS を意識せずに入稿できるように CMS を整備することが大切 • 今後の展望 ◦ より効率的な WordPress → microCMS データ移行手順を検討したい ◦ a11y, o11y など、ソフトウェアとしての品質をより高く保つ基盤を整備したい ◦ フロントエンドを取り巻く状況の変化は速く、常にベストプラクティスを探していきたい ▪ PPR やキャッシュ戦略など、サービスにマッチしそうなものは積極的に検討する
49. ご清聴ありがとうございました 49