技術情報

SEOウェブ・バイタルの改善

2025年01月21日 SEO レポート 分析する

 

SEOウェブバイタル機能はMatomo オンプレミス専用 であり、Matomoクラウドではご利用いただけませんのでご注意ください。

測定基準がわかったら、「改善が必要」（オレンジ色）または「悪い」（赤色）の範囲にあるものを改善することを目指しましょう。SEOウェブ・バイタルレポートを確認したときに、あるページの指標のいくつかが赤で表示されていることに気づいたら、そのページから始めるのが良いかもしれません。サイトのスコアの要因と改善の可能性を確認するには、プラスアイコン Plus Iconをクリックしてこれらの値の行を展開し、監査ラボのデータでパフォーマンスの低いスコアを探します。

Audit Lab Data

コアとなるSEOウェブバイタルの指標は太字で表示され、サポートとなる診断と最適化の可能性は標準的なフォントで表示されます。スコアが100%未満のメトリクスまたは最適化は、改善の余地があることを意味します。トップレベルのSEOウェブバイタルの指標を改善する方法と、一般的な要因に関する一般的な説明をご覧いただけます。この下には、監査ラボの最適化の完全なリストと、スコアの改善に役立つ可能性のある方法が記載されています。

ページ・スピード・スコアを向上させる方法

ページ・スピード・スコアは、他のパフォーマンス指標の加重平均であるため、直接最適化することはできません。代わりに、総合的なスコアを向上させるために基礎となる指標の改善に焦点を当てる必要があります。監査ラボデータの完全なリストから最もパフォーマンスの悪い診断または指標を選択し、そこから最適化の旅を始めるという戦略を検討するとよいでしょう。他の指標が改善され始めると、Page Speedのパフォーマンススコアにも反映されるはずです。

FCPの時間を短縮する方法

FCPの値が遅くなる要因はたくさんあります。この指標を改善するために行うべき最善のことの1つは、トラフィックのレベルに適したプランで高品質のウェブホストを利用していることを確認することです。その上で、最も一般的な問題と、スコアを向上させるためにできる最適化を見つけることができます。

LCPのタイムを向上させる方法

最大のコンテンツフル・ペイントは、コンテンツが画面上にレンダリングされるかどうかにかかっています。したがって、ファースト・コンテンツフル・ペイント（FCP）のローディング時間が速ければ速いほど、最大のコンテンツを早く読み込むことができます。つまり、FCPが速くないと思われる場合は、まずFCPを最適化するための推奨事項を完了する価値があります。

とはいえ、最大のコンテンツペイントの表示時間を改善するためにできることはたくさんあります。ページで不要な大きな要素を削除する以外に、最も一般的な最適化のいくつかを以下に紹介します。

FIDスコアを向上させる方法

ブラウザの処理に50ms以上かかるものは、長いタスクと考えられます。テストの際、FIDを再現することは不可能なので、代わりにTotal Blocking Timeを最適化する必要があります。このスコアは、ユーザーがどの要素とインタラクションするかによって、偶然の要素もあることは注目に値します。FIDスコアを最適化するためにできることの例をいくつか挙げます：

CLSスコアを向上させる方法

ページが持つことのできるレイアウトの数はほぼ無制限であるため、様々なことがページのレイアウトシフトを引き起こす可能性があります。CLSスコアに影響を与えるほとんどの変更は、ウェブサイトのコードを変更する必要があります。このスコアを向上させるためにできることの例を、以下のセクションでご紹介しています。また、サイト上のどの要素がレイアウトのずれを引き起こしているかを確認できる便利なオンラインツールもあります。

フォールバック要素がダイナミック要素と同じサイズであることを確認する。

多くの場合、ウェブサイトは最初のHTMLを受け取った後、動的にコンテンツをロードする。例えば、サードパーティのウェブサイトからコンテンツを取り込むJavaScriptウィジェットなどである。このような場合、完全なデータがダウンロードされるまでに時間がかかることがありますが、ウィジェットが読み込まれる前にサイズがわかることがよくあります。したがって、動的に含まれるコンテンツと同じスペースを取るように、要素コンテナを設定する必要があります。

例として、幅768ピクセル、高さ500ピクセルになることが分かっているソーシャルメディア・ウィジェットを読み込む場合、次のようなコードを使えば、div要素が動的に更新されるまでスペースが確保される。

HTML

<div class="SocialMediaWidget"></div>

CSS

