ページ表示速度を99点に改善するとSEOで上位にくるのか?『PageSpeed Insights』で点数を最適化した8つの施策とは。【検証】

ページ表示速度を99点に改善するとSEOで上位にくるのか?『PageSpeed Insights』で点数を最適化した8つの施策とは。【検証】 アフィリエイト

webサイトの表示スピードを上げる、いや、上げまくるとSEO的な効果は果たしてあるのだろうか・・・

一般的にページの表示速度とSEO(検索結果の上位表示)とは相関関係があると言われております。

確かに自分も調べたいキーワードをググった時にタイトルを見て、「おっしゃー、このページ見たろー」って思ってタイトルをクリックしても、なかなかページが表示されず画面が真っ白のままだと、「もーえーわ。。。」って戻っちゃいますからね。
いちユーザーとして考えると確かにページ表示速度は早い方がユーザー体験が良いワケで。

でもって、googleさんは『Googleが掲げる10の事実』という会社の価値観?を明示しているページで1番目に以下のような項目をあげています。

■ユーザーに焦点を絞れば、他のものはみな後からついてくる。
https://www.google.com/about/philosophy.html?hl=ja

こうしたことを考えると、ページ速度は早いほうがユーザーにとっては良いのは誰が見ても明らかですので、webサイトの表示速度を改善することはgoogle的にもgoodなハズです。
もちろんそのことが100%の確立で上位表示につながるかは世界中の誰もが分からないのかもしれませんが。。。

ということで、今回は僕が携わっているサイトで実際に実験してみたいと思います。
検証に使用するサイトはコチラ。

【京都】放課後等デイサービスJiria(じりあ) 【運動・ソーシャルスキル】
Jiria(じりあ)は土・祝日も対応している京都市の放課後等デイサービスです。運動・SSTを中心に楽しく「生きるチカラ」を一緒に育みませんか?

ページ表示スピードを測定するツールはgoogle様が提供している『PageSpeed Insights』を使用したいと思います。

PageSpeed Insights

では、参りましょう!!w

ますは現在の表示速度を測定します

問題解決のファーストステップは現状把握ですよね。
なので、まずは現在の表示速度を計測してみます。

では、いきます!

ドキ、ドキ、ドキ、ドキ。



ジャーん!

ん?

おっと、どうやら見間違えたみたいです。
ちょっとコーヒーを一口飲んで落ち着いてもう一度見てみましょう。



うん、見間違いではないですね。

どうやら『PageSpeed Insights』の測定結果はめちゃくちゃ良くないようです。
体感速度的に「なんとなくこんな感じかな~?」というのはあったのですが、全盛期の野茂ばりのフォークの下落幅にちょっとびっくりしました。

まぁ、逆に考えれば改善すれば大幅な効果が見込めるかもしれませんので、一つ一つページ表示速度を改善する施策をしていきます。

ちなみに、パソコン版の数値は以下の通り。

検証サイトの前提

検証サイトの前提条件というか、簡単な情報は以下の通りです。

  • 本サイトはwordpressで作成されています。
  • 『Lite speed cache』を使用しています。(設定項目などはまた機会があればご紹介させていただければと思います。)
  • サーバーは『mixhost』です。

余談ですが、『mixhost』は個人的に非常に良いサーバーで速度も早い部類に入るかと思います。
サービス開始直後はサーバーダウンもしていましたが、今では特に不満もなく使用できています。

アクセス数に応じてグレードが簡単に変更できたり、『Lite speed cache』という強力かつ高性能なwordpressのプラグインを使用できるので速度を追い求めたいサイト運営者にはもってこいのサーバーかもです。

10日間無料でお試しできるので、ご興味のある方は無料期間だけでもお試ししてみてはいかがでしょうか?
月額880円からの高性能クラウドレンタルサーバー

さて、話をもとに戻していきましょう!

ページ表示速度を99点にするために『PageSpeed Insights』で改善した項目

それでは、「ここを改善すれば点数あがるぜ!」ってgoogle先生が教えてくれた各項目を一つづつ、潰していくようにしよう。

画像サイズを圧縮したり、スマホ最適化したり、webPにしたり・・・

まずはtop画面のスライダーに使用している画像自体を圧縮して軽くします。
加えて、「pictureタグ」を使い、スマートフォンの場合はより軽い画像を配信するように「imgタグ」を修正します。

ついでに「次世代フォーマットでの画像の配信」に対応させるため、webPでの配信に変更します。

画像を圧縮するのに使用したツール

単純に画像を圧縮するwebサービスを使って画像を軽くします。
今回使用したのは、「Squoosh」というwebサービス。

簡単に画像を圧縮できます。

