ページ読み込み速度とSEO 〜高速化のための技術とSEO施策大全〜

レベル：中級〜上級

こんにちは、SEO野郎です。

今日はページの読み込み速度とSEOについて解説していきます。

Sec1. ページ読み込み速度とランクの関係

ウェブページの読み込み速度は検索エンジンにおける検索順位と一定の因果関係があります。

ページ読み込み速度とランクの関係としては以下の捉え方をするのが現状では正しいと思います。

・ページ読み込み速度が向上することでユーザーの行動がポジティブに変化し、その結果としてランクにもポジティブに働く
・読み込み速度が速ければ速いほど高く評価されるというアルゴリズムではない
・極端に読み込み速度の遅いページはランクが下がる

今回はそのページ読み込み速度の指標と計測方法、SEO観点からのページ速度の改善施策をまとめます。

ウェブページの読み込み速度に関連する全要素を解像した上で、それぞれの要素を読み込み速度の観点から最適化するTipsを網羅したつもりなので、ページ読み込み速度の改善を図るサイト運営者の方の参考になれば幸いです。

尚、今回のnoteではAMPについては扱っていません。

Sec2. ページ読み込み速度の指標と計測方法

1. ページ読み込み速度の指標

① First Contentful Paint（FCP）
・意味のあるコンテンツの初回ペイント
・ページの主要コンテンツが可視化されるまでにかかった時間

② Time to Interactive（TTI）
・インタラクティブになるまでの時間
・ページが完全にインタラクティブになるまでの時間

③ First Input Delay（FID）
・入力の推定待ち時間
・ユーザーの入力に対して応答するまでの時間

2. ページ読み込み速度の指標の計測

① Lighthouse
・FCP, TTI を計測可能
・速い：90〜100, 平均：50〜89, 遅い：0〜49
・Lighthouse について：「Lighthouse によるウェブアプリの監査」
・LighthouseのGoogle Chrome拡張機能

② PageSpeed Insight
・FCP, TTI, FID を計測可能
・PageSpeed Insight

③ Chrome User Experience Report
・FCP, FID を計測可能
・Chrome User Experience Report について

④ Webperf API
・FCP. FID を計測可能

Sec3. レンダリングリソースの大きさ

モバイルウェブにおいて平均的に1ページあたりのレンダリングデータ量が大きいリソースは以下の順となっています。
1. 画像（約500KB）
2. JavaScript（約380KB）
3. フォント（約80KB）
4. CSS
5. HTML
6. その他リソース

Sec3. ページ読み込み速度の最適化

レンダリングリソースの上位要素に対して、それぞれどのような対応を行えばページ読み込み速度の改善に繋がるのか、各リソースに対して解説します。

1. 適切な画像フォーマット

① WebP
・WebP：Googleが開発した, 品質を保ったまま高圧縮できる画像フォーマット（現在グローバルで72%のユーザーが利用可能）
・Chrome、MS Edgeはサポート、Firefoxはサポート予定、Safariは不明
・JPEG、PNGに比べて25〜35%サイズが小さくなる
・WebPをサポートするブラウザとしないブラウザの両方に適切に画像を配信させるHTML例（HTMLの上から順番にサポートしているフォーマットの画像を1つだけ読み込ませる）

<picture>
　　　<source type=“image/webp” srcset=“example.webp”>
　　　<source type=“image/jpeg” srcset=“example.jpg”>
　　　<img src=“example.jpg">
　　</picture>

② アニメーションGIF
・アニメーションGIFはサイズが大きいため、MPEG-4（MP4）を使用する （アニメーションGIFはMP4の4〜20倍サイズが大きくなる）cf. TwitterではアニメーションGIFをアップロードするとMP4に自動変換される
・ffmeg（https://www.ffmpeg.org/）を使用するとコマンドラインでアニメーションGIFをMP4に変換できる（$ ffmeg -i dog.gif）
・変換後はHTMLタグを<img>タグから<video>タグに変更する 
・MP4動画をアニメーションGIFのように自動再生、ループ再生、消音、インライン再生にするためには “autoplay loop muted plyasinline” を追加（以下に記述例）

<video autoplay loop muted plyasinline>
　　　<source src=“example.mp4” type=“video/mp4”>
　　</video>

③ 動画
・将来的にはAV1を推奨
・VP9（WebM）よりも約30%圧縮が優れている
・x264（MPEG-4）よりも圧縮が45〜50%優れている
・デスクトップ版Chrome70でサポートが開始

2. 画像の圧縮

