コアウェブバイタル（Core Web Vitals）について考える

当記事はコアウェブバイタル（Core Web Vitals）について考えていく記事になります。
弊社では、コアウェブバイタル（Core Web Vitals）が相当に重要なアルゴリズムであると考えています。
これを避けてコンテンツの良し悪しは語れない・・・とまで考えています。

コアウェブバイタルとは、以下の要素を判定して、WEBサイト・WEBコンテンツとしてのレベルを測る・・・というアルゴリズムなのかなと考えています。

• LCP（Largest Contentful Paint）
• INP（Interaction to Next Paint）/ FID（First Input Delay）
• CLS（Cumulative Layout Shift）

で、弊社では以下のように考えています。

というように解釈しています。
デザインやコーディングの良し悪しは、デザイナーの存在よりもGoogleの存在が決めていくものになっているのかもしれません。

各要素について考えてみる

まずは、改めて各要素を振り返ってみたいと思います。

LCP（Largest Contentful Paint）

ページの読み込み速度が「LCP（Largest Contentful Paint）で測定されます。
ページの主要なコンテンツがどれだけ速く表示されるかが重要です。
物凄く細かいニュアンスの違いになるんですが、LCPはページの主要なコンテンツが「いつ」表示されるかを測る指標です。

動画などの重いコンテンツが最後まで表示されないことや、JSの読み込みに時間がかかるなど、主要な部分のコンテンツが適正なスピードで表示されないといけないという指標となっています。
具体的には、ユーザーがページにアクセスしてから、視覚的に最も大きなコンテンツ（動画や画像やテキストなど）が完全に表示されるまでの時間を測定します。

例えば、ニュースサイトの記事ページを開いたとします。

ページのトップ画像が最も大きいコンテンツだとします。
ユーザーがページにアクセスしてから、このトップ画像が完全に表示されるまで3秒かかったとします。
この場合、LCPは3秒となります。
LCPは、ユーザーがページの主要なコンテンツをどれだけ早く見ることができるかを示す指標であり、ユーザー体験に大きく影響します。

LCPが短ければ、ユーザーはすぐにコンテンツを認識し、読み始めることができます。
逆に、LCPが長ければ、ユーザーはページが読み込まれるのを待たなければならず、ストレスを感じたりサイトを離脱してしまう可能性があります。

ですので、LCPを改善することは、ユーザーに快適な閲覧体験を提供し、サイトの離脱率を減らすために重要です。

INP（Interaction to Next Paint）/ FID（First Input Delay）

「INP（Interaction to Next Paint）/ FID（First Input Delay）」で測定されます。
ユーザーがページを操作した際に、ブラウザが 視覚的に どれだけ速く反応するかを測定する指標です。
ページの「応答性」を評価するための重要な指標です。

具体的な例として、ボタン（コンテンツの要素）をクリック（タップ）したのになかなか反応がない・・・といった経験があるんじゃないかなと思います。
このような時には「ページが固まった？」「クリックがちゃんと認識されている？」と不安に感じ、ストレスを感じてしまいます。

この指標を計測しているのがINPということです。
INPを改善することで、ユーザーの操作に対してスムーズに反応する、快適なWebサイトを提供することができると考えられています。

FIDは最初の入力のみを計測対象としていましたが、INPは、ページ上の全ての操作を計測対象とするためより包括的に応答性を評価できます。
Googleは、INPの理想的な値を200ミリ秒以下としています。

CLS（Cumulative Layout Shift）

視覚的な安定性を「CLS（Cumulative Layout Shift）で測定されます。
ページの読み込み中に、画像やテキストなどの要素が予期せずにズレてしまうと、ユーザーは不快感を感じたり誤操作をしてしまう可能性があります。
CLSは、このようなレイアウトのずれを数値化することで、ページの視覚的な安定性を評価します。
CLSの値が小さいほど、ページのレイアウトは安定しており、ユーザーにとって快適な閲覧体験を提供できていると言えます。

具体的には、ブラウザバグや広告が差し込まれたり、画像の読み込みが遅い時などに発生するズレのことを指していますね。
フォントファイルの読み込みが遅く、フォントが切り替わってレイアウトに影響を与えることもありますよね。

CLSを改善するポイントとして以下のような工夫が出来ます。

