MFI(CWV)とサイトレスポンスの最適化

SEO内部対策で最重要と言われる表示速度

Googleによる「MFI(モバイルファーストインデックス)」や「Speed Update」の発表からもわかるように、近年サイトスピードの改善が重要になってきています。

MFIとはPCで作られたコンテンツではなく、スマートフォン用に最適化されたページを優先的に検索エンジン上で評価する考え方です。

モバイル ファースト インデックス登録とは、Google のインデックス登録とランキングで、モバイル版のコンテンツを優先的に使用することです。これまで、ユーザーのクエリとページの関連性を評価するにあたっては、主にパソコン版のページのコンテンツがインデックスで使用されていました。今ではユーザーの大半がモバイル デバイスから Google 検索にアクセスしているので、今後、Googlebot は主としてスマートフォン エージェントでページのクロールとインデックス登録を行うようになります。

モバイル ファースト インデックス登録に関するおすすめの方法

Speed Updateとはモバイル検索において、レスポンス速度の早いサイトやページを優先的にランキング上位に組み込むことを発表したGoogleのアップデートのことです。

ページの読み込み速度をモバイル検索のランキング要素に使用します。

2018 年 7 月よりページの読み込み速度をモバイル検索のランキング要素として使用することを本日みなさんにお伝えしたいと思います。

ウェブマスター向け公式ブログ

「ページの読み込み速度をモバイル検索のランキング要素に使用します」と、明言していることから、逆にページの読み込み速度が遅い場合は、「モバイルの検索ランキングを落とす」といった意味で捉えることができます。

スマートフォンの出現により誰でも手軽にインターネットにアクセスできるようになりましたが、Wi-Fiや有線などで設置されているパソコン環境とは異なり、スマートフォンはまだまだ回線速度が不安定な環境にあります。

今後は5Gや6Gの出現により、そのインフラ整備後には、更なる回線の高速化が見込まれるとは思いますが、まだまだ実験的、且つ局所的な導入であったり、対応する端末が十分に出回っていないといった点から、普及に至るまで、もうしばらく時間がかかることでしょう。

表示速度が遅い事によるデメリット

では、具体的にページ速度が遅いと、ユーザにどれほどの悪影響が出るかを調べてみましょう。

以下のようなデータが「How Fast Should A Website Load & How To Speed It Up」に公開されています。

  1. In studies, Page Time Load goes from 1s to 3s – the probability of bounce increases 32%.
  2. In studies, Page Time Load goes from 1s to 5s – the probability of bounce increases 90%.
  3. In studies, Page Time Load goes from 1s to 6s – the probability of bounce increases 106%.
  4. In studies, Page Time Load goes from 1s to 10s – the probability of bounce increases 123%.
  5. 53% of mobile site visits are abandoned if pages take longer than 3 seconds to load.

要約するとページが表示されるまで1秒から3秒掛かってしまうと、ユーザーの直帰率は32%増加する。
更に6秒になると106%に増え10秒以上になると123%まで増加するといった検証データが報告されています。

上記はパソコンにおいての検証データですが、モバイルページに至っては表示に3秒以上掛かっただけで、53%ものユーザーが離脱してしまいます。

コンテンツの質を考える以前の問題

せっかく良質なコンテンツを公開していても、直帰率が高く、回遊のしづらい状態では、ユーザーに心地よくサイトを閲覧・利用してもらう事が出来ません。

コンテンツの内容を考慮する前に、まずは何よりもサイトの高速化を行うことが必須になっています。

高速化の種類

私は以下の3つにカテゴリを分けて高速化に努めるようにしています。

一言で高速化と言っても、様々な概念と改善箇所が存在するので、それぞれを正しく理解して、効率的にサイトのスピードアップを行いましょう。

サーバサイドの強化

サーバのスペックを上げてしまうことが一番手っ取り早く、理論的には簡単な手段となります。

CPUやメモリ、ハードディスク(SSD)といったハードウェア(周辺機器)が高速で大容量となれば、様々な動きを力技で高速に処理させることが可能です。

しかしながら、ハードウェアの強化だけでは根本的な解決にはなりません。
ドーピングには上限があり、力技だけではどうにもならないが後述のソフトウェアの部分となります。

ソフトウェアの改善点

