Webサイト高速化の基本と Next.jsでの ヘッドレスCMS実装パターン

2023.04.23 株式会社オークンさんでの合同勉強会にて発表した資料です。

リンク（一部）
- https://bento.me/ryo-sogawa
- https://o-kun.com/
- https://onesword.jp/
- https://web.dev/vitals/
- https://ics.media/entry/200317/
- https://speakerdeck.com/ryosogawa/hetutoresucmstoha-she-nei-mian-qiang-hui-zi-liao
- https://nextjs-blog-patterns-src-project.vercel.app/
- https://github.com/RyoSogawa/nextjs-blog-patterns

Transcript

1. Webサイト高速化の基本と Next.jsでの ヘッドレスCMS実装パターン 2023.04.23 Ryo Sogawa @株式会社オークン
2. 自己紹介 • 十川 涼（RyoSogawa） ◦ フロントエンドエンジニア ◦ アーキテクト / UIデザイナー • any株式会社 / ONE SWORD株式会社 • 好きな技術 ◦ React ◦ GraphQL ◦ Qwik • 趣味 ◦ ロックンロールミュージック ◦ ストリートファイター ◦ ダーツ https://bento.me/ryo-sogawa
3. まず初めに
4. HPリニューアルおめでとうございます！🎉 https://o-kun.com/
5. 以前作成したヘッドレスCMS採用サイト https://onesword.jp/ 関連記事 • 当サイト開発におけるライブラリ・フレームワーク等の選定について(Next.js / TailwindCSS / WPGraphQL…) • 「ヘッドレスCMS」社内勉強会 1/2 〜新世代のWebサイト構成とは？ ご相談いただいたきっかけ
6. なぜ高速化する？
7. • ユーザーがページ表示に待てるのは2秒まで • 3秒以上かかると40%以上のユーザーは離脱する • 表示が1秒遅れるごとにコンバージョン率は7%落ちる • 表示が1秒遅れるごとに顧客満足度は16%落ちる • 速いサイトはインフラと公開にかかるコストを50%以上削減する • Amazonの調査では0.1秒反応が遅くなると売上が1%減る UX向上、コンバージョン 引用元: https://www.suzukikenichi.com/blog/website-performance-optimization/
8. Core Web Vitals • 得点が高いほどUXの高いサイトとして、検索ランキングで優遇される • ページの表示速度とCLSはSEOに求められる要素となった 画像引用元 :https://web.dev/vitals/ 8
9. “推測するな、計測せよ” • Chrome DevTools • PageSpeed Insights
10. 高速化の基本
11. 1. サイズを小さくする 2. 注文前に製造しておく 3. 近くから配達する ※それぞれのジャンルをざっくり紹介します 配送サービスに例えると
12. ① ~サイズを小さくする~
13. Webサイトの2大重量級選手 • 画像や動画などのコンテンツ • 日本語フォント ※モバイルデバイスに対してはJSのサイズを抑えるのも重要(後述)
14. 画像最適化 1. 軽量化 2. 読み込みタイミングの調整 3. その他
15. 1. リサイズ 2. 圧縮 3. 次世代フォーマット（WebP、AVIF） ※AVIFはまだ非対応ブラウザがあるので picture>sourceタグで 画像最適化① 軽量化
16. 1. loading="lazy" a. 画像がスクリーンに入るまで読み込まない 2. decoding="async" a. メインスレッドをブロックせずに読み込む 3. fetchpriority="high" a. 読み込み優先度を上げる（主に FVの画像用） 画像最適化② 読み込みタイミングの制御
17. 1. レスポンシブによる画像の切り替え a. 複数読み込んで1つしか使わなければ無駄になる b. loading="lazy" と display: none; を併用するのが簡単でオススメ 2. CSSのbackground-imageは使わない a. 諸々の制御ができない 3. width / height 属性の指定(CLS対策) 4. プレースホルダーの表示(遅延読み込みのUX向上) 画像最適化③ その他
18. 日本語フォントは重い Noto Sans JP 1ウェイトあたり … 1.6MBもある 高速化を最優先する場合Webフォントを諦めるのも手 (参考) フォント最適化
19. Webサイト＝文字なのでだいたい諦められない • サブセット / ダイナミックサブセット • CDN • next/font • FontPlus といった対策もあるが万全なものはまだなさそう フォント最適化
20. ② ~注文前に製造しておく~
21. ヘッドレスCMSとは 「ヘッドレスCMSとは」社内勉強会資料 - Speaker Deck WordPress ヘッドレスCMS 21 CMSがサイトと切り離されAPIとしてデータのみを提供している構成 ※この資料ではブログ等のコンテンツをCMS管理しているサイトと捉えます
22. Next.jsでの実装パターン 1. Client Side Rendering (CSR) 2. Server Side Rendering (SSR) 3. Static Site Generator (SSG) a. fallback b. Incremental Static Re-Generation (ISR) 4. React Server Components (RSC) 5. Static Exports with app router ←New!
23. デモ https://nextjs-blog-patterns-src-project.vercel.app/ ソースコード https://github.com/RyoSogawa/nextjs-blog-patterns
24. クライアント側でデータフェッチする 1. Client Side Rendering (CSR) • 👍データがリアルタイム • 👎遅い ◦ マウントされてからAPI実行 ◦ バンドルサイズ • 👎OGP系の情報が取得できない ことがある • 👎APIアクセス過多
25. 2. Server Side Rendering (SSR) サーバーでデータをフェッチしてクライアン トには生成済みのコンテンツを送る • 👍データがリアルタイム • 👍OGP • 👎遅い ◦ リクエストを受けてから APIアクセス ◦ レンダリングまで完全にストップする • 👎APIアクセス過多
26. 3. Static Site Generator (SSG) ビルドタイムでデータを取得し、予めコンテ ンツを生成しておく • 👍早い ◦ 静的ファイル ◦ アクセス前にページが生成されている • 👍APIアクセスがビルド時のみ • 👎データがリアルタイムでない • 👎コンテンツ更新に時間がかかる →欠点を補う技術がある
27. fallback 存在しないIDの記事ページにアクセスすると404になるが、その際にSSRでデータフェッ チしてくれる機能 ① ② ③ ④
28. Incremental Static Re-Generation (ISR) SSGで生成された静的な内容からの差分を自動で再生成してくれる 画像引用元：Qiita
29. この2つの技術を組み合わせることで 👎データがリアルタイムでない →ほぼリアルタイムになる！ 🥳 👎コンテンツ更新に時間がかかる →アクセスするだけ！1~2秒くらいでできる 🤩
30. SSG最強では...？ 🤔 …まだ改善点がある PageSpeed InsightsでDesktopでは100点を出すことも可能だが、Mobileだと点数がな かなか伸びない なぜなら... JSが大きいから！
31. SSGは完全なHTMLが生成されるわけではない • あくまでもReactがベースとなったHTMLなので画面読み込み後にReactが動いて いる • Reactのライブラリ等、色々なJSがバンドルされる←これが重い 画面上にhello worldを表示するだけのページでも結構な量の JSが読み込まれてしまう。。
32. サーバーサイドでデータを取得してレン ダーまで行った状態のコンポーネントを生 成する 4. React Server Components (RSC) • 👍 早い ◦ バンドルサイズが小さくなる ◦ 部分的に採用できる ◦ fetchしたデータをキャッシュしたり revalidateしたりもできる • 👎 設計/実装が難しそう
33. 5. Static Exports with app router • 👍 早い ◦ 不要なJSがある程度取り除かれる • 👍 インフラの制約がほぼない • 👎 Next.jsの一部機能が使えない • 👎 設計/実装が難しそう • 👎 記事の更新に時間がかかりそう RSCを使いビルドタイムに静的なファイル を生成する https://nextjs.org/docs/app/building-your-application/deploying/static-exports
34. ③ ~近くから配達する~
35. • 世界のさまざまな場所にあるエッジサーバー上にデータを配置し、クライアントに近 い場所からデータを返すことができる • アクセス負荷にも強い CDN/エッジサーバーを使おう
36. さらなる高速化のために
37. Astro https://astro.build/ • ZeroJS • パーシャルハイドレーション • React/Vue/Svelte等の多くのライブラリと組み合わせられる コンテンツベースのWebサイトに強い
38. Qwik (推し) https://qwik.builder.io/ • ZeroJS • レジューマブル • Reactに近いAPI デフォルトはSSRだがSSGさせることもできる コンテンツベースのWebサイトもWebアプリもいける
39. Q&A
40. • 全記事データを持った状態でクライアント側で絞り込みをするのはちょっと無駄があ り勿体無い • 記事数が少なければどうやってもあまり変わらないが、あえて推すならURLで切り 替える方法 ◦ カテゴリ絞り込み … `/blog/category/XXXX` ◦ ページネーション … `/blog/category/XXXX/2` etc... • この方法にすると、各ページには表示する記事データのみがある ◦ →クライアント側で絞り込みが不要 →クライアントのコード削減 →高速化につながるはず Q. SSGの場合のブログのカテゴリーによる絞り込みや、ペー ジネーションの作り方について知りたい
41. ヘッドレス化する大きな目的の一つは高速化なのでそのための選択肢 • Tailwind CSS / UnoCSS ◦ Atomic-CSSはアプリケーションが大型になればなるほど有利 • CSS Modules ◦ 無難 • Zero-runtime CSS in JS ◦ Linaria / Vanilla Extract / macaron ◦ 結構癖があるので好みに応じて ◦ near-zero-runtimeのStitchesも CSSライブラリ選定
42. 発表は以上です。 ありがとうございました！