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

by gree_tech

Slide 1

Slide 1 text

Jamstack でリニューアルするグリーグループのメディア Glossom株式会社岡﨑俊樹

Slide 2

Slide 2 text

岡﨑俊樹 / Toshiki Okazaki 2019年にグリー株式会社に新卒入社。ブラウザゲームのバックエンドエンジニアを経て 2022年以降はメディア開発全般を担当している。ビールが大好き。 Glossom株式会社サービス統括本部エンジニア 2 @cakegaly

Slide 3

Slide 3 text

サービス紹介 3 GREEニュースグルメ映えグルメメディアゲームギフトナビゲームアプリ紹介メディア

Slide 4

Slide 4 text

グリーグループが展開する記事メディア 4 2007/12 2015/11 2016/6 2017/2 2017/3 芸能ニュース中心のキュレーションメディア派生メディア「GREEニュースプラス」住まい・暮らしメディア美容メディアファッションメディアおでかけ情報メディア「ゲームギフトナビ」おすすめ商品情報メディアおすすめグルメ情報メディア 2021/6 2024/7 2023/4 おすすめゲーム情報メディア派生メディア「GREEニュースグルメ」

Slide 5

Slide 5 text

グリーグループが展開する記事メディア 5 2007/12 2015/11 2016/6 2017/2 2017/3 芸能ニュース中心のキュレーションメディア住まい・暮らしメディア美容メディアファッションメディアおでかけ情報メディア「ゲームギフトナビ」おすすめゲーム情報メディア 2021/6 2024/7 2023/4 派生メディア「GREEニュースプラス」おすすめ商品情報メディアおすすめグルメ情報メディア派生メディア「GREEニュースグルメ」

Slide 6

Slide 6 text

グリーグループが展開する記事メディア 6 「ゲームギフトナビ」おすすめゲーム情報メディア 2021/6 2024/7 2023/4 派生メディア「GREEニュースプラス」おすすめ商品情報メディアおすすめグルメ情報メディア派生メディア「GREEニュースグルメ」 2021/6 「GREEニュースプラス」運用開始 ● SEO に知見があるメンバーが集まって立ち上げ ● wordpress.com サイトとして構築 ○ 自作のカスタムテーマで運用 2023/4 「ゲームギフトナビ」運用開始 ● 「GREEニュースプラス」をベースに、 wordpress.com サイトとして構築 ○ 自作のカスタムテーマで運用

Slide 7

Slide 7 text

グリーグループが展開する記事メディア 7 「ゲームギフトナビ」おすすめゲーム情報メディア 2021/6 2024/7 2023/4 派生メディア「GREEニュースプラス」おすすめ商品情報メディアおすすめグルメ情報メディア派生メディア「GREEニュースグルメ」 2023/12 リニューアル検討開始 ● メディア規模の拡大にともない、WordPress 以外の構成を検討 2024/7 「GREEニュースグルメ」運用開始 ● リニューアルで検討していた新たな構成で構築 2024/9 「ゲームギフトナビ」リニューアル ● wordpress.com サイト運用をやめて、新たな構成でリニューアルして運用開始

Slide 8

Slide 8 text

リニューアルを決めた経緯 8

Slide 9

Slide 9 text

● wordpress.com サイトとして運用していた ○ プラグイン利用なしで、自作のカスタムテーマのみでメディアとしての機能を実現 ○ 低コストで立ち上げられる反面、メディア規模の拡大にともない、課題が見えてきたリニューアル前の構成 9 ユーザレスポンス (HTML, CSS, JS) リクエスト (URL) コンテンツ編集者管理画面ページ生成コンテンツ (記事データ)

Slide 10

Slide 10 text

リニューアル前の課題 1. WordPress テーマの保守が大変すぎる 2. 機能開発の要望に応えづらい 3. ページ表示が遅く、見づらい 10

Slide 11

Slide 11 text

