SSG による Core Web Vitals の向上 – あるいは Jamstack の利点

最近 Core Web Vitals に関するご相談をいただくことが増えてきました。インターネットで調べると、SEO視点での解説記事は多いものの、開発や実装目線での記事はまだまだ少ない印象なので、開発・実装目線でまとめてみようと思います。

開発・実装目線での Core Web Vitals

この記事は「Core Web Vitalsのスコアがよくなくて焦っている」「SSGとかJamstackとかよく聞くけど何が良いの？」といった悩み・疑問を抱えている非技術者向けに実装者の目線で書いています。

すでに「Jamstack 大好き！」「Core Web Vitals のスコアあげてやったぜ！」「他の人はどうしてるか知りたい」というような経験豊富な方には物足りない内容だと思います。

今後そのような方々向けに Next.js, Nuxt.js, Gatsyby などを絡めた Core Web Vitals の記事も増やしていきたいと思っているので少しお待ち下さい。 🙇‍♂️

なお、Core Web Vitals （コアウェブバイタル）の概要については先日森田が記事にまとめているのでぜひご覧ください。

より詳細な解説については下記の記事などがおすすめです。

• Google Developers Japan: Web Vitals の概要: サイトの健全性を示す重要指標
• 【重要】コアウェブバイタルとは? LCP/FID/CLSをわかりやすく解説【SEO情報まとめ】

Jamstack の解説についてはこちらがおすすめです。

• Jamstackとは何を指すのか今一度考えてみる

免責

この記事の筆者は SEO の専門家ではなく、Core Web Vitals の向上を含めたページ速度の改善や閲覧・操作体験の向上などが Google などの検索結果にどう影響するかの専門的な知識はありません。

あくまでも「より良いウェブサイトを作るための知識」として捉えていただきたいです。

SSG を検討する前に

この記事では SSG （Static Site Generator）や Jamstack の Pre-render の概念が Core Web Vitals にどう効くのかを簡単に解説していきます。

ただし、SSG を導入するには現在のサイトの設計から大きく仕様を変更する必要があります。（有りていに言えばシステムのリプレースが前提になる可能性が高いです。）

そのため技術トピックは関係なく Core Web Vitals を改善したいのであればコストが少なく実施できる一般的な施策から検討することをおすすめします。

• 画像ファイルの最適化（フォーマットの変更や軽量化）
• img 要素などに画像の幅高さ（もしくはスペクト比）を指定する
• css, js の分割や軽量化
• 使用しているシステムのパフォーマンスチューニング
• サーバーまでの経路の最適化
• CDNの導入
• etc…

物によってはシステムリプレースなみにコストが嵩んだりそもそも実施不可能なものもあるかと思いますが、地道なチューニングでも Core Web Vitals が向上することはあります。

それでもダメなら SSG （も有りかもしれない）

やっと本題です。

現行システムのチューニングではもうどうにもならない、もしくはすでにシステムリプレースが決まっていてユーザーの使い勝手もさらに向上したいと考えている場合は SSG の導入も検討してみることをおすすめします。

SSG とは

SSG とは Static Site Generator の略で、動的サイトの用に静的サイトを生成する機構のことです。古くは MovableType などがこの機構を採用しており、長く Web 制作に携わった方には馴染みのあるものだったりするのではないでしょうか。

では、なぜいまさらSSG？ となると思います。SSGが脚光を浴びるようになったのは、冒頭でも少し触れた Jamstack という概念が広がってからでした。

フロントエンド技術の Jamstack は簡単に言うと下記のような構成になります。

1. 事前に全ページの主要な情報を HTML として出力する
2. ブラウザは静的なHTMLを表示したあとに JavaScript でAPIから追加の情報を取得する
3. 初回表示以降は SPA と同等の動きをする

この構成により、初回のページ表示の際に必要なデータの大半が事前にHTMLに出力されているため、データベースにアクセスする時間すらスキップしてページ表示ができるという離れ業が可能になります。

