運用中サービスに対するCore Web Vitals(CWVs)対策まとめ【追記予定】

2021年5月13日 17:04

先月くらいまでは日本語での情報が少なかったCore Web Vitals対策ですが、SEOスコアに影響が出始める期日が迫るにつれ、まとまった情報が見つかるようになってきました。
ただ、「そんな対策、こんな小さい案件じゃできないよ」という内容も多いですので、現実的な範囲で何ができるかという観点でまとめてみたいと思います。
※Page Speed Insightsの表記を前提にしています

最も効果の大きい対策：Webフォントを辞める

個人的に最も効果が大きかったのは、「Webフォントの使用をやめる」でした。OSデフォルトのフォントでマークアップすると、
・Windows、Mac間でフォント違いの崩れが発生する
・Androidに明朝体が入っていない
といった最終確認で躓くようなことが良くありますので、基本的にはnoto sans、明朝が必要であればnoto serifを使用することが殆どでした。
標準的な読み込み方としては、下記のような形ですが、

<link rel="preconnect" href="https://fonts.gstatic.com">
<link href="https://fonts.googleapis.com/css2?family=Noto+Sans&display=swap" rel="stylesheet">

CWVsが本格化する前の時点ですでにスコアに悪影響（レンダリングがブロックされる）がありましたので、WebFontLoaderを使って読み込むこと改善を試みていました（少なくとも2年前はかなり効果がありました）。
ですが、CWVsでの評価が加わってからはそれでもスコアが悪化してしまう（LCPやCLSが悪化する）ため、SEOを重視するのであればWebフォントは使わない方がベターといえます。

既にNoto sans等を使用してOS間のフォントを平準化している場合、単純に使用をやめてしまうと至る所で崩れが発生する可能性がありますが、私の場合は下記のように游ゴシックに寄せることである程度回避できました。

font-family: "游ゴシック体", YuGothic, "游ゴシック Medium", "Yu Gothic Medium", "游ゴシック", "Yu Gothic", "メイリオ",'ヒラギノ角ゴ Pro W3', 'Hiragino Kaku Gothic Pro',  sans-serif;

ヒラギノを優先して指定することが多いですが、OS間で同じフォントを使用したいという理由で游ゴシックを優先指定しています。
さらに、Windows標準の游ゴシックは細すぎてサイトの印象が大きく変わってしまうので、Midiumを指定するようにしています。

どうしてもWebフォントを辞められないという場合は、フォントをPreloadしたり、サブセット化したりとやりようはあるみたいですが、小さい案件でそこまでできないというケースが殆どだと思いますのでWebフォントを辞められないか検討したほうが個人的にはベターかなという印象です。
どうしてもという方は下記ご参考ください（私は心が折れました）
https://note.com/taira_daishiro/n/nf037bf199ed8

LCP（Largest Contentful Paint）の意味

定義については理解が少々曖昧なのですが、このスコアが悪い場合は画像、動画などのサイズの大きな要素の読み込みに時間がかかっているという理解で対策しました。

LCP対策（１）：Webp対応

Page Speed Insightsでも良く指摘される項目ですが、
・squoosh等のWebサービスでwebpファイルを準備
・.htaccessで画像ファイルをwebpファイルにリダイレクト（参考）
の2点で実施できるので、ソース中の記載一つ一つを対策していくよりは負担が少ないと思います。

Wordpressのメディア画像に対しては、対応しているプラグインが色々あるのでインストールしておくとベターですが、プラグインによっては遅延読み込み用のJSを勝手に吐き出すものなどもある（JSの実行時間分スコアが悪化する）ので注意が必要です。

LCP対策（２）：サイズの大きな画像のプリロード

ヒーロー画像、キービジュアル、メインビジュアルなど方言は様々ですが、サイトのファーストビューには大きめの画像を使用していることが多いと思います。（この記事ではメインビジュアルと呼称します）
その画像をpreload（＝HTML内のimgタグ解析前に予め読み込む）ことでレンダリング時に画像の読み込みでブロックされることを防ぎます。