1. WordPress テーマの保守が大変すぎる ● WordPress の急な更新で、サイトの表示が崩れることがある ○ ボタンパーツ、カラムレイアウトなどが予期せず崩れる ○ プラグインを使わずにカスタムテーマで運用していても、 Gutenberg ブロックエディタとの互換性の問題により、完全に防ぐことは難しい 11 表示が崩れたボタン意図した表示のボタン

Slide 12

Slide 12 text

1. WordPress テーマの保守が大変すぎる ● ブロックエディタが使いづらい ○ 細かいデザイン調整が難しい ■ ブロック構造の制約が多い ■ テーマファイルだけでは制御に限界がある ○ ライターが効率的に記事を執筆できない ■ 特に、画像を多く挿入する記事では、編集画面のパフォーマンスが不安定になる ■ カスタム HTML の挿入 → 記事フォーマットの不一致 12 WordPress 時代に Gutenberg ブロックエディタで「ゲームギフトナビ」記事を編集している例

Slide 13

Slide 13 text

リニューアル前の課題 1. WordPress テーマの保守が大変すぎる 2. 機能開発の要望に応えづらい 3. ページ表示が遅く、見づらい 13

Slide 14

Slide 14 text

2. 機能開発の要望に応えづらいプラグインなし、カスタムテーマ運用の限界が見えてくる ● カスタム投稿タイプ、カスタムフィールドを柔軟に制御できない ● 特に、wp_posts, WP_Query の範囲を超えた検索はきつい 14 記事で紹介しているゲームアプリの情報を細かい条件で検索する機能つくってほしい！カスタムフィールドを管理画面で柔軟に操作… WP_Query を魔改造… ごめん、厳しいかも… 記事の編集担当エンジニア

Slide 15

Slide 15 text

リニューアル前の課題 1. WordPress テーマの保守が大変すぎる 2. 機能開発の要望に応えづらい 3. ページ表示が遅く、見づらい 15

Slide 16

Slide 16 text

3. ページ表示が遅く、見づらい ● フロントエンド起因の課題がたくさん ○ ユーザビリティ↓ アクセシビリティ↓ ○ レスポンシブ表示も考慮されていない ● サイトの表示が遅い ○ 不要な JS, CSS を大量に読み込んでいる ○ 画像/動画が表示最適化されていない 16 WordPress 時代の「ゲームギフトナビ」記事ページで Lighthouse スコアを測定したときの結果

Slide 17

Slide 17 text

リニューアルに向けた技術選定 17

Slide 18

Slide 18 text

技術選定の方針整理 18 ● 社内で開発実績がある構成を検討する？ ○ 特に Laravel, Rails は、社内での知見が多い ○ CDN で他プロダクトへの相乗りもできる ● 新しい技術の導入を検討する？ ○ Jamstack ならすべての課題を解決できそう ○ 社内での前例がないため、導入にあたって調査することが多く出てくる管理画面の保守が負担になるため今回は課題の根本解決にはならない Laravel で作成した管理画面のデモ

Slide 19

Slide 19 text

Jamstack とは？ 19 J a m s t a c k ● プリレンダリングページの内容は (なるべく) 事前に生成 → 表示速度アップ ● デカップリングフロントエンドとバックエンドを分離 → 柔軟に、安定した運用が可能 JavaScript APIs (Pre-Rendered) Markup

Slide 20

Slide 20 text

プリレンダリング - ユーザからの見え方 20 ユーザレスポンス (HTML, CSS, JS) リクエスト (URL) CSS JS HTML CDN 事前に静的ページを生成して CDN にキャッシュしておくホスティングサービスと CDN Web サーバキャッシュされた静的ページ API サーバデータベースコンテンツ編集者事前に生成された HTML を受け取って表示するため初期表示がとても速い

Slide 21

Slide 21 text