Squoosh
Compress and compare images with different codecs, right in your browser

jQueryやdisplay=”none”を使わずデバイスの画面によって画像を切替える方法

「pictureタグ」を使ってデバイスの画面によって画像を切り替えます。
スマホとかで見た場合、より軽い画像が配信されるようにするイメージです。

<picture>
  	<source media="(max-width: 600px)" srcset="xxxx_sp-top.jpg">
  	<source media="(min-width: 601px)" srcset="hxxxx_pc-top.jpg">
 	<img src="hhxxxx_pc-top.jpg">
</picture>

画像をwebPにする変換ツール

ついでに次世代画像フォーマットの「webP」にも対応させてよりサイトの高速化を目指すことにします。
まずは画像フォーマットをwebpに変換します。

以下のツールでjpgやpngをwebPに変更できます。

WEBP変換ツール (jpg、pngとwebpを相互変換)
WEBPコンバーターは、お手持ちのJPEGやPNG画像をWEBPに変換するウェブサービスです。現在、Chromeのみサポートしています。

そして、上述のコードに以下のように「type属性」を加えてあげます。

<picture>
  	<source type="image/webp" media="(max-width: 600px)" srcset="xxxx_sp-top.webp">
  	<source type="image/webp" media="(min-width: 601px)" srcset="hxxxx_pc-top.webp">
 	<img src="hhxxxx_pc-top.jpg">
</picture>

これにてwebPへの対応もできましたのでさらなる高速化が期待できる・・・・ハズ!

レタリングを妨げるソースの除外

画像の最適化が一段落しましたので、次はレタリングを妨げているソースをなんとかします。
実際にどのソースがレタリングを妨げているのかはサイトによってマチマチだと思いますので、『PageSpeed Insights』の改善できる項目でご確認ください。

実験サイトでは、

  • jquery
  • googleマップのapiを使用するためのjs
  • facebookのapiを使用するためのjs
  • fontawesomeのcss

がロードにかなりの時間を費やしているようでした。

ということで、それぞれ対応してきましょう。(できるだけ後の方に読み込ますようにさせます。)

とはいっても、サイトのギミックやデザインによっては、各ソースの読み込み順番を変更するとサイトのデザインなどが崩れてしまう場合がありますので、その場合はサイト構造を見直すか、もしくは「レタリングを妨げるソースの除外」の改善は諦めるかでしょうか。

個人的にはサイト構造を見直すまでする必要はコストパフォーマンス的に合わないと思いますので、「PageSpeed Insightsの数値を改善するのが趣味なんだぁぁぁ!」という人以外はこの項目は諦めてしまってもよいかと思います。
(ただし、この項目は改善すると劇的にPageSpeed Insightsの数値が向上するかと思います。)

jqueryを下の方(footer)で読み込ませる

まずはjqueryをfooterで読み込ませるようにします。
以下のコードを「functions.php」に記述します。

add_action('init', 'my_init');
function my_init() {
	if ( !is_admin() ) { // サイトのadmin(管理者)でなければ{}内を実行
	wp_deregister_script('jquery');
    wp_deregister_script('jquery-core');
    wp_deregister_script('jquery-migrate');

    wp_register_script('jquery', false, array('jquery-core', 'jquery-migrate'), '1.12.4', true);
    wp_enqueue_script('jquery');

    wp_enqueue_script('jquery-core', '//ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js', array(), '1.12.4', true);
    wp_enqueue_script('jquery-migrate', '//cdnjs.cloudflare.com/ajax/libs/jquery-migrate/1.4.1/jquery-migrate.min.js', array(), '1.4.1', true);
	}
}

これでフッター部分でjqueryが読み込まれるようになったハズです。

「googleマップのapiを使用するためのjs」をgoogleマップを使用するページだけで読み込ませる。

googleマップのapiを使用するためのjsとはこんなヤツです。

<script src="http://maps.google.com/maps/api/js?key=xxx&language=ja"></script>
//xxxにapiキーが入ります

で、本サイトの場合は手抜き汗でheader.phpで共通で読み込まれていましたので、googleマップが必要なページのみで読み込ませるようにしました。

<?php if(is_page("個別記事のタイトルとかID")); ?>
<script src="http://maps.google.com/maps/api/js?key=xxx&language=ja"></script>
<?php endif; ?>

いやいや、googleマップが表示されるページの速度を改善したいんじゃー!って場合は「header」とかに書くのではなく、マップが呼び出される直前にコードを挿入するといくぶんか早くなるかと思います。

「facebookのapiを使用するためのjs」をfacebookの埋め込みを使用するページだけで読み込ませる。

