爆速サイトの作り方

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

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

モバイル ファースト インデックスを開始します

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

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

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

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

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

今後は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を導入されている方が多いのではないでしょうか。


Img src: 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系は激的に処理速度が向上し、それ以降も緩やかながら、パフォーマンスが上がっていく検証結果となっています。

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

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

主に共有サーバによる問題とシステムの設計による問題になります。

共有サーバによる問題

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

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

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

そういった場合は、多少値は張るものの専用サーバを利用することで問題解決することができるでしょう。

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

オリジナルのシステムを導入しているサイト、またはWPなどのCMSを導入していてデータベースが連動しているサイトは、処理速度低下となっているボトルネックを定期的に検証することが非常に重要です。

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

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

通信速度の最適化

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

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

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

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

コンテンツ描写の高速化

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

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

ファーストビューを見ている間に、下部に展開しているコンテンツを読み込ませたり、遅延ロードを行うなどして、まずはファーストビューの描写を最速で出すことに注力することで、ユーザビリティの高いコンテンツとなる。
ユーザは目的の情報に接触できていない不安から、直帰や離脱が行われる可能性が高いので、想定される流入キーワードを考慮し、ターゲットに見合う回答文、もしくはイメージ等を素早く置いて、ユーザに安心感を与えよう。

目的の情報まで簡単にたどり着かない作りである場合は、コンテンツが存在しないに等しい。
実店舗にあるような商品棚と同様に、ランディングしたページにおいて「どのような区画なのか」「お目当ての商品はすぐに見つかる場所にありそうか」というお客さんの利便性をコンテンツ描写においても配慮できるように、適切な設計を行えるようにしましょう。

ユーザにはできる限りストレスフリーな状態を維持してもらい、結果としてランディングから閲覧、問題解決までスムーズに進んでもらえるような環境作りは、ファーストビューの高速化で実現させることが可能なのである。

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の考え方について、現場での経験をもとに、どのように対策を行えば良いかを具体的に解説できるよう努めています。詳しくはプロフィールをご覧ください。

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

, , , , , ,