普段はあまり気にすることがないと思いますが、すぐに確認するべきところはPHPのバージョンです。

PHPを導入していないようであれば、関係のない話題になりますが、昨今ほとんどのサイトでCMSが利用されています。
中でも普及率やその利便性からWordPressを導入されている方が多いのではないでしょうか。


参考: Kinsta

  • WordPress 5.3 PHP 5.6のベンチマーク結果:97.71リクエスト/秒
  • WordPress 5.3 PHP 7.0のベンチマーク結果:256.81リクエスト/秒
  • WordPress 5.3 PHP 7.1のベンチマーク結果:256.99リクエスト/秒
  • WordPress 5.3 PHP 7.2のベンチマーク結果:273.07リクエスト/秒
  • WordPress 5.3 PHP 7.3のベンチマーク結果:305.59リクエスト/秒
  • WordPress 5.3 PHP 7.4のベンチマーク結果:313.42リクエスト/秒

上記の引用はPHPの5.4, 7.0, 7.1, 7.2, 7.3, 7.4、それぞれのバージョンで特定のプロセスを1秒間に何回処理できるかといったベンチマークテストのデータです。

要約するとPHPバージョン5.6から7.x系は激的に処理速度が向上、それ以降もパフォーマンスは更に上がり、最大で3倍以上ものスピードアップが見込める検証結果となっています。

つまり、単純にPHPの最新版を利用するだけで、処理速度は大きく改善することがわかります。

サーバサイドにおけるその他の問題

その他、共有レンタルサーバによる負荷問題とシステム設計の根本的なボトルネックも考えられます。

共有サーバによる問題

一般的に普及しているホスティングサービスは、安価で手軽な共有プランというものです。
これは、1つのサーバに複数の契約者が入居してシェアするサービスになります。

サーバをシェアしているという事は、CPUやメモリ、回線が他者と共有されるので、お隣さんが負荷のかかるプログラムを動かしている場合は、ハードウェアのリソースがそちらに取られます。
また、同じくお隣のサイトに大量のアクセスがある場合は、回線帯域もそちらに占有されてしまう恐れがあるのです。

リソースキャップや帯域制限などが設けられている場合がほとんどですが、少なからずシェアハウスのようなサービスには変わりありませんので、常に理想とするような最高のパフォーマンスは出しづらくなります。

上記の様な問題は、コストは上がってしまいますが、専用サーバを利用することで解決することができるでしょう。

システム設計、またはデータベース設計がボトルネックになっている問題

オリジナルのシステムを導入しているサイト、またはWordPressなどのCMSを使うことにより、データベースを連動させているサイトは、処理速度低下と成り得るボトルネック箇所を定期的にメンテナンスすることが必要になります。

公開当初はスピーディに処理できていても、アクセス数の増加やデータベースの肥大によって大きくパフォーマンスを落とす事が多くあります。

特に日に日に処理が遅くなっていくといった場合は、前述のような問題が起きていることが多いので、負荷の掛かっているプログラムによる処理の見直し、データベースの再設計や蓄積されているデータの最適化を行うことをお勧めします。

コンテンツ量の最適化

当サイトの別記事で解説している「サーバ通信の設定による高速化」「AMP導入によるSEO効果」「WebPの話を交えたSEO対策の心構え」も併せて参考にしてもらえればと思います。

上記に列挙した記事は、今あるコンテンツをどのように圧縮、軽量化できるかといった施策や技術の話でしたが、そもそも無駄な文章を省き、設置するコンテンツ容量を始めから簡素にしてしまうのも効果的です。

闇雲に必要性の低い長文を毎日書き続けたり、見られもしない解像度で画像を設置することは好ましくありません。

Googleは「ユーザーの課題を素早く解決するコンテンツ」を提供することをサイト運営者に求めおり、可能な限りコンテンツは厳選して、ユーザが閲覧・理解しやすい情報を提供できるように心がけると良いでしょう。

コンテンツ描写の高速化

ユーザがランディングしてきたページにおいて、ファーストビューとして表示されるコンテンツをいち早く表示させることです。

ランディング直後、視覚的に何らかの形で描写が実現できていれば、継続してコンテンツの読み込まれているものの、既にユーザは情報に接触していることになります。