.SocialMediaWidget {
    height: 500px;
    width: 768px;
}

画像の高さと幅を指定しないと、画像をダウンロードする際にレイアウトがずれてしまい、CLSに悪影響を及ぼします。

監査ラボの最適化の全リスト

過剰なDOMサイズを避ける

DOMサイズとは、HTMLページの構造を持つすべてのオブジェクトの合計サイズのことです。ページ上の要素が多ければ多いほど、このサイズは大きくなります。ページから不要な要素を削除し、コンテナを必要最小限にまとめることで、このサイズを小さくすることができます。

複数ページのリダイレクトを避ける

リダイレクトはページのロード時間を長くしますので、可能な限り避けるようにしましょう。リダイレクトはページ自体だけでなく、JavaScriptやCSSファイルなど、ウェブページにリンクされているアセットにも当てはまります。リダイレクトが避けられない場合は、複数のリダイレクトを使用するとさらに読み込み時間が遅くなるため、一回で済むリンクを使用することをお勧めします。

膨大なネットワーク・ペイロードを避ける

大きなペイロードは、ブラウザがページの後続部分を読み込むのを遅らせる可能性があります。平均的なファイルリクエストまたはペイロードは、1,700～1,900KiBおよびアセットです。ペイロードが5,000KiBを超えると、この警告が表示されます。可能であれば、大きなペイロードを小さな論理コンポーネントに分割し、必要のないものは削除するようにしてください。

レガシーなJavaScriptをモダンブラウザに提供しない

最新のJavaScript機能をサポートしていない古いブラウザのユーザーに対応するためにコードを作成することがよくあります。しかし、このコードを考慮せずにすべてのユーザーに提供すると、それを必要としない最新のブラウザに不必要な読み込み時間を追加することになります。レガシーコードを条件付きで読み込むのは、それが必要なときだけにすることを目指すべきです。

document.write()を避ける

これはページが読み込まれた後にDOMを再描画するため、レイアウトがずれてしまう可能性がある。また、低速の接続では、コンテンツがまったく表示されない。

オフスクリーン画像を延期する

これはレイジー・ローディングとも呼ばれ、基本的に、ページ上で物理的に見える位置、つまりフォールドの上方でのみ画像を読み込むようにウェブサイトに指示します。これにより、最初のページ読み込みに必要なデータ量が削減されるため、最初のページ読み込み速度が向上します。また、必要なときだけデータをダウンロードするため、インターネット接続の帯域幅が制限されている人にもメリットがあります。

画像を効率的にエンコードする

ウェブ上で画像を圧縮してファイルサイズを小さくすることは、ユーザーの視覚的な画質に大きな影響を与えることなく、多くの場合可能です。このようなことは、画像制作中に行うこともできますし、コンテンツ管理システム（CMS）の画像最適化プラグインを使用したり、Squooshなどのオンラインツールを使用して、ウェブサイトにアップロードする前に画像を圧縮することもできます。

レンダリングをブロックするリソースを排除

ページのJavaScriptとCSSファイルは、ページが完全にレンダリングを開始する前に、完全に読み込まれ、解析される必要があります。ブラウザがこれを待っている間、これらのファイルは「レンダリングをブロックするリソース」となります。つまり、これらのファイルが多ければ多いほど、また大きければ大きいほど、サイトの読み込み時間が遅くなる可能性が高くなります。

そのため、サイト上で複数のJavaScriptやCSSファイルにリンクしている場合は、それらが実際に使用されるページでのみ読み込まれるようにしてください。例えば、価格設定ページのテーブル用のカスタムスクリプトやスタイリングは、価格設定ページにアクセスしない人のためにダウンロードする必要はありません。

さらに、ロードに必要なコードの総量を減らすために、何らかの理由で不要になったコードがないか、定期的にファイルをチェックするとよい。

テキスト圧縮を有効にする

テキスト圧縮は、複雑なアルゴリズムを使用して、HTML、JavaScript、CSSファイルなどのテキストのみのドキュメントのファイルサイズを縮小します。テキスト圧縮の最も一般的な形式はGZIPですが、Brotliも広くサポートされている新しい代替手段です。これらのツールはどちらもサーバー上で設定され、ページのファイルサイズが小さくなるため、読み込み時間が短縮されるはずです。あなたのサイトがどのようなテキスト圧縮方式を使用しているかは、テキスト圧縮テストツールで確認することができます。これらのツールのいずれかを使用していない場合は、いずれかを有効にするためにホストに連絡する必要があります。