プリレンダリング - ユーザからの見え方 21 ユーザレスポンス (HTML, CSS, JS) リクエスト (URL) CSS JS HTML CDN 事前に静的ページを生成して CDN にキャッシュしておくホスティングサービスと CDN Web サーバキャッシュされた静的ページ API サーバデータベースコンテンツ編集者ユーザの手元 (ブラウザ) では、必要最小限の JS を実行する例: カルーセルの自動再生

Slide 22

Slide 22 text

プリレンダリング - 静的ページの事前生成 22 ユーザレスポンス (HTML, CSS, JS) リクエスト (URL) CSS JS HTML CDN 事前に静的ページを生成して CDN にキャッシュしておくホスティングサービスと CDN Web サーバキャッシュされた静的ページ API サーバデータベースコンテンツ編集者データベースから取得したコンテンツ情報を HTML に埋め込む (ビルド) JSON

Slide 23

Slide 23 text

データベースと API サーバ → ヘッドレス CMS 23 ユーザレスポンス (HTML, CSS, JS) リクエスト (URL) CSS JS HTML CDN 事前に静的ページを生成して CDN にキャッシュしておくホスティングサービスと CDN Web サーバキャッシュされた静的ページ API サーバデータベースコンテンツ編集者ヘッドレス CMS

Slide 24

Slide 24 text

技術選定 - ヘッドレス CMS 24 microCMS を利用する！ ● シンプルでわかりやすい日本語 UI ○ サポートも日本語で、手厚く対応してもらえる ● 標準の管理機能が充実している ○ ロール管理、操作権限を柔軟に設定できる ○ エンジニアが事前に API スキーマを組んでおけば安全かつ柔軟なコンテンツ編集を実現できる microCMS で作成した「ゲームギフトナビ」の記事編集画面

Slide 25

Slide 25 text

技術選定 - ヘッドレス CMS 25 microCMS を利用する！ ● フロントエンドエンジニア向けの機能 ○ 管理画面のインフラ管理が不要になる ○ サクッと見れる API プレビュー機能 ○ imgix を標準でサポートしている ● みんなの作業領域を明確にできる ○ 安全かつ柔軟に、CMS 内でコンテンツを更新 ○ 非エンジニアに HTML, CSS, JS を意識させない microCMS の API プレビュー機能返却される json の中身を手軽にチェック可能

Slide 26

Slide 26 text

技術選定 - ヘッドレス CMS 26 「WordPress のヘッドレス CMS 化」ではダメなのか？ ● リニューアル時の工数だけ考えると、microCMS に移行するよりも簡単 ○ WP REST API や RSS Feed を使えば、簡単に実現できる ○ データの移行作業がないため、フロントエンドの切り出し方だけを考えれば設計できる ● 今回は、管理画面に関する課題の解決にはならない ○ ブロックエディタ、ロール制御などの課題が残る ○ 記事フォーマットの多様化を管理しきれない

Slide 27

Slide 27 text

(再掲) リニューアル前の課題 1. WordPress テーマの保守が大変すぎる 2. 機能開発の要望に応えづらい 3. ページ表示が遅く、見づらい 27 🙆 microCMS の採用で解決！ ● 管理画面のメンテ工数を削減 ● フロントエンドとバックエンドをきっちり分離

Slide 28

Slide 28 text

静的サイト生成 (SG, Static Site Generation) 28 ユーザレスポンス (HTML, CSS, JS) リクエスト (URL) CSS JS HTML CDN 事前に静的ページを生成して CDN にキャッシュしておくホスティングサービスと CDN Web サーバキャッシュされた静的ページコンテンツ編集者ヘッドレス CMS 静的サイトジェネレーター (メタフレームワーク)

Slide 29

Slide 29 text

技術選定 - メタフレームワーク 29 Next.js を利用する！ ● 圧倒的 No.1 のシェア数 ○ コミュニティも活発 ● App Router の採用事例が増えていた ○ 検討はじめたとき、ちょうど stable になった ○ layout コンポーネント、fetch API など、 SEO 観点で活用できそうな新機能もたくさん → 知見をためるため、積極的に使っていくメタフレームワーク(※) の人気度調査 ※ 2022 までは「レンダリングフレームワーク」 State of JS 2023 より引用