これも上述したgoogleマップの場合と同じですね。
当サイトの場合はtopページでのみfacebookの埋め込みを利用していなかったので、以下のようにTopページ以外で「facebookのapiを使用するためのjs」を読み込むことにしました。

<?php if(!is_home()): ?>
//facebookのJavaScript SDKをここに記述
<?php endif; ?>

これでtopページではJavaScript SDKのコードは読み込まれなくなります。

「fontawesomeのcss」をDOMの構築が終わった後で読み込ます

fontawesomeのcssとはこんなヤツです。

<link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.8.2/css/all.css">

「fontawesome」は上記のコードを一行読み込ませればいろいろなアイコンが簡単に使えるので便利なのですが、headeに記述して順番に読み込ませると『PageSpeed Insights』的には数値を妨げる原因になるようです。
ということで、このcssをDOMの構築が終わったタイミングでhead内に挿入するようにjavascriptで制御します。

<script type="text/javascript">
var mycss=function(){// mycss関数を定義。{}内の処理を実行。
  var l=document.createElement("link");// link要素をlに代入。
  l.rel="stylesheet";// lにrel="stylesheet"属性を付与。
  l.href="https://use.fontawesome.com/releases/v5.8.2/css/all.css";// lにhref属性を付与。
  var s=document.getElementsByTagName("link")[0];// HTML内の最初のlink要素名をsへ代入
  s.parentNode.insertBefore(l,s);// sの直前にlを出力
};
window.addEventListener("DOMContentLoaded",mycss);// DOMの構築が終わったらmycss関数を実行
</script>

参考サイト

jQueryとCSSを最後に読み込ませてサイトの表示速度を上げる方法
レンダリングをブロックしているリソースをフッターへ移し、サイトの表示速度をUPさせます。WordPressを使っている様々なサイトに応用できますよ。

これで、「レタリングを妨げるソースの除外」の対策は終了です。

使用していないCSSの削除

『PageSpeed Insights』の改善できる項目にピックアップされていたcssを削除しました。
これだけですw

cssの削除はレイアウトが崩れる場合もあるかと思いますので、実行する時は慎重に行ってみてください。

モバイル版では192%のスピード改善に成功!パソコン版では満点に近い99点に!

ということで、各項目を改善し、今一度『PageSpeed Insights』の実測に挑みたいと思います。

どうや。。。







ん?
おおーー!

ちなみにPC版の数値は99。

おおー!!ちょっとだけ頑張ったかいがありましたぁ!

なんと、モバイル版は、【48から92】に数値がUPしました!
パソコン版は【86から99】に!

モバイル版before

モバイル版after

パソコン版before

パソコン版after

ということで、『PageSpeed Insights』の数値改善についての結論。

  • そもそもの画像を圧縮して軽くする
  • デバイス(画面サイズ判定)によって読み込ませる画像を変える
  • webPを使う
  • jqueryをフッターの方で読み込ます
  • googleマップのapiを使用するためのjsを最適なページ・箇所で読み込ませる
  • facebookのapiを使用するためのjsを最適なページで読み込ませる
  • fontawesomeのcssをDOMの構築が終わったタイミングでhead内に挿入する
  • 使用していないCSSを削除する

この8つの施策を行った結果、上述したようにモバイル版は、【48から92】に、パソコン版は【86から99】にページ速度が改善しました。

で、ここからが本番です。
果たしてページ速度が改善した結果SEO的な効果はあるのか?

ページ表示速度を大幅に改善しても、それだけではSEOの効果はない!?

えーっとですね、大変残念な結果となってしまったのですが、いくつか狙っているキーワードで数週間時間をおいて検証してみたところ順位にまったく影響がありませんでした汗
というか、なんなら順位が下がってしまっているキーワードもいくつかありました涙

みなさんもご周知の通り、かなり多くのサイトが影響を受けたgoogleのコアアップデートが2019年3月中旬くらいにあり、改善したのが4月とかなので検証の時期がそもそも良くなかったのかもしれません。
しかし、結果としてページ速度を劇的に改善してもSEO的な効果は当サイトではまったく得れませんでした。

めでたし、めでたし。。。。
じゃなぁぁぁい!!

いやいや、改善に費やした時間!!
といいたいところですが、ページ表示速度が早くなったのは事実ですし、それはユーザー体験的にはgoodなハズです。
体感的にも早くなった気はします。

ということで、結論としては検証サイトではページ速度を『PageSpeed Insights』で99にしてもなんら上位表示には関係ありませんでしたと。
ただ、ユーザーにとっては快適にサイトを閲覧できるようになりましたと。

めでたし、めでたし。

引き続き色々なサイトでページ表示速度とSEOの関係は検証していきたいと思います!

コメント