Webfont のロード中にテキストが表示されるようにする

カスタムフォントは、レイアウトシフトの一般的な原因です。ユーザーが自分のデバイスに特定のフォントを持っていない場合、コンテンツを表示する前にそのフォントをダウンロードする必要があります。ウェブサイトがどのようにカスタムフォントを実装しているかにもよりますが、カスタムフォントがダウンロードされると、サイズが異なるデフォルトのフォントでテキストが読み込まれ、更新される場合があります。

これを解決する最も簡単な方法はウェブセーフなフォントを使用することである。これらは訪問者のデバイスにすでにインストールされている可能性が高いからです。これにより、ブラウザが特別なものをダウンロードする必要がなくなり、ウェブサイトが必要とするデータ量を削減できるという利点もあります。しかし、フォントは重要なデザインおよびブランディングツールであるため、これはオプションではないかもしれません。

ウェブサイトにカスタムフォントが必要な場合、ウェブサイトのレイアウトがずれるのを防ぐためにできる対策がいくつかあります。1つ目は、カスタムフォントをあらかじめ読み込んでおき、ページの読み込み順序の早い段階でダウンロードされるようにすることです。これを行うには、サイトのHTMLの<head></head>セクション内に<link rel="preload">タグを追加します。hrefと typeの値がカスタム・フォント・ファイルに対して正しいことを確認してください：

<link rel="preload" href="fonts/customfont.woff2" as="font" type="font/woff2" crossorigin>

また、font-display: optionalオプションのCSS属性と組み合わせることで、ブラウザがカスタム・フォント・ファイルのダウンロードを試みる間、フォントのレンダリングを最大100ms遅延させることができ、レイアウトがずれる可能性を回避することができます。

初のペイント3G

これは模擬3g携帯端末でのファーストコンテントフルペイントの時間です。FCPよりも遅くなりますが、同じ許容範囲内に収まるように目指してください。

最初の意義ある塗装

FMPとしても知られるこの指標は、ブラウザ間で一貫性がないため廃止されつつあります。FMPがどのようなものであったのか、また FMPが廃止されるに至った背景にはどのような課題があったのかについては、こちらをご覧いただきたい。

JavaScript実行時間

これは、あなたのウェブサイトでJavaScriptを実行するのにかかる時間です。過度に長い場合は、例えば視覚的な装飾など、サイトの機能にとって不可欠でないJavaScriptを削除することを検討するとよいでしょう。コンテンツ管理システムを使用している場合、同じスクリプトが何度も読み込まれている可能性もあります。このような場合は、カスタムコードやプラグインが正しいメソッドを使用して依存関係を呼び出し、重複を回避できるようにします。あるいは、プラグイン内のオプションやフィルタを検索して、よく使われるパッケージが不要な場合は無効にすることもできます。

CSSの最小化

これにより、CSSファイル内の不要な空白が削除され、ファイルサイズが小さくなるため、読み込みが速くなります。このために使用できるオンラインツールがあります。.

JavaScriptの最小化

これにより、JavaScriptファイル内の不要な空白が削除され、ファイル全体のサイズが小さくなるため、読み込みが速くなります。場合によってはコードに問題が生じることもあるので、変更後は必ずサイトのテストを行ってください。JavaScriptを最小化するために使用できるオンラインツールがあります。

メインスレッドの作業を最小限に抑える

メインスレッドは、HTML/CSSとJavaScriptのすべての解析と実行を含む、ブラウザがウェブページを読み込むためのコア処理を記述します。メインスレッドは一度に1つの処理を行うため、大きなスクリプトがメインスレッドをブロックすると、それ以前のタスクが完了するまでサイトの残りの部分の処理を続行できなくなります。したがって、メイン・スレッドで処理しなければならない作業が少しでも減れば、全体としてページ読み込みの完了が速くなります。メインスレッドでの作業を最小限に抑えるためにできることはたくさんあり、その多くはこのページで説明しています。以下のことができます。メインスレッドの作業を最小限に抑えるための最も一般的な方法については、こちらをご覧ください。.

最新の画像フォーマット

AVIFとWebPはどちらも新しい画像ファイル形式で、従来のjpgやpngファイルよりも圧縮率が高いため、ファイルサイズが小さくなります。ファイルサイズが小さいため、一般的に読み込みが速くなり、ページのパフォーマンスが向上します。残念ながら、どちらの新しいフォーマットもブラウザやウェブアプリケーションではそれほど広くサポートされていないため、フォールバックを提供する必要があるかもしれません。以下の方法があります。ウェブ用ファイルフォーマットについて詳しくはこちら.