Slide 30

Slide 30 text

技術選定 - ホスティングと CDN 30 Vercel を利用する！ ● 利用することがそのまま Next.js のベストプラクティスになる ○ 開発元が同じで、Next.js のために極限まで最適化されている ○ デプロイ、CDN とキャッシュ管理などもやってくれる ○ ISR でのレンダリングを実現してくれる ● AWS, GCP などで、自前でホスティングするよりも割高になる ○ Pro プランで $20〜 (従量課金制) ○ 2024/10 現在では、キャッシュ制御の対応が拡大しているため、 Vercel 以外の選択肢もある

Slide 31

Slide 31 text

静的サイト生成 (SG, Static Site Generation) 31 ユーザレスポンス (HTML, CSS, JS) リクエスト (URL) CSS JS HTML コンテンツ編集者 Vercel Edge Network CDN ヘッドレス CMS 事前に静的ページを生成して CDN にキャッシュしておくコンテンツに更新があるとすべてのページを再生成 → ビルド時間が長くなる Web サーバ

Slide 32

Slide 32 text

インクリメンタル静的サイト再生成 (ISR, Incremental Static Regeneration) 32 ユーザレスポンス (HTML, CSS, JS) リクエスト (URL) CSS JS HTML コンテンツ編集者 Vercel Edge Network CDN ヘッドレス CMS 事前に静的ページを生成して有効期限つきのキャッシュを CDN に配置生成されたキャッシュを一定時間ごとに再検証するページごとに一定時間でキャッシュの内容を再検証 → ビルド時間を短縮 Web サーバ

Slide 33

Slide 33 text

(再掲) リニューアル前の課題 1. WordPress テーマの保守が大変すぎる 2. 機能開発の要望に応えづらい 3. ページ表示が遅く、見づらい 33 🙆 Next.js, Vercel 採用で解決！ ● React ベースできっちりとフロントエンドを開発 ● ISR による記事の爆速表示

Slide 34

Slide 34 text

CMS データ移行 34

Slide 35

Slide 35 text

WordPress からデータをエクスポート ● WordPress 標準のエクスポート機能を使う ○ 投稿データは、WordPress 独自フォーマット XML である WXR で出力される 35

Slide 36

Slide 36 text

WXR のパースと整形 - サムネイル画像の対応づけ ● WXR では、記事とサムネイル画像が別の item として出力される ○ post_type が post であれば、記事データの出力 ○ post_type が attachment であれば、メディアファイル情報の出力 → パースするときに post に対応する attachment を対応づける 36

Slide 37

Slide 37 text

WXR のパースと整形 - カスタム HTML による課題と影響 ● カスタム HTML による課題と影響 ○ 一部の記事で、HTML が直接入稿されていた ○ css ではなく、style をベタ書き → エンジニアが把握していないスタイルは、　移行後にそのまま再現できない ○ 閉じタグの入れ忘れ → ブラウザと WordPress が補完してくれるため　運用中には気付けなかった 37 WordPress 時代の「ゲームギフトナビ」記事編集画面カスタム HTML でのテーブル挿入において、 style 属性がベタ書きされており、閉じタグの挿入がひとつ漏れている

Slide 38

Slide 38 text

WordPress → microCMS データ移行 ● 記事本文と画像データの移行は、手動でチェックして対応 ○ カスタム HTML 起因の例外パターンの洗い出しには時間がかかる ○ 300 記事 (1000 アイテム) 程度であれば、手動でもいけると判断 → エンジニア 5人日程度の作業で解決 38

Slide 39

Slide 39 text

工夫した点、苦労した点 39

Slide 40

Slide 40 text