<head>
メタタグ等は省略

<link rel="preload" href="/images/mv-bg.jpg" as="image">
<link rel="preload" href="/images/mv-front.png" as="image">
<link rel="preload" href="/images/logo.png" as="image">
</head>

上記の例では、ロゴ、メインビジュアル、メインビジュアルの背景をpreloadするようにしています。PCとモバイルで出し分けている場合両方書く方が正しいか悩ましいところですが、CWVsで問題になるのはだいたいモバイルなので、私の場合はモバイル画像だけをpreloadするようにしました。
「スコアの改善のためにやってる」感があってあまり好きではないですが、一旦効果はありました。

LCP対策（３）：CSSで画像の出し分けをしない

PCとモバイルでブラウザの縦横比は大きく異なるので、メインビジュアルをPC用、モバイル用でdisplay:none;を使って出し分けするケースはよくあると（個人的には）思っています。
この手法の場合、PC用とモバイル用の画像はどちらもサーバーにリクエストされるため、モバイルでアクセスしても不要なPC用画像がダウンロードされていることになります。

こちらの対策としては、srcsetを使って対策することがベターと思われます。imgタグの属性としてsrcsetを使う方法とpictureタグの属性としてsrcsetを使う方法があると思いますが、より柔軟に対応できるpictureタグを使用した例はこちらです。

<div class="mv">
 <div class="mv-front">
  <picture class="mv-img">
   <source media="(min-width: 769px)" srcset="/images/mv-front-pc.png">
   <source media="(max-width: 768px)" srcset="/images/mv-front-sp.png">
   <img src="/images/mv-front-pc" alt="">
   </picture>
 </div>
</div>

CSSのメディアクエリと同様の考え方で、画面解像度によって画像の出し分けが可能です。上記は解像度のみを考慮した例ですので、2倍解像度の画面対応する場合などはその旨記述します。ググれば例はいっぱい出てくると思います。
FCP対策（１）のWebp対応を「htaccessを触れない環境」で実現する場合、srcsetによる出し分けで対応することもできますので、参考になれば嬉しいです。

LCP対策（４）：画像、動画、Google Mapの遅延読み込み

画像、iframe等を遅延読み込みしないと、画像等がすべてダウンロードされるまでレンダリングがブロックされます。Page Speed Insightsでは「オフスクリーン画像の遅延読み込み」という表記になっていますが、個人的にはYoutubeの埋め込みやGoogle Mapの埋め込みに使われているiframeも、遅延読み込みすることでかなりのスコア改善が見込みますので対応したほうがベターです。
遅延読み込みの方法としては意見が分かれるようにも思いますが、私は現状JSライブラリ（lazysizes）で対応しています。
Chromeではブラウザ標準の機能で遅延読み込み対応されていますが、Sfariはまだ未対応ですのでJS対応を続けています。（近く実装されるようですが）

ライブラリ使用を続けているサポート状況以外の理由としては、「background-image」の遅延読み込みができるということです。background-imageを使用したほうが実装しやすいデザインも少なくないですし、しばらくは様子見というスタンスです。

CLS（Cumulative Layout Shift）の意味

口に出すときは「レイアウトシフト」という呼び方をすることが多いですが、簡単に言うと「一旦レンダリングされたものの再レンダリング」見たいな意味です。
主な対策ポイントは下記2点と考えています。
・フォントswap時のチラつき（字形によっては高さも変わる）
・画像遅延読み込み時に、画像ローディング完了で画像の高さ分だけ下の要素が移動する
フォントスワップ問題は、「最も効果の大きい対策：Webフォントを辞める」の末尾にも記載した通り対策難易度が高いので、ここでは画像を対象に対策を上げさせていただきます。

画像を対象にしたCLS対策は全て、「画像が読み込まれる前にブラウザに画像の高さを教えてあげる」という一言に尽きます。ブラウザが最初から画像の高さを知っていれば、その分のスペースを空けておいてくれるので画像よりも下の要素にレイアウトシフトが発生しなくなります。