必要なオリジンへの事前接続

多くのウェブサイトは、サードパーティドメインのアセットを利用しています。DNSの解決、SSL証明書の検証、リダイレクトの可能性などに時間がかかるため、特に低速なネットワークでは、新しいリクエストのたびに読み込み時間が長くなります。これらのアセットがDOM内で後からリクエストされると、このプロセスが始まる前にコンテンツの多くがすでにロードされているため、さらに遅くなる可能性があります。このような事態を避けるため、<link rel="preconnect">タグまたはdns-prefetchタグを使用してサードパーティのオリジナルに事前に接続し、読み込みプロセスの早い段階でネットワーク交渉が行われるようにします。すでにアセットをプリロードしているドメインでは、これは必要ないかもしれません。

プリロード・キー要求

リソースの中には、ダウンロードに時間がかかっても、ページのロード中に後から発見されるものもあります。例えば、@font-face CSSルールによって読み込まれるフォントなどです。このような場合は<link rel="preload">タグを使用して、重要なファイルができるだけ早くロードされるようにし、FCPに悪影響を与えないようにします。

lcp イメージのプリロード

最大の内容を持つペイント(LCP)が画像である場合、以下の方法でプリロードすることができます。<link rel="preload">を使用して、可能な限り早いタイミングで読み込まれるようにしてください。そうしないと、ブラウザがダウンロードを待つ間、処理が遅くなる可能性があります。

画像の適切なサイズ

アップロードする写真は、読み込む場所に合わせて適切なサイズにしてください。最近のカメラは、平均的な画面解像度の何倍もの写真を撮影することがよくあります。フル解像度で写真をアップロードすると、ページリクエストに不必要な読み込み時間が追加されます。

サーバーの初期応答時間を短縮（TTFB）

Time to First Byte (TTFB)は、最初のリクエストが送信されてから、サーバーが最初のデータを返すまでの時間を測定します。TTFBは、データベースリクエストの速度、実装されているサーバーサイドのキャッシュ、サーバーのCPUやメモリなどのWebサイトで利用可能な物理的リソースなど、さまざまなものに影響されます。したがって、TTFBを向上させるためには、サーバーサイドの処理を最適化するあらゆる機会を利用する必要があります。

JavaScriptバンドル内の重複モジュールを削除する

最近のJavaScriptは、よくあるコーディングパターンをプロジェクトごとにゼロから書く必要がないように、依存関係をまとめて構成することが多い。これは開発プロセスをスピードアップできますが、場合によってはバージョン管理やファイルパスの問題により、同じモジュールが一つのプロジェクト内で何度も呼び出されることになります。これを避ける最善の方法は、カスタムコードを作成する際に、重複の兆候がないか監査することです。もしモジュールの重複が、あなたが作成したものではないコードで発生しているのであれば、代わりに重複排除ツールを使うことができるかもしれない。

未使用のCSSを削除する

特に一般的なCMSツールでは、サイト全体で1つか2つのCSSファイルしか使わないことがよくあります。しかし、1つか2つのページだけに関連するCSSスタイルがある場合、サイトの残りの部分にダウンロードしなければならないコードの量を減らし、必要のないユーザーがそのコードをダウンロードするのを避けるために、関連するページだけにそのCSSを読み込むべきです。

未使用のJavaScriptを削除する

上記と同じです。例えば価格表など、特定のページにのみ機能を提供するJavaScriptファイルがある場合、不必要に遅くなるため、ウェブサイトのすべてのページでこれらのファイルを読み込むべきではありません。

スピード指数

スピードインデックスとは、ページ上の可視アセットの読み込み速度から算出されるスコアです。スピードインデックスの計算方法については、こちらをご覧ください。このスコアには様々な要素が関係しているため、この指標は、どの要素を重点的に改善すべきかの指標というよりも、参考値として役立ちます。とはいえ、いくつかの最適化は他のものよりもこのスコアに大きな影響を与えるかもしれません。

インタラクティブ時間（TTI）

これは、ページの読み込みが完了し、訪問者がページと対話できるようになるまでの時間です。リンクをクリックできるなど、ユーザーが有意義な方法でコンテンツとインタラクションできなければ、単にコンテンツを見るだけでは十分ではありません。