この事前にHTMLを出力する機構がまさに SSG であり、Jamstack では Pre-render / Pre-generate と呼ばれる概念です。

なんでSSG？

なんらかのCMSやシステム上にあるページで Core Web Vitals のスコアを改善しようとした経験のある方の中には、画像やCSSの問題だけでなく、そもそもページの初回表示に時間がかかりすぎて重要なスコア（とくにLCP）が向上せず諦めたという方もいるのではないでしょうか。

特に在庫情報を確認する必要があるECサイトや、ユーザー情報を参照する箇所が多いレビューサイトなどではその傾向が多いかと思います。
部分的なキャッシュ機構を導入したり、取得に時間がかかる情報を Ajax で後読みするなどの工夫をすると思いますが、それらも限界があります。

そんなとき、まっさきにユーザーが取得したい情報が更新頻度の低いデータ※1であれば SSG の導入が検討可能です。在庫に関わる情報やレビューなどを除いた商品固有の情報※2を事前にHTMLに出力することでいち早く画面を表示することができます。※3

※1. データの更新のたびにページの出力が必要で頻繁にデータが変わるようなものには不向きです。フレームワークによってはページ単位で更新する機構を持つものもありますが、それでもタイムラグは存在するので、リアルタイム性が重視されるデータについては十分に検証をする必要があるかと思います。

※2. ただし、レビュー情報を後読みするのは Google のインデックス上問題になる可能性があるかもしれないため、どんな情報を後読みにしてよいかなどは SEO の専門家に判断を仰ぐことをおすすめします。

※3. 足りない情報をSPAで追加読み込みする際、レイアウトが変化するとCLSに影響するので、事前に高さを確保しておくなどの対応が必要です。広告バナーがあとから出て誤タップしてしまいイライラする経験は、誰もがしていますよね。。

どんなフレームワークがよい？

2020年10月現在 Jamstack に対応しているフレームワークで Gaji-Labo がおすすめしているのは下記3つです。

• Next.js
• Nuxt.js
• Gatsby.js

Next.js と Nuxt.js は大規模開発にも耐えうる Jamstack や SPA に対応したフレームワークです。ここでは両者の具体的な比較には触れませんが、Next.js は React、Nuxt.js は Vue.js を採用しているので、開発チームのスキル構成で検討するのも良いかもしれません。

ただし、どちらも SSG の機構を簡単にオフにすることができます。すでに Next.js や Nuxt.js を採用していても SSG が有効になっているとは限らないので、必ず確認するようにしてください。

Gatsby.js はブログやコーポレートサイトなど込み入った機能が少ないメディア寄りのサイトでの採用に向いていると感じています。Gaji-Labo のコーポレートサイトも Gatsby.js を採用しています。

また、ちょっと変わった方向性だと WordPress を Jamstack 化して提供している Shifter という CMS サービスもおすすめです。

• Shifter

Jamstack 化や SaaS 化するためなのか、生の WordPress よりも多少制限されている部分もありますが、幅広く普及している WordPress で簡単に Jamstack できるのが利点です。

SSG・Jamstack やってみませんか

Core Web Vitals の”スコア”のためだけにシステムリプレースを行うことはおすすめしませんが、SSGや Jamstack の導入でページの表示が速くなれば、ユーザーの使い勝手はかなり向上するはずです。

「手ざわりのいいUI」にフロントエンド技術からアプローチするために、有効な手段なのではないでしょうか。

そろそろ次期システムのリプレース考えなくては… というときの参考になれば幸いです。

サイトの重要指標であるCore Web Vitals についてまとめた記事をシリーズとして集めてみました。Core Web Vitals の内容をもっと知りたい方、実践での考え方を模索している方、ウェブの優れたUX（ユーザーエクスペリエンス）を実現するための指標に興味のある方などにおすすめの内容です。