CLS対策（１）：aspect-ratioプロパティの設定

個人的なおススメはCSSのaspect-ratioプロパティの設定です。
・対策の目的とプロパティの意味が一致していること
・CSSだけで完結すること
が理由です。
先にも上げたメインビジュアル画像に対して適用した例がこちらです。

@media only screen and (max-width: 768px) {
 .mv-img > img {
  aspect-ratio: 750 / 800;
 }
}
@media only screen and (min-width: 769px) {
 .mv-img > img {
  aspect-ratio: 1200 / 600;
 }
}

この例は、PC用画像を1200px*600px、モバイル用画像を750px*800pxで用意されている場合のサンプルです。ブラウザに何pxで表示されるかは考えず、元画像の縦横pxを書くだけで良いので、heightをVWで指定する等の計算が苦手な方にもおススメです。
ブラウザは、縦横比と画面幅を知っているので、heightを指定しなくてもそのスペースを親切に空けておいてくれます。

CLS対策（２）：paddint-topを利用する

「Aspect ratio box」と呼ばれるアスペクト比を固定したブロックを使用する手法ですが、詳しく説明してくれている方がいらっしゃるので解説はそちらに譲ります。
https://zenn.dev/akatsuki/scraps/2a02edda4a8ff2

CLS対策（３）：imgタグにwidth、heightを記載する

こちらの対策についてはタイトルの通りですが、逆に私が採用しなかった理由を述べさせていただきます。

１．めんどい
いちいちすべてのimgタグにwidth、heightを書くのめんどいですよね…
Wordpressがメディア画像に対して標準でwidth、height属性を付与するのはおそらくこの目的があると思われます。

２．picture要素のsourceタグに記載できない
FCP対策でpicture要素を用いて画像を出し分けする場合、picture > sourceタグにはwidth、heightを指定できません。
PCとモバイルで共通の画像を使用する場合は問題になりませんが、私が今までかかわってきた案件の場合は、PCとモバイルの画像を全く出し分けしない案件はほぼありませんでしたので、採用が難しいかなと思った次第です。

FCP対策

FCP（First Contentful Paint）については、正直何を改善するか見えていません。
私の場合、LCP、CLSを改善する過程で改善していきました。

FID対策

こちらについては、ラボデータによると95%のサイトでクリアされている指標のようですので割愛します。
問題があるしサイトでもその他の指標に対応していくうちに解決することが多いですし、よっぽど遅いサーバーやバックエンドプログラムを使用していない限りは問題ないと思います。

対策する上でのTIPS

CWVs対策を行う場合、Page Speed Insightsを使用するのはデフォだと思いますが、「この機能ありがたいよね」というものを幾つか紹介します。

Tips-1：Lighthouse Scoring Calculator

Page Speed Insightsの「See Calculator」をクリックすると、どの要素を改善すればスコアがどのくらいになるかを計算できる画面が表示されます。

この画面でvalueの値を上下させると、右側のスコアが変動します。
対応していく中でも、感覚的に「対策しやすそう」な指標は見えてくると思うので、対策しやすい指標を解決するとどの程度スコア変動が見込めるのか把握することができますので、効率の良い対策ができると思います。

Tips-2：LCPになっているコンテンツの表示

診断結果内の「最大コンテンツの描画」を開くと対象になっている要素とイメージが表示されます。
この要素がLCPだと思っていたら違った！ということが稀にあります。頑張って対応した要素が影響の少ないものだとしたら悲しいので、対策前に対象になっている要素を確認してから対策することをお勧めします。

何か新しい対策が見つかるたびに追記・更新していく予定です。
個人的には、自分が担当している案件だけがCWVsのスコアが良く、他のサイトは悪いままという状況の方が仕事上良いんだろうとは思いますが今年は無職というペルソナ設定で生活しているので気にしないことにします。