総ブロック時間

これは、FCPとTTIの間の時間です。これは、ユーザーがサイトのコンテンツを見ることはできても、そのコンテンツと対話することができず、悪いユーザー・エクスペリエンスにつながる時間を表します。

サイズなし画像

最近のウェブサイトでは、画像（およびその他のメディア）が多くの部分を占めています。メディアがブラウザによってダウンロードされている間、ブラウザはデータを受信するまでそのサイズを知ることができません。そのため、常にheightそしてwidthタグをHTML内に記述することで、完全なデータがダウンロードされる前に、ブラウザが画像用のスペースをページに割り当てることができます。これらのタグを正しく使用した画像のHTMLコードは、次のようになります：

<img src="http://example.com/logo.jpg" height="200" width="400" />

上記の推奨は、画像の大きさが正確に分かっている場合には有効ですが、レスポンシブ画像にはあまり有効ではありません。レスポンシブ画像を作成するための一般的なデザインパターンは、インラインのheightとwidthの値を設定せずに、width属性が100%、height属性がautoに設定されたCSSを使用することです。この場合、ブラウザはそのサイズを確定する前に画像データをダウンロードする必要があります。一つの解決策は、画像の縦横比をブラウザに提供することで、ブラウザが確保すべき容量を計算できるようにすることです。幸運なことに、最近のブラウザのほとんどは、画像の初期寸法を設定すれば、アスペクト比を自動的に計算することができます。したがって、レスポンシブCSSを使う場合でも、まずHTMLで画像の実際の高さと幅を設定するようにしてください。コードは次のようになります：

HTML

<img src="http://example.com/logo.jpg" height="200" width="400" class="responsive-image"/>

CSS

.responsive-image {
    height: auto;
    width: 100%;
}

上記のコード例では、ブラウザはHTMLコード内の画像寸法から縦横比を計算し、CSSは利用可能なスペースを埋めるために画像のサイズを即座に変更します。これを組み合わせると、データのダウンロードが完了する前に画像に適切なスペースが割り当てられ、目に見えるレイアウトのずれが発生する可能性が低くなります。

静的アセットに効率的なキャッシュ・ポリシーを使用

訪問者があなたのサイトに何度も戻ってくることはよくあります。サイト上に頻繁に変更されないファイルがある場合は、キャッシュ・ポリシーを設定し、すでにコンピュータに保持しているアセットを再ダウンロードする必要がないようにする必要があります。

パッシブ・リスナーを使用してスクロール・パフォーマンスを向上

イベントリスナーはJavaScriptでよく使われるツールで、タッチイベントや マウスホイールイベントと一緒に使うことで、カスタムスクロール設定を作成することができます。このため、ブラウザは通常、これらのイベントにアタッチされたリスナーが実行を終了するまで待ってからスクロールを許可します。しかし、これらのイベントの使用は本質的にスクロールを遅らせる必要があることを意味しないので、無関係なコードが読み込まれる間、ユーザーは不必要に待つことになります。

幸運なことに、ブロッキングを必要としない方法でこれらのイベントのリスナーを使用する場合はpassiveタグを使用して、スクロールを許可する前に特定のリスナーを待つ必要がないことをブラウザに伝えます。その結果、コードは以下のようになります：

document.addEventListener('touchstart', onTouchStart, {passive: true});

このコードを分解すると、外側のdocument.addEventListener( );はイベントリスナーを設定し、最初の属性touchstartはイベントリスナーをtouchstartイベントにアタッチし、2番目の属性onTouchStartはイベントがトリガーされたときに実行するJavaScript関数の名前であり、3番目と最後の属性{passive: true}は、これがユーザーのスクロールを遅らせないパッシブイベントであることを示します。パッシブ・イベント・リスナーについての詳細や、ブラウザのサポートについては、こちらを参照してください。

アニメーション・コンテンツにビデオ・フォーマットを使用する

アニメーションGIFファイルはかなり大きいので、同じコンテンツをMPEG4などのビデオフォーマットで表示すると、ファイルサイズがずっと小さくなることがよくあります。FFmpegや Cloud Convertなどの無料ツールでGIFをMPEGに変換できます。また、WebMのような新しいファイル形式を使用することもできますが、これらは特にモバイルで広くサポートされていないため、フォールバックを提供する必要があります。どちらの方法を取るにしても、メディアファイルのサイズを小さくすればするほど、パフォーマンススコアへの影響は少なくなります。