下部に設置しているコンテンツは継続して読み込ませつつ、ファーストビューを素早く表示させることに注力します。

全てのコンテンツの読み込みが完了しないと描写されない設計であったり、ファーストビューまでが異常に遅い作りであると、ユーザは視覚的な情報に接触できていない不安から、直帰や離脱をしてしまう可能性が高まるので、想定される流入キーワードを考慮し、ターゲットに見合う回答文、もしくはイメージ等を素早く置いて、ユーザに安心感を与えましょう。

目的の情報までスムーズにたどり着かない作りであると、コンテンツが存在しないに等しいとGoogleに判定されてしまいます。
実店舗でもあるような商品棚と同様に、ひと目で「どのような区画なのか」「お目当ての商品がすぐに見つかりそうか?」というような、お客さんの利便性をコンテンツ描写においても配慮できるように、適切な設計を行えるようにしましょう。

ユーザにはできる限りストレスフリーな状態を維持してもらい、結果としてランディングから閲覧、そして問題解決までストレスなく進んでもらえるような環境作りは、以下のCore Web Vitalsという指標を調査することで改善することが可能です。

Core Web Vitals

2020年5月28日、Googleは検索順位を決定付ける指標として「Core Web Vitals(コアウェブバイタル)」の導入を行い、既存シグナルと組み合わせて評価すると発表しました。

ユーザー エクスペリエンスの質の測定には、多くの側面があります。そのほとんどはサイトやコンテキストに固有のものですが、すべてのウェブ エクスペリエンスにとって重要な共通シグナル、つまり「Core Web Vitals」が存在します。このようなユーザー エクスペリエンスの核となるニーズには、読み込み時間、インタラクティブ性、ページ コンテンツの視覚的な安定性などが含まれ、これらを組み合わせたものが 2020 Core Web Vitals の土台になります。

Core Web Vitals

このCore Web Vitalsは、主にサイトスピードやユーザビリティに関する指標で、以下の3つで構成されています。

  • LCP (Largest Contentful Paint)
  • FID (First Input Delay)
  • CLS (Cumulative Layout Shift)

LCP

前述の「コンテンツ描写の高速化」で解説した該当ページにおけるファーストビューとなるコンテンツを読み込むまでの時間を示す指標です。いち早くユーザを情報に着地させる事により、安心感を与える重要な要素といえるでしょう。主にサーバの負荷や回線の質によって左右されます。

FID

ユーザがクリックやタップといったアクションを行えるようになるまでの時間になります。
現時点では、画面のスクロールやズームは該当しないようです。
つまりユーザがアクセス後のフリーズ状態から開放されるまでの時間を示す指標です。
具体的な改善策としては、スクリプトやアクションの読み込みといった行動開始の弊害となる不要な処理は極力省くといった設計が必要となります。

CLS

始めての訪問するサイトなどで、ページへランディング後、コンテンツが表示されるにつれて、既に画面上に出現していたレイアウトや描写がズレたり、移動してしまうといった現象を経験された事はないでしょうか。

これは主にサイズを指定せず画像やパーツが配置されている場合や、HTMLのレンダリング後にCSSを読み込んでいる場合、または外部サイトからスクリプトファイルといったサイズの想定できない情報を呼び出す場合の遅延処理において、描写のズレが起きてしまうといった現象です。

視覚的な安定性を示す指標で、サイトのレスポンススピードとは直接関係はないものの、ユーザビリティを考慮した設計を行うといった意味では、他と同じように重要な要素です。
対策としては、特定の場所に表示されるパーツが、どれほどのサイズかを予め把握しておき、描写の際のズレを最小限に留めるコーディングを行えればよいでしょう。

まとめ

Core Web Vitalsの発表により、今まで以上に使いやすく、サイトからの素早いレスポンスが求められるようになってきています。

ユーザに安心してコンテンツを見てもらうには、情報の中身も大切ではありますが、まずは環境を整えることから優先的に始めてみても良いのではないでしょうか。

当サイトの運営者。
主にSEO、SXO、Googleの考え方について、現場での経験をもとに、どのように対策を行えば良いかを具体的に解説できるよう努めています。詳しくはプロフィールをご覧ください。

Set your Author Custom HTML Tab Content on your Profile page

記事が気に入ったらシェアをお願いします!

, , , , , ,