• 画像のサイズを指定する。
  画像のサイズをHTMLで明示的に指定することで、ブラウザは画像の読み込みを待たずにレイアウトを確定できます。
  <img src="example.jpg" width="300" height="200">のように”width属性”と”height属性”を使用しましょう。
  （インラインで style="width:**px;" でも可だと思います。）
• 広告の配置を工夫する。
  ページ上部に大きな広告を配置すると、コンテンツが下に押し下げられてレイアウトシフトが発生しやすくなります。
  広告のサイズを固定したり、コンテンツの読み込みを妨げない場所に配置するなど工夫が必要です。
• Webフォントの読み込みを最適化する。
  Webフォントの読み込みが遅延すると、テキストの表示が遅れてレイアウトシフトが発生する可能性があります。
  font-displayプロパティをswapに設定するなど、フォントの読み込み方法を最適化しましょう。

Googleはサイトの離脱の原因に繋がるとしていますので、十分に工夫して対処したところですね。

大きく言えばミニファイ化

正直、この一言でまとめるのは危険かもしれませんが、これらのことを大きく言えば「盛大なるミニファイ化」ということかなと感じています。
私どもは、常々コーディングとリソースに配慮するようにしてるんですが、絶対に効果はあると思うんですね。
無駄なソースを減らし、無駄なデータを減らし、サーバーになるだけ負荷をかけすぎず、ユーザーに対してすぐにレスポンスを返していきましょう・・・という盛大なるミニファイ化ですね。

とくに、JavascriptとCSSと画像ファイルについては、軽量化すればするほど、目に見えて動作が変わります。

正直なところ、大きな売り上げをあげているシステムであったり、メンテナンス性を考慮しているシステムは、関係者が困らないようにインデントを入れて視認性を確保していたりします。
また、ブラウザバグ対策も大きな仕組みほど対策が複雑化しているのが実情かなと思います。
運用事情も大きく関わってきますので、難しいところですね。
画像ファイルに関しては、高解像度で書き出した後に最適化していきファイルの容量は減らしていきたいところかもしれません。

具体的に何に気をつければいい？

大規模サイトはともかくとしてリソース的に可能な範囲で以下のことにまずは配慮してみるというのが現実的かなと考えています。

• プログラムコードの最適化
• htmlソースの最適化
• javascriptの最適化
• cssの最適化
• 画像ファイルの最適化

最適化というのは、可能な限り軽量化しましょう・・・という流れですね。
画像ファイル一つで80kbの容量があったとして、1ページ内でそういう画像が10個も20個も使われていると、デバイスによってはレンダリングが遅くなってきます。
ですので、そういう場合は、画像を80kbから50kbにする努力をしましょう・・・というところなんですね。
システムでキャッシュを生成するシステムなどもありますので、そういうプログラムを使うのも一つの手ですね。

cssやjsの軽量化は、まぁまぁデリケートなところかなとも感じますので、専門家の監修のもとに進めていただきたいところかなと考えます。

そんな、たいしたことないよ・・・と言われる方もいますが、定期でコンテンツを増やしていく中で、どうしても煩雑になるコードと増えていくコード・・・。
考えただけでゾッとしますが、平素、軽量化を意識してるだけで、後々、だいぶ楽になるはずですので、コンテンツを増やしていく中で十分に意識していただきたいところかなと考えています。

締め

以上です。

重ねてしまいますが、弊社ではこれらのところが最も基礎的なことであり、最も重要なところかなと考えています。

どうしてもレンダリングが遅れる・・・という大規模なサービスもありますよね。
ですが、大規模なシステムの場合、無理して頑張るところではないかなと考えます。
プログラマーさんやエンジニアさんは、SEOのことを考えて仕様を設計しているわけではありません。
それよりも間違いが起きないことや、インターフェイス上で確実にサービスを提供すること、メンテナンス性、発展系のカスタマイズ性を問われることが多いので、わざわざSEOのことを最優先に考えている方はいないと言っても過言ではないかなと考えます。
もちろん、プロジェクトにSEOマニアなディレクターがいれば、間違いなく指示してくるところだとは思いますが、ケースとしては珍しいかなと感じます。

現実的に思うことで言えば、フロントエンドのエンジニアさんやコーダーさんには是非とも体得していただきたいところかもしれません。
フレームワークを使えば、ビュー部分だけは分かれていますからね。

と、そんな諸々のことを考えています。

今後、この部分については、さらに発展していくとも考えていますので、アップデートなどがあった際には、追って記事を訂正したり、改めて書き直すなどしていきます。