表示高速化のために工夫したことページ表示速度の主なボトルネック ● 画像ファイル ○ 多くの画像を扱う記事メディアでは、画像の読み込み速度が課題となる ● フォントファイル ○ 文字数が多い日本語フォントの読み込みは、特に重くなりやすい 40 WordPress 時代の「ゲームギフトナビ」記事で 1記事あたりの転送量を確認した例画像だけで 48.6MB の読み込みが発生している

Slide 41

Slide 41 text

表示高速化 - 画像を最適化する ● next/image 画像最適化を活用する ○ Accept ヘッダを見て、フォーマットを最適化 ■ ブラウザが対応していれば webp で表示 ○ デフォルトで lazy load される ○ 画像の数が多いと、Vercel 従量課金の対象に ■ Pro プランでは、5,000 枚(/月) 以上で課金 ■ 画像多めのメディアでは、1週間もたない → Custom Loader で対策可能 41 「GREEニュースグルメ」に30記事入稿して社内で表示をテストしたときの記録

Slide 42

Slide 42 text

表示高速化 - 画像を最適化する ● next/image 画像最適化をもっと活用する ○ microCMS の画像 API と組み合わせる ■ microCMS にホスティングした画像は、imgix で操作できる ■ コンポーネントのカスタムローダーとして設定しておけば、 Vercel のリソース (従量課金の対象) を節約できる 42 Image コンポーネントの loader に customImageLoader を設定する例

Slide 43

Slide 43 text

表示高速化 - 画像を最適化する ● next/image 画像最適化をもっと活用する ○ priority の props を使い分ける ■ 記事のサムネイル、カルーセルの1枚目 → priority true にする ■ 記事の本文終わり、カルーセルの2枚目 → priority false (デフォルト) 43

Slide 44

Slide 44 text

表示高速化 - フォント読み込み ● next/font でフォントを最適化する ○ ビルド時にフォントファイルを静的ファイルとしてダウンロードしてくれる ○ 必要なウェイトのみを読み込む ○ ページを表示するとき、フォントの配布先にアクセスしなくてもよい 44 「GREEニュースグルメ」記事ページでフォントファイルの転送量を確認したときの例ビルド時に Google フォントを読み込んでいるため高速にフォントを読み込める

Slide 45

Slide 45 text

表示高速化 - 結果 (Lighthouse) ● WordPress 時代に測定したものよりも、大幅に改善 45

Slide 46

Slide 46 text

その他、保守性を高めるために採用した技術と取り組み 46 1人でも、コーディングに集中しながらでも無理なくできることを中心に ● Tailwind CSS ○ 使われない CSS が残りにくい ○ フレームワークに依存しない ● shadcn/ui ○ ライブラリ非依存のヘッドレス UI ○ 後方互換性、メンテナンスコストも安心 ● ESLint + Prettier (-> Biome) ○ TypeScript 採用のメリットを最大限まで高める ● Storybook + Vitest (試験的に導入中) ○ メディア間で共通する UI 管理のため ● Bundle Analyzer (試験的に導入中) ○ コンポーネント境界をより明確にする ● GitHub Actions 経由でのデプロイ ○ Vercel のリポジトリ連携を使いたいけど節約のため、自作して対応

Slide 47

Slide 47 text

まとめ 47

Slide 48

Slide 48 text

まとめと感想 48 ● まとめ ○ Next.js を採用した Jamstack 構成での運用は、多くの記事メディアと相性がいい ○ HTML, CSS, JS を意識せずに入稿できるように CMS を整備することが大切 ● 今後の展望 ○ より効率的な WordPress → microCMS データ移行手順を検討したい ○ a11y, o11y など、ソフトウェアとしての品質をより高く保つ基盤を整備したい ○ フロントエンドを取り巻く状況の変化は速く、常にベストプラクティスを探していきたい ■ PPR やキャッシュ戦略など、サービスにマッチしそうなものは積極的に検討する