① 画像の圧縮の種類
・Lossless：データを損失しない
・Lossy：データを損失するがより高い圧縮が可能
・Losslessでの圧縮は最低限必要、ほとんどのサイトにおいてはLossyでより高圧縮すると良い
・Lossy圧縮では 0〜100のスケールで圧縮率を設定できる（0に近づくほど高圧縮だが画像のクオリティも落ちる）
・ほとんどの画像では80〜85でLossy圧縮すればファイルサイズを30〜40%削減しつつクオリティの劣化を最低限に抑えられる

② 圧縮ツール
・Imageminが一般的
・Imagemin：webpack、node.js、gulp等の様々な技術から使用できる（JPG、PNG、GIFなどの主な画像フォーマットのプラグインが存在）

3. 適切な画像サイズ / 密集度

① 画像のサイズ
・デバイスのスクリーンサイズに合わせて画像サイズを配信し分ける（cf. MERY）→ データ転送量を抑え、CPUの使用も抑えられる
・画像サイズ変更ツールとしてnpmパッケージのSharp、Jimpを使用できる
・複数のサイズの画像を配信させる → srcset と size によって画像の大きさを指定することで、どの画像をレンダリングするかをブラウザが決定できる（px ではなく w を使用する）（以下にHTML例）

　<img srcset=“example-small.jpg 480w, example-large.jpg 1080w” size=“50vw” src=“example.jpg”> 

4. Lazyload

① Lazyload 概要
・あるタイミングまでリソースの読み込みを遅らせる技術
・主に画像に使用されるほか、JavaScriptなどその他のリソースにも使用可能
・ページ読み込み時のパフォーマンスを向上させることが主な目的
・cf. SpotifyはLazyloadを使用 → ページ内の全画像を読み込むと18MBだがスクリーン内のみの画像を読み込ませると1MBに抑えられる
・JavaScriptで実装するのが一般的
・Chromeがブラウザの機能としてLazyloadをサポートするようになる

② LazyloadとSEO
・一般的にLazyloadはJavaScriptで実装する
・Lazyloadで実装された画像は本来Googleにクロールもインデックスされない → だから特殊な対応を行ってクロール / インデックスさせる実装が必要
・Googleは IntersectionObsever API によるLazyloadの実装を推奨
・GoogleはLazyload実装時に polyfill の実装及び<noscript>タグと構造化データの設定を推奨（SEO的には polyfill の実装が非常に重要）

（1）IntersectionObserver API
　・IntersectionObserver API はChrome 51からサポート → 現在のWRS（Web Rendering Service）はChrome 41相当なため、Googleは IntersectionObserver API で遅延読み込みさせる画像をレンダリングできない

（2）polyfill
　・polyfill：新しい技術をサポートしないブラウザでもその機能を利用できるようにするための仕組み
　・polyfill によって IntersectionObserver API をサポートしない Google/WRS にも画像を認識させられる（ユーザーのブラウザには IntersectionObserver API によって Lazyload を適応し、Googlebotには polyfill によって最初から全ての画像を認識させる）

（3）<noscript>タグ
　・GooglebotがJavaScriptを実行しなくても画像を認識できるように <noscript>タグで画像を指定する方法
　・GoogleはLazyloadの画像については<noscript>タグを正常に処理する
　・cf. 本来Googlebotは<noscript>タグを無視する（スパムに乱用されたため）が、Lazyload画像に対して記述されたものについてはこの限りでない
　・<noscript>タグで画像を指定する場合もalt属性は設定するべき

（4）構造化データ
　・構造化データの中で画像のURLを記述する
　・Googleは実際の画像が表示されていなかったとしても構造化データのURLを取得して画像をクロール、インデックスする
　・JSON-LDを使用してマークアップする（microdataは実際の画像に対してマークアップするため）
　・Imageプロパティを持つタイプの構造化データなら画像のURLをそのまま設定しておくだけ
　・可能であればより多くのプロパティを設定すると良い
　・画像にはImageObjectの構造化データが使える （以下マークアップ例）

<script type=“application/ld+json”>
　　{
　　 “@context": “http://schema.org”,
　　 “@type”: “https://example.com/barackobama.jpg”,
　　 “description”: “バラクオバマの写真”
　　}
　　</script>

5. JavaScriptの最適化

① JavaScript 概要
・JavaScript の1ページあたりのデータ量中央値：モバイル370KB、デスクトップ420KB（JavaScriptは圧縮されて転送されるため実際には約1MBのファイルとなる）→ これを復元、パース、実行すると性能の低いデバイスでは非常に遅くなる

② JavaScript リソースの読み込み高速化施策
・Code Splitting
・Preload
・利用しないJavaScript（及びCSS）の精査

6. フォントの最適化

・ウェブフォントはページ読み込み速度を低下させる
・Flash of Invisible Text（FOIT）：ブラウザがウェブフォントを読み込むまで文字が現れない現象 → UXのためにFlash of Unstyled Text の採用を推奨
・Flash of Unstyled Text（FOUT）：ブラウザがウェブフォントをダウンロードするまでシステムフォントを代用して文字を表示する技術（ウェブフォントのダウンロードが完了するとシステムフォントと置き換わる）
・cf. システムフォント：PC、スマホにデフォルトで入っているフォント
・以下FOUTの実装例（最終行がブラウザへのフォントの入れ替えの命令）

@font-face {
　　　　font-family: ‘Pacifico’;
　　　　src: url (…pacifico.woff22) format (‘woff2’);
　　　　font-display: swap;
　　}

7. リダイレクト数の制限

・各ページのリダイレクトは1回以下に抑えるべき

8. ファイルの圧縮

・不必要なデータを削除する
・データが削除できない場合には、Gzip、Brotli などのツールを使用してコンテンツを圧縮しファイルサイズを下げる

9. サーバー応答時間を200ms以下に抑える

・HTTP/2 を使用することでサイトパフォーマンスを向上させられる
・OCSPステープリングを有効にすることでTLSシェイクハンド時間を高速化できる

10. キャッシュポリシーの設定

・ブラウザのキャッシュを利用し、ブラウザがレスポンスをキャッシュする方法と期間を制御する
・Etagsを使用して再バリデーションを効率化する

11. CSSの最適化

① CSSの最適化
・外部参照のCSSファイルは1つだけにする → HTTPリクエストで生じるレイテンシーを削減

② インライン化
・そのページに固有のCSSはインラインで記述する（外部ファイルを参照させない）
・小さいCSSファイルはHTMLにインライン化する
・大きなCSSファイルやCSS属性はHTML要素にインライン化しない（外部ファイルを参照させる）

12. above the fold の最適化

⓪ above the fold 最適化のベース
・above the fold：ユーザーがスクロールせずに閲覧することのできる画面領域（いわゆるファーストビュー）
・HTMLマークアップを整理してコンテンツの可視化を優先し、ファーストビューコンテンツが素早くレンダリングされるようにする
・ファーストビューコンテンツのサイズは148kB以下に抑える
・モバイルユーザーにとっては特に重要
・Googleは Above the fold のコンテンツを1秒以内に表示させることを推奨
・cf. 基本的にブラウザはHTMLを上から順に読み込み表示する

① above the fold とそれ以外の部分のHTMLを分割する
・above the fold のコンテンツのHTMLを先に記述する
・above the fold で表示する部分のサイドバーのコードもその他のサイドバーとは分けてHTMLに記述する
・above the fold のコンテンツに適用するCSSは外部参照させずインライン化する

② ファーストビューのレンダリングを妨害するJavaScriptを取り除く
・重要でないスクリプトは after the fold 以下のサードパーティーJavaScriptライブラリに分ける
・above the fold にJavaScriptが存在する場合、<script>タグをasyncとして記述し、レンダリングを妨害させないようにする

③ above the fold のコンテンツの読み込みが終わるまでJavaScriptの読み込みを遅らせる
・優先度の低いJavaScirptの読み込みを遅らせる（ソーシャルボタンのためのJavaScriptなど）
・JavaScriptの読み込みを延ばすためには、body終了タグ（</body>）の直前に以下のコードを記述する

<script type=“text/javascript”>
　　function downloadJSAtOnload() {
　　var element = document.createElement(“script”);
　　element.src = “自社サイトの環境での外部参照のJavaScriptファイルのパス”;
　　document.body.appendChild(element);
　　}
　　if (window.addEventListener)
　　widow.addEventListener(“load”, downloadJSAtOnload, false);
　　else if (window.attachEvent)
　　window.attachEvent(“onload”, downloadJSAtOnload);
　　else window.onload = downloadJSAtOnload;
　　</script>

おしまい

以上、ページ読み込み速度の改善施策一覧をまとめて見ました。今後も更に有効そうな技術や施策が出現したら随時追記していきたいと思います。

冒頭に記述した通り、ページの読み込み速度は速ければ速いほど検索順位にポジティブに作用するという類の要素ではなく、サイト内でのユーザーの行動に影響して間接的にランクに作用するものです。

読み込み速度の速いページほどユーザーにとっては快適なはずなので、SEOを過剰に意識しすぎず、最適なユーザー体験を目指して高速化に取り組むのが良いのではないかと思います。