Blue Leaf

PageSpeed Insightsで100点を出してみた

作成日:

ブログの表示が遅い・・・。ブラウザが読み込みはしているけど、白い画面のまま何も表示されない・・・。モバイルファーストと叫ばれているので気をつけてはいるけど、1ページの容量が数MBと凄く大きくなってしまう・・・。

ある時に、自分のブログを外出先からスマホで見てみようと思ったら、表示されるまでに時間がかかり遅い事が分かったので、勉強も兼ねてブログの高速化に取り組んでみました。

高速化といっても何から手をつけていいか分からないので、以下の2つのサイトを指標としました。このページでは、指標とした「PageSpeed Insights」の指摘事項に合わせて取り組んだ内容を説明しています。

高速化の指標とした2つのサイト

「PageSpeed Insights」と「GTmetrix」の2つのサイトを指標としました。

  • PageSpeed Insightsは、Googleの運営で「ウェブページのコンテンツを解析し、ページの読み込み時間を短くするための方法を提案してくれる」サイトです。
    Google PageSpeed Insights

  • GTmetrixも「ウェブページのコンテンツを解析し、パフォーマンスを改善する方法を提案してくれる」サイトです。
    GTmetrix – Website Speed and Performance Optimization

PageSpeed Insightsでの指摘事項を1つ1つクリアしながら、GTmetrixの「Waterfall」「Page Load Time」「Total Page Size」などをチェックしながら高速化を進めました。

ブラウザでも「Waterfall」などの確認はできますが、GTmetrixのほうが視認性がよく作業がしやすかったです。

まずは結果

高速化に取り組んだ後のこのページの結果は、

PageSpeed Insightsの結果でモバイルが100点の画面

PageSpeed Insightsの結果でPCが100点の画面

PageSpeed Insightsが、モバイルとPCで100点。

GTmetrixの結果の画面

GTmetrixが、PageSpeedとYSlowでA判定。(画像をもう少し圧縮できるはず・画像の配信にCDNを利用してみては・cssの細かい指摘、という3つの努力目標が残っています)。

後で書きますが、「アクセス解析のGooge Analytics」と「広告のAdSense」を利用していると、PageSpeed Insightsで100点が出なかったので、一時的に2つとも外した状態が上記のスクリーンショットの点数です。通常はAnalyticsとAdSenseを利用しているので、90点前後の表示が出ます。

PageSpeed Insightsのチェック事項

PageSpeed Insightsでチェック・指摘されるのは以下の8項目です。この項目をチェックし点数化されます。

  1. HTML、CSS、JavaScriptを縮小する
  2. サーバーの応答時間を短縮する
  3. 圧縮を有効にする
  4. ブラウザのキャッシュを活用する
  5. 画像を最適化する
  6. リンク先ページのリダイレクトを使用しない
  7. スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する
  8. 表示可能コンテンツの優先順位を決定する

私は勉強も兼ねて1項目ずつ順番に作業をし、GTmetrixやブラウザで「通信量」や「ヘッダー情報」などを確認しながら作業を進めました。が、とてもとても面倒です・・・。上の項目の意味がほとんど分からないところから勉強をしながら進めたので、1ヶ月ほどの時間がかかりました・・・。

何はともあれ、上記の8項目に沿って以下に説明します。

CSS、HTML、JavaScriptを縮小・圧縮(Minify)する

この項目は、HTML、CSS、JavaScriptの余分なスペース、改行、インデントを取り除くことができますと指摘してくれます。作業する内容はシンプルですが、ハマりやすいです。そして、高速化の効果は感じにくい項目です。ファイル名は教えてくれますが、ピンポイントでどの部分かは指摘してくれません。

Googleなどで検索をする時は、Minify(縮小・圧縮)で検索をしてみてください。

Minify(圧縮)のサンプル

Minify化の実施前後のサンプルを記載します。

  • html Minify前後
#html Minify前

<p>圧縮テスト</p>
<p>htmlのMinify</p>
<p>効果は実感できない・・・</p>
#html Minify後

<p>圧縮テスト</p><p>htmlのMinify</p><p>効果は実感できない・・・</p>
  • css Minify前後
#css Minify前

p {
    font-size: 16px;
    line-height: 28px;
    margin-bottom: 28px;
    color: #333;
}
#css Minify後

p{font-size:16px;line-height:28px;margin-bottom:28px;color:#333;}
  • JavaScript Minify前後
#JavaScript Minify前

<script>
    document.write('効果は薄い・・・');
</script>
#JavaScript Minify後

<script>document.write('効果は薄い・・・');</script>

Minify化する事で、改行やスペースが取り除かれているのが分かっていただけるかと思います。

少しでもデータのサイズを小さくしたいので、コンピュータにとっては人の目で見て判読しやすい改行やスペースは必要ないので削りましょうという事みたいです。

注意1:WordPressを利用している場合

使用しているテーマファイル・プラグインによって対応する方法が変わってくると思います。

HTML、CSS、JavaScriptを縮小(圧縮)してくれるプラグインもありますが、必要なインデントや空白が削れてしまったりするのでHTMLとJavaScriptの圧縮は何もしないほうがいいと個人的に感じました。CSSについては、自分で管理している部分については縮小できると思います。

.phpファイルの内容を圧縮する事で、排出されるhtmlのタグを一部圧縮する事もできますが、ほとんどデータのサイズが変わらないのでオススメしません。

注意2:外部のCSS・JavaScriptについて

外部のCSS・JavaScriptを利用していて下記のように読み込ませている時は、

<link rel="stylesheet" href="http://外部のドメイン.com/css/style.css">

<script type="text/javascript" src="http://外部のドメイン.com/js/javascript.js"></script>

などなど。

PageSpeed Insightsに指摘をされても、自分で管理しているわけではないので何もできないです。指摘を参考程度に受け止めておけばいいと思います。

縮小する方法

実際に縮小する方法ですが、「CSS Minify」「html Minify」「JavaScript Minify」という風に、Minify(圧縮)と合わせて検索すると、色々な方法が出てきますので調べて見てください。

参考程度にいくつかの方法を下に記載します。

MinifyしてくれるWebサイトを利用

一番手っ取り早い方法です。cssなどのコードを貼り付ければ圧縮を実行してくれます。

MinifyしてくれるWebサイトは検索するとサイトが山のように出てきます。

エディタでMinify

これが一番利用している人が多いと思います。利用しているエディタのプラグインなどで圧縮する方法です。

人気のあるエディタ、

  • Atom
  • Brackets
  • Sublime Text
  • Visual Studio Code

どれでもMinify化のプラグインがあります。

WordPressのプラグイン

WordPressのプラグインなどでMinify化。上のほうに書きましたが、コレが安心して使えるというプラグインが見つけられなかったです。プラグインは使わずに、自分で管理しているCSSだけをwebサイトやエディタでMinify化しておくだけで良いと思います。

手で縮小

圧縮ではなく、自分の手でコードを見直して縮小する方法です。Minify化よりもサイズが減ります。

html

  • 必要ない divspan などのタグを削る・まとめる。
  • style の指定で、必要ない id名・class名 などを削る。

必要ないコードは削除する・書かないという事に気をつける。

cssとJavaScript

  • PageSpeed Insightに書かれているのですが、セレクタ・変数の名称を短いものに見直す。
.site-top-name-title{
	#css
}
↓
.sitename{
	#css
}
  • cssで、border・padding・marginなど、一行でかけるところがないか見直す。
.style-css{
	padding-top: 10px;
	padding-left: 20px;
	border-bottom: solid;
	border-bottom-color: #ccc;
	border-width: 1px;
}
↓
.style-css{
	padding: 10px 0 0 20px;
	border-bottom: solid #ccc 1px;
}
  • JavaScriptは充分枯れたコードの印象がありますが、常に最新の技術を追いかける事でコードの最適化がまだまだ進められると思います。

特にcssがグチャグチャになりやすいと思います、継承しているのに二重に書いていたり。過去のデザインを削除していなかったり・・・。私です・・・、後でいいやと思っていたら忘れてしまい、気がついたらこの部分は?となっています。

ブラウザのプラグインで、サイト全体をチェックし使われていないセレクタなどを教えてくれるツールもありますので、チェックしてみてください。

PageSpeed Insightsでダウンロード

ダウンロードのリンク画面

PageSpeed Insightsで分析したサイトの cssjavascript を最適化してくれるので、ダウンロードすることもできます。

Minify(圧縮)のポイント

  • 実施前にバックアップを必ずとる
  • Minify化後、ブラウザで描画した時に表示が壊れていないか確認する。Minifyでコードが壊れてしまう時は、そのプラグインなどに固執せず別なモノを試す。たくさんあるので1つに固執せず色々試したほうが良いです。JavaScriptは壊れやすいと思います。

最後に。Minifyの前後でデータサイズをチェックすると分かりやすいですが、サイズはほとんど変わらないです。組み込み用途などで、容量の小さいチップなどに保存する必要があったり。汎用的なインターネット回線でなく、とても遅い通信環境であればMinifyの効果を実感できると思いますが、う〜ん・・・。という感覚です。

鬼の首をとったような書き方をしているサイトも見かけた事があるので・・・、この世界は難しいですね。

個人的にはMinify化は、過去の遺産だと思っています。PageSpeed Insightsの指摘は、参考程度に受け止めておけば良いと思います。

サーバーの応答時間を短縮する

この項目は、サーバーの応答時間が200ミリ秒以上であると指摘されるようです。

最初、サーバーの応答時間?となりましたが、サイトにアクセスをした時に、サーバーからデータの1Byte目が届いたタイミングを応答時間というようです。ページ全体が表示されるタイミングとかではないです。

サーバーの応答時間を調べる方法、高速化する方法を説明します。

ウォーターホールをチェック

応答時間を調べるのに簡単な方法は、ブラウザのウォーターホールをチェックする事です。下の画像がウォーターホールになります。

Gtmetrixのウォーターホール図

このページ、https://blue-leaf81.net/archives/1014/ にアクセスした時のモノです。

ウォーターホールを確認することで、ページが表示されるまでの詳細な流れを確認することができまます。

ウォーターホールは各ブラウザに標準で搭載されていて、メニューから簡単に表示することができます。

  • Chrome
    メニュー → 表示 → 開発/管理 → デベロッパーツール →Network
  • Firefix
    メニュー → ツール → ウェブ開発 → ネットワーク
  • Safari
    メニュー → 開発 → Webインスペクタを表示 → ネットワーク

サーバーの応答時間を調べるには、ウォーターホールの一番上にある html の部分の横棒にマウスカーソルを当てると時間が確認できます。

Safariのウォーターフォール図

これはブラウザのSafariの画像ですが、

  1. 遅延 7.51ms
  2. DNS 12ms
  3. 接続(保護SSL) 112ms
  4. リクエスト 35.27ms

リクエストの次が、「レスポンス」となりサーバーからデータの1Byte目が送られ始めるタイミングになります。なので1~4項を足して、サーバーの応答時間は「166.78ms」となります。アクセスを開始してから、htmlファイルの受信完了までは「192.98ms」です。

ブラウザだとタイミングが早すぎて見にくいという場合は、GTmetrixでも確認できます。

GTmetrixのウォータホールで、赤い矢印で図解

上はGtmetrixの画面ですが、

  1. Connecting 217ms
  2. Waiting 102ms

Waitingの次が「Receiving」なので、1~2項を足してサーバーの応答時間は「319ms」となります。Googleの閾値「200ms以上」ですが、GTmetrixは海外のサーバーからのアクセスなので遅くなります。

高速化の方法

サーバーの応答時間の高速化の方法ですが、状況によって色々な方法が考えられるので参考程度に書きます。

手打ちhtml、静的サイトジェネレータなど

サーバーにhtmlファイルを置くことでサイトを運営している場合は、何もする必要がないと思います。というよりも、PageSpeed Insightsでこの項目は指摘されないと思います。別なアクセスとタイミングがぶつかったとかだと指摘されるかもしれませんが・・・。後は海外のレンタルサーバーを使用しているとか・・・。

いずれにしても、国内のレンタルサーバーでhtmlでのサイト運用なら、大規模なアクセスでもなければサーバーの応答時間は気にする必要はないと思います。効果があるか分かりませんが、SSDを採用しているレンタルサーバーにしたら多少の高速化になるかもしれません。

リクエストを受け付けて、用意されているファイルを返しているだけなので、あまり気にしない方が良いと思います。

WordPress

WordPressは、色々と検討しないといけないことが多いです。まずは、下の画像です。

ウォータホールで、リクエスト時間に赤い枠線

これは、テスト用にMacの中にWordpressを真っさらな状態で構築しアクセスした時の時間です。

リクエストが「190.83ms」となっているのですが、この時間の大部分がWordPressがページを生成している時間で、ブラウザがWebサーバからのレスポンスを待っている状態です。次の「レスポンス」でサーバーからデータの受診が始まります。

WordPressはアクセスがある毎に、PHPでデータベースへアクセスし、記事データなどを取得しHTMLファイルを生成しています。このHTMLファイルをを生成する時間をいかに短くするかがポイントになってきます。

私が1年半ほど前に借りた安いレンタルサーバーは、このページ生成が1~2秒ほどかかっていました・・・。

色々な解決方法があるかと思いますが、

  • PHP7を使用するようにする。
  • ページのキャッシュを活用するようにする。
  • プラグインを見直し、必要ないモノを停止・削除する
  • SSDを使用しているサーバにする。
  • Wordpressが速いと謳っているサーバーを使う。

などなどがパッと思いつきます。簡単にですが、画像を使って説明します。

PHP7を使用するようにする(WordPress)

PHP7についてです。そもそもWordPressにおけるPHPの役割は、SQLデータベースと連携し動的にHTMLを生成する役割を担っています。

そのPHPが、Ver.7になったのが2015年11月。Ver.7の前はVer.5.6になります。実行速度がアップした!というのが、インターネット上で話題になっていました。

今から1年ほど前にリリースされたので、すでに多くのレンタルサーバーで使用できると思うし、WordPressも対応しています。(更新されていない、古いプラグインはちょっと怪しいです・・・)

比較した画像が下記です。

PHP7のウォータホールで、リクエスト時間に赤い枠線

PHP5.6のウォータホールで、短くなったリクエスト時間に赤い枠線

上の画像がPHP7、下の画像がPHP5.6です。

「リクエスト」の時間が、

  • PHP 7 : 190.83ms
  • PHP 5.6 : 261.46ms

となり、PHP7のほうが速いことが分かります。なので、PHP7を使用するようにしよう!ということです。

ページのキャッシュを活用するようにする(WordPress)

WordPressはアクセスがある度に、PHPが実行されデータベースから記事データなどを取得しHTMLを生成します。ページキャッシュは、一度作成したHTMLを保持し、同じページ(URL)へアクセスがあった時に、保持したデータを払い出すようにすることです。もの凄く早くなります。

参考として、WordPressのプラグイン「WP Super Cache」でページキャッシュを利用した時の画像が下記です。

ページキャッシュ無しのウォーターフォール

ページキャッシュ有りウォーターフォール

上の画像が1度目のアクセスで、下の画像は2回目のアクセスです。ブラウザのキャッシュは削除してから2回目のアクセスをしています。

  • 1回目:234.73ms
  • 2回目: 21.23ms

1度目にアクセした時のHTMLがキャッシュされ、2回目のアクセスで劇的に速くなっているのが分かります。

「WP Super Cache」でキャッシュが保持される時間は、標準で30分です。(注意点:ページキャッシュで早くなるのは2回目のアクセスからです。1回目は速くなりません。)

キャッシュされた2回目からのアクセスが早くなるので、あまりアクセスのないページをPageSpeed Insightsで調べるときは、2回実行する必要があります。(SEOという観点にすると、Google Botがアクセスしに来たタイミングでキャッシュがあれば早いページと評価されるかもしれませんが、ほとんどアクセスのないページだと期待はずれに終わります。ただ、Google Botのためにサイトを運営しているわけではないので気にしなくてもいいと思います。)

キャッシュの設定・調整が難しいですが、効果は分かりやすいので、可能であればページキャッシュを使用するようにしよう!ということです。

プラグインを見直し、必要ないモノを停止・削除する(WordPress)

WordPressがHTMLを生成する時に、PHPがプラグインの中も1回1回解析・処理をします。使用しているプラグインが多いと、それだけ処理の時間もかかるので、必要ないと感じているプラグインは停止・セキュリティの面も考えて削除するようにしましょう!ということです。

SSDを使用しているサーバーにする(WordPress)

これは簡単にイメージできるかと思います、HDDよりもSSDのほうが圧倒的に全てが早いです。

WordPressが速いと謳っているサーバーを使う

このサイトはサーバーを6回変えているのですが、どのレンタルサーバーでもWordPressは使用できると思います。そんな中でも、WordPressが速い謳っているサーバーは、WordPress用にサーバーがチューンナップされています。

契約したことがある中でオススメは、下記の「wpx(ダブリューピーエックス)サーバー」です。

レンタルサーバーとクラウドの違いは、分かりやすいのはWorPressをインストールできる数です。私は違いをよく確認せずにレンタルサーバーを契約してしまったのですが、WordPressを一つ運用するなら「クラウド」で充分だと思います。

wpxオススメの理由は、

『VPS / nginx リバースプロキシで快適にしたいけど、構築面倒だし、保守もしんどいし。』なんて方には、ぜひ一度 wpXクラウドを使ってみていただきたいと思います。

wpXクラウド、wpXレンタルサーバーの違い」より引用

この引用の文そのままですが、nginxのリバースプロキシによるキャッシュ処理を簡単に利用できるからです。

リバースプロキシによるキャッシュ処理とは、WordPressのプラグインではなく、フロント側のWebサーバー(Nginx)でキャッシュを保持・配信してくれことです。Nginx・リバースプロキシで検索すると色々情報が出てきます。これがレンタルサーバーで簡単に使えるのは面白いです。WordPressのプラグインでキャッシュの処理は、知識も必要だし、調整が面倒です・・・。

あ、wpXだと、WordPressのキャッシュプラグインは使えないと思うので気をつけてください。私が試した限りでは、Apacheの設定(.htaccess)が干渉してしまい、WordPressがエラーを吐いてWordPressの管理画面にログインもできなくなりました。

WordPressとCGIを使いたいとか、WordPressと静的サイトを組み合わせたいとか、WordPressのプラグインでキャッシュ処理をしたいとかだと、

xserverが契約した中ではオススメです。オススメの理由は、老舗で情報が豊富。可もなく不可もなく、レンタルサーバーとして普通に使えたので。速度も速いです。

自分でサーバーを構築したいならVPSです。webサーバーも好きに選べるし、好きなCMSを使えます。オススメは、このサイトを運用している「Conoha」です。

オススメの理由は、「時間単位で料金が発生する」のでテスト用に2日だけVPSを新規に動かしてお金を払うということができる。WordPressなどが設定されたテンプレートもあり気軽に利用できる。公式で使い方などの情報をきちんと配信しているからです。

レンタルサーバーに関しては、比較されているサイトがたくさんあるので検索してみてください。

何はともあれ、WordPressはページの生成に時間がかかるので、少しでも速いサーバーを使った方が良いということです。

応答時間のポイント

サーバーの負荷状況によっても結果が大きく変わってくると思います。他のアクセスとぶつかってしまったりすと、ん?となるような時間が表示されたりもします。おかしいと感じたら、何度かチェックを。

圧縮を有効にする

この項目は、圧縮が有効になっていない時に指摘される項目です。

圧縮とは

パソコンを使用していると目にする、.zip などと同じです。ApacheなどのWebサーバでGZIP圧縮が使用できるので、htmlやcssを圧縮して配信してあげてください。

htmlのgzip圧縮のサイズを比較

cssのgzip圧縮のサイズを比較

上の画像は、htmlとcssを圧縮した時のサンプルです。拡張子に .gz が付き、ファイルサイズが減っているのが分かっていただけると思います。

GZIP圧縮の設定

Apache

ApacheのGzip圧縮のサンプルです、下記の内容を .htaccess に記載をします。MIME Typeの内容はサイトで配信されているコンテンツに合わせて修正してください。

# Gzip圧縮の設定
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
# 画像など圧縮済みのコンテンツは再圧縮しない
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico)$ no-gzip dont-vary
# プロクシサーバーが間違ったコンテンツを配布しないようにする
Header append Vary Accept-Encoding env=!dont-vary
# 圧縮対象とする MIME Type
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom_xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-font-woff
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
</IfModule>

Nginx

NginxのGzip圧縮のサンプルです。下記の内容を .confに記載をします。nginxは色々な書き方があるので検索されてみてください。

gzip on;
gzip_types text/css application/javascript text/xml text/plain application/json application/rss+xml application/xhtml+xml application/postscript application/rtf application/pdf application/atom+xml application/x-perl text/x-component;

静的なサイトであれば事前に圧縮をしておくとか、ディレクトリで指定するとか、色々な書き方があるので運用されているサイトにあった内容を検索してみてください。意外に奥が深いです。

圧縮の確認

GZIP圧縮されて配信されているかはヘッダー情報を確認します。

Gzip圧縮時のヘッダー情報

上の画像はGTmetrixの画面です、ブラウザのウォーターホールでもヘッダー情報の確認ができます。

上の画像の時、レスポンスヘッダーを見ると、MIMEタイプ「text/html」で「gzip圧縮」されて配信されているのが分かります。

ポイント:画像のjpegなどは既に圧縮されています

自分のサイトで管理・配信しているコンテンツがPageSpeed Insightsで「圧縮されていない」と指摘される時は、ヘッダー情報を確認してMIMEタイプを追加してあげてください。上の .htaccess の内容でほとんどのwebサイトは網羅していると思うのですが・・・。

外部のサーバーから読み込んでくるファイルについては、自分ではどうすることもできないので気にしないのが一番です。

ブラウザのキャッシュを活用する

この項目は、ヘッダーに「キャッシュ ヘッダーが含まれていない」時に指摘されます。

Expiresヘッダーについて

ブラウザーは一度アクセスしたページの情報をキャッシュします。再度同じページにアクセスしたり、別なページにアクセスして同じ画像が使用されている時などは、キャッシュされているデータを使用します。これはブラウザの標準のキャッシュ機能で、ユーザは何も意識しなくても使用をしています。

ブラウザのキャッシュ機能の動作については、ブラウザの開発元の考えた方・実装方法により多少の違いががあります。

PageSpeed Insightsのいう「キャッシュヘッダー」とは、ウェブサイトを運営している配信者側で、配信するコンテンツのヘッダーに消費期限のような時間を付与することです。ブラウザは、この時間の間に同じコンテンツにアクセスするなら、コンテンツに変更がないものとしてキャッシュされている情報を利用してコンテンツを表示するようになります。キャッシュの利用をブラウザに任せるのではなく、コンテンツ配信者側でキャッシュ制御ができる強制権の強いヘッダー情報です。もちろん、キャッシュさせないということもできます。

サイトのタイトルロゴの画像に毎回アクセスしたり変更の確認をする必要はないので、指定した時間の間は強制的にキャッシュしたデータを表示させるとイメージすれば分かりやすいと思います。アクセスしてくるユーザーにとってメリットがあるし、Webサーバーにとっても優しい機能です。

キャッシュコンロトールは奥が深く、Expiresヘッダー以外の方法もあります。興味があれば検索してみてください。

Expiresヘッダー有無のキャッシュの違い

ブラウザで普通にアクセス・キャッシュを使用している時のアクセス・Expiresヘッダー有りのキャッシュを使用している時のアクセス、の3種類のアクセスの違いが下の画像です。

このサイトのトップページにアクセスをし、外部スタイルシートstyle.css をキャッシュ。このサイトの別なページへアクセスした時に、style.css をキャッシュから利用しているかを確認しています。

普通にアクセス

ウォーターフォールとcssのヘッダー情報

Expiresヘッダー無しのキャッシュ利用

Expiresヘッダー無しの、ウォーターフォールとcssのヘッダー情報

Expiresヘッダー有りのキャッシュ利用

Expiresヘッダー有りの、ウォーターフォールとcssのヘッダー情報

画像は、ブラウザのSafariでアクセスした時のモノになります。Expiresヘッダー有りの時に、Cache-Control max-age=604800 とヘッダー情報が付与されているのが分かるかと思います。これがExpiresヘッダーです。この時間の間は、ブラウザは強制的にキャッシュを利用して描画をするようになります。

本当は、Expiresヘッダー無しと有りの時にアクセスの違いが出るようにしたかったのですが、ヘッダー情報の違いしか分からない画像になってしまいました。キャッシュをクリアせずに2~3日してからアクセスすると違いが出ると思うのですが・・・。

Expiresヘッダーの期限・ファイルの種類

PageSpeed Insightsでチェックされるキャッシュの期限は7日以上です。なので、ヘッダー情報に Cache-Control max-age=604800 と付与されていれば指摘されることはありません。「604800」の単位は「秒」です。「604800秒」となります、計算すると7日になります。

ヘッダーを付与するファイルは、htmlファイル意外と考えればOKです。

一般に HTML は静的ではないため、デフォルトではキャッシュ可能と見なさないようにしてください。

PageSpeed Insightsより引用

Expiresヘッダーの利用方法

Expiresヘッダーを利用するには、Webサーバーで設定をします。

Apache

ApacheのExpiresヘッダーのサンプルです、下記の内容を .htaccess に記載をします。MIME Typeの内容はサイトで配信されているコンテンツに合わせて修正してください。

"access plus 1 weeks" で7日。MIME Typeで指定したファイルのヘッダーに Cache-Control max-age=604800 が付与されます。

# ブラウザキャッシュの設定
<IfModule mod_headers.c>
<IfModule mod_expires.c>
ExpiresActive On
# MIME Type ごとの設定
ExpiresByType text/css "access plus 1 weeks"
ExpiresByType text/javascript "access plus 1 weeks"
ExpiresByType image/gif "access plus 1 weeks"
ExpiresByType image/jpeg "access plus 1 weeks"
ExpiresByType image/png "access plus 1 weeks"
ExpiresByType image/svg+xml "access plus 1 weeks"
ExpiresByType application/pdf "access plus 1 weeks"
ExpiresByType application/javascript "access plus 1 weeks"
ExpiresByType application/x-javascript "access plus 1 weeks"
ExpiresByType application/x-shockwave-flash "access plus 1 weeks"
ExpiresByType application/x-font-ttf "access plus 1 weeks"
ExpiresByType application/x-font-woff "access plus 1 weeks"
ExpiresByType application/x-font-opentype "access plus 1 weeks"
ExpiresByType application/vnd.ms-fontobject "access plus 1 weeks"
</IfModule>
</IfModule>

Nginx

NginxのExpiresヘッダーのサンプルです。下記の内容を .confに記載をします。nginxは色々な書き方があるので検索されてみてください。

expires 7d;

注意点1

強制権の強いヘッダーなので、例えば同じファイルネームで画像を差し替える、同じファイルネームで外部スタイルシートを修正・変更する、といった作業をしてもブラウザのキャッシュを削除しないと変更が反映されなくなります。

自分のサイトを変更して、ブラウザのキャッシュを削除、変更を確認。でも、アクセスしてくるユーザーは過去のキャッシュを利用しているので変更が反映されないという事になります。画像などはファイルネームを変えると思うので、特に外部スタイルシートを大幅に変更するときは、ファイルネームの変更を検討されてみてください。日付やバージョンをファイルネームに入れておくといいかもしれませんね。

ちなみにこのサイトは・・・、まったく気にしていないです。ダメなサイトだと思っています・・・。

で、上の注意点をふまえて説明をします。スマホの「iPhone」についてです。仮に、表示がガタガタになってしまっているサイトにアクセスをした時に、ブラウザのキャッシュをクリアしよう!と思っても、「機能制限をしているとSafariのキャッシュの削除」ができません。

通常のiPhoneのキャッシュ削除の画面

通常は上の画像のように、「履歴とWebサイトデータを消去」を選択するとキャッシュの削除ができるのですが、下の画像のように機能制限をすると、

iPhoneの機能制限の画面

機能制限されたiPhoneのキャッシュ削除の画面

上の画像のように、「履歴とWebサイトデータを消去」がグレーアウトしてしまいキャッシュの削除ができなくなります。

これは友人から聞いた話なのですが、企業案件でサイトをリニューアルするのにテストをしていたところ、お客様から「変更が反映されない」とあり、「キャッシュをクリアしてアクセスしてください」と返答したところ、「キャッシュがクリアできない」となってバタバタした事があったそうです。確認してみると、iPhoneで上の画像のように機能制限がしてあったそうです。

同じような場面にあたる方もいるかもしれないので、書き残しておきます。

注意点2

しつこいようですが、PageSpeed Insightsで指摘されるからといって、7日以上にこだわらずにサイトに合った設定をしてみてください。

商品を販売しているようなサイトで、情報を変更したのにユーザー側に変更が反映されない。リアルタイムを売りにしているのに変更が反映されない。などとなってしまうと売上に響いてしまう事にも繋がりかねません。キャンペーンを売って先行投資をしているような状況だと・・・。考えたくもない状況になります・・・。

そんな時は逆にキャッシュをさせない、といった方法も検討されてみてください。

キャッシュのコントロールはサイト・コンテンツに合わせて慎重に設定を。

Google Analytics と Adsense 、 外部配信のコンテンツについて

Google Analytics と Adsense を利用していると、PageSpeed Insightsでキャッシュについて指摘されると思います。

また、Adsenseは配信される広告によっても指摘される項目が大きく変わってきます。

これは、自分で管理しているサーバでなく、外部のサーバーから取得をしているのでどうする事もできません。同様に、htmlに記述をしている外部から読み込んでくるファイルについてもどうする事もできません。

WordPressであれば、テーマファイルやプラグインによって、自動的に外部ファイルを読み込むようになっているモノが多いです。私は、勉強を兼ねてhtmlを1行1行確認をしながら削除をしていきましたが、意味がないなと思いました。

PageSpeed Insightsの指摘は、Webの一般的な技術として、こんな技術的な方法があるんだー。という知識の参考程度にしておくといいかもしれません。

もし、PageSpeed Insightsで高得点を出してみたいという場合は、Analytics と Adsense を外して作業をした方が、どこまでが自分で追い込める範囲かが分かりやすくなると思います。

画像を最適化する

この項目は、見た目に影響が出ない範囲で画像を削減できると判断された時に指摘される項目です。

この指摘項目は他の指摘項目と比べてすごく曖昧です、PageSpeed Insightsが何を閾値としているかが提示されていないので、どこまで削ればいいのかが分からずに困惑します。

ただ、この画像の最適化はとても重要だと思います。

仕事でサイト立ち上げ・運営などをしている友人からは「趣味でやっているブログなんだから、細かいことは気にしなくていい。強いてあげれば画像の容量だけ気をつける。それよりも、人に伝えやすい文章を書くことに時間を使ったほうがいいと思うよ。サイトの高速化は、企業や商用サイトで、お客様に対して1msでも早く表示する!という時にガリガリやればいい。」というアドバイスをされたことがあります。

以前、スマホのアプリを紹介している企業のサイトを見ていた時に、やけにアクセスが遅いなと思ったら、3MB程度の画像を20枚ほど掲載していたことがありました。1つの記事にアクセスしただけで、60MBです・・・。他のページも画像を最適化していないようだったので、スマホでアクセスするとパケットがモノ凄く消費されるな〜と思いました。

画像の最適化は特に難しいことはなく、できることは単純でツールに任せるだけです。

パソコンを利用している方なら経験があるかもしれません、何かのファイルに画像を添付するのにデータサイズが大きいので小さくした・解像度が大きすぎるので画像を小さくした。これと同じことをやります。私はMacを使用しているのですが、OSに標準でついている「プレビュー」というソフトでもできます。

画像の最適化は、Webがどうこうという技術ではないので、検索すればソフトも星の数ほどたくさん出てきます。モニターのピクセルを接写して、ソフトの違いを比較されているサイトもたくさんあります。

WordPressのプラグインもたくさんあります。画像をアップロードした瞬間に最適化してくれたり、過去の画像を最適化・記事のimgタグのリンクを書き換えてくれるモノなどなど。

使いやすいモノを検索してみてください。

このサイトで画像を最適化している方法

ちなみに、このサイトで掲載している画像の最適化の方法です。使用しているのは、Macのソフトです。

  1. JPEGminiでMax Width(横幅)・Max Height(縦幅)を指定してリサイズしながら削る。
  2. ImageOptimでさらに削る。(JPEGの品質を85%にしています)

本当は、JPEGminiで削るだけにしたいのですが、PageSpeed InsightsとGtmetrixで「まだ最適化できる!」と指摘されるので、ImageOptimでさらに削っています。このページの画像を見て分かるかと思いますが、ザラザラの画像になっています・・・。

最初にJPEGminiで削るのは、Max Width(横幅)・Max Height(縦幅)で幅を指定して、一気にファイルを処理できるからです。

JPEGminiの画面

JPEGminiは上の画像のような見た目のソフトです。

ImageOptimは下の画像です。

ImageOptimの画面

どちらのソフトも設定できる項目は少なくシンプルです、設定をしたら画像ファイルをドラッグ・アンド・ドロップするだけで使えます。

ちなみに、上の2枚の画像を最適化した時のデータサイズの遷移です。

  1. 798KB(生データ) → 36KB(JPEGmini) → 23KB(ImageOptim)
  2. 448KB → 38KB → 25KB

JPEGminiで極端にデータが小さくなっているのは、画像の解像度のリサイズも実施しているからです。JPEGminiで削った後に、ImageOptimでさらに削ってもあまり意味がないのですが、PageSpeed Insightsで指摘されるので・・・。

2つのソフトのリンクを記載しておきます。

JPEGmini

  1. MacAppStoreにJPEGmini Liteという体験版?制限のかかっているバージョンもあります。
  2. 使用していないのですが、Windows版もあるようです。
  3. exifデータは削除されないので、デジカメ・スマホなどで撮影した画像をWebで使用する場合は注意が必要です。

私は、Web以外にも画像を最適化するのに利用しているので、Mac App StoreでJPEGminiを購入して利用しています。

ImageOptim

使い方などについては、多くのサイトで記事を書かれているので検索されてみてください。

PageSpeed Insightsでダウンロード

ダウンロードのリンク画面

PageSpeed Insightsで分析したサイトの画像を最適化してくれるので、ダウンロードすることもできます。

ポイント

最初に書きましたが、PageSpeed Insightsが何を基準・閾値にして判定しているかが明示されていないので、画像の最適化はほどほどに。このサイトのようにザラザラの画像になってしまいます・・・。

画像を最適化することで、ユーザーにもサーバーにも優しいサイト運営ができるようになるはず。スマホでアクセスしてきてくれるユーザに、1ページで数十MBもパケットを消費させてはいけないと思います・・・。

リンク先ページのリダイレクトを使用しない

この項目は、PageSpeed Insightsで分析させたいURLの先で、リダイレクトが複数発生している場合に指摘される項目です。PageSpeed Insightsで自分のサイトをチェックした時に、この項目が指摘される方は少ないと思います。

極端な例になりますが、画像を使って説明します。

リダイレクトが2回発生している図

上の画像のように、https://blue-leaf81.net/css1/style.css にアクセスをすると、 /css2/style.css/css/style.css と2回リダイレクトが発生する時。

この時に、PageSpeed Insightsで https://blue-leaf81.net/css1/style.css のURLを入力し、分析をすると「リダイレクト」の指摘が出ます。

リダイレクトが1回発生している図

上の画像のように、リダイレクトが1回であればPageSpeed Insightsで指摘はされません。

また、htmlの中で <link rel="stylesheet" type="text/css" href="/css1/style.css"> として、リダイレクトが発生する外部スタイルシートがあっても、PageSpeed Insightsで指摘はされません。

あくまで、PageSpeed Insights で入力した、分析する対象のURLにアクセスした時のリダイレクト回数をカウントしているようです。

PageSpeed Insightsのページには、モバイルとPCでページを分ける時のリダイレクトのケースが書かれています。この指摘項目は、あるURLにアクセスした時にモバイルとPCでリダイレクトを挟みながらページを振り分けるケースを想定した項目のようです。逆に考えると、複数のリダイレクトをさせている場合、きちんとモバイルとPCでリダイレクトができるかをチェックできます。そして、Webサーバーでユーザーエージェントを見て配信するページを分ける場合は関係ないとも言えます。

いずれにしても、指摘されるユーザーの方は少ないと思います。

スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する

この項目は、次の項目「8.表示可能コンテンツの優先順位を決定する」と同時に考える必要があります。

この指摘事項をクリアするには、HTML・CSS・JavaScriptの知識、WordPressを使用しているならWordPressの知識が必要になると思います。私は、HTMLとCSSを勉強して、 WordPressでテーマが作れるようになって。JavaScriptを多少書けるようになったら、ようやくこの指摘事項の全体像を把握して制御ができるようになりました。とてもややこしいです。

サイトの構成によっては諦めないといけないし、WordPressのプラグインによってはどうすることもできない指摘項目です。

とてもややこしいので、教科書的な内容で説明をします。

まず、「スクロールせずに見えるコンテンツ」という言葉についてです。

スクロールせずに見えるコンテンツ

スクロールせずに見えるコンテンツとは「ファースビュー」と呼ばれている、最初にサイトにアクセスした時に画面に表示される領域のことです。

ん?と、なる人もいると思いますが、スマホ・PCなどで画面サイズがバラバラなのでファーストビューの領域はもちろんバラバラになります。

なので、今は PageSpeed Insights 用のファースビューについて考えてみます。

モバイルのファーストビュー領域

PCのファーストビュー領域

PageSpeed Insights の結果の画面で出てくるのが上の画像ですが、この画面の表示範囲が「ファースビュー」です。

  • モバイル : 480px(横) X 750px(縦) ぐらい
  • PC : 1050px(横) X 640px(縦) ぐらい

大雑把に計測しました。

次は、「レンダリングをブロックしている」という言葉についてです。

レンダリングをブロックしている

この言葉は、ブラウザのレンダリング動作を知る必要があります。

ブラウザはサイトにアクセスしてWebサーバーからhtmlファイルを受け取ると、ファイルに記載されている内容を上から1行1行解析をします。解析をしながら、描画(レンダリング)に必要な情報を集めDOM(Document Object Model)を構築します。HTMLファイルを最後まで解析すると、DOMの構築も完了するのでブラウザはレンダリング開始します。解析の途中で外部スタイルシートがあったり、外部から読み込むJavaScriptがあると、ブラウザはDOM構築に必要・不要を判断できないのでファイルを取得し中身を解析します。

これが基本的なブラウザのレンダリングの動作です。

上の内容を踏まえて考えると、PageSpeed Insightsの言うレンダリングをブロックしているとは、「htmlファイルだけを上から下まで解析するだけでレンダリングが開始できるようにしなさい。外部から読み込む CSS/JavaScript があると、そのファイルにアクセスする必要があるので、レンダリングがすぐに開始できない!」と言っています。

え!どうすればいいの・・・って、私はなりました・・・。

どうすればいいか、外部から読み込まずにインライン化(htmlファイルの中に書く)すればいいんです。

スクロールせずに見えるコンテンツのレンダリングをブロックしている

先に、言葉の説明を終わらせます。「スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する」とは、上の2つの説明をつなぎ合わせると。

ファーストビューの領域を、htmlファイルだけを解析したところでレンダリングできるようにしなさい。そのため、外部から読み込む JavaScript/CSS を排除(削除) 又は htmlにインライン化しなさいとなります。

何が言いたいのかなと考えると、1秒でも早く画面に何かを表示したほうがユーザーフレンドリーだよね と言っていると思います。

インライン化といっても、自分で管理している JavaScript/CSS については自由にできますが、外部で提供されているモノについてはどうしようもありません。また、全てをインライン化してしまうとhtmlファイルのサイズが大きくなりすぎてしまいます。

なので、ファースビューの領域に関わる部分のみインライン化しレンダリングを開始させ、他の部分については後から読み込みをし描画をさせるようにします。

先に「インライン化」、次に「後から読み込みをし描画」を説明します。

インライン化

CSSとJavascriptのhtmlへのインライン化のサンプルです、下記のようにします。

<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">

<style type="text/css">
 #スタイルシートを記入
</style>

<script type="text/javascript">
 #JavaScriptを記入
</script>

</head>
<body>
</body>
</html>

headタグ の中に、

  • CSSなら <style type="text/css">#スタイルシートを記入</style> で記述
  • JavaScriptなら <script type="text/javascript">#JavaScriptを記入</script> で記述

他にも、bodyタグ の中の最後に書くこともできます。

JavaScriptは、自分で管理しているモノであれば .js の中身をベタッと書いてしまえばOKです。インライン化するScriptの中で同期で読み込むようなファイルがあれば、非同期にする・そのファイルの中身もインライン化してください。

CSSはどこまでがファースビューか考慮しながらセレクタを抜き出すは面倒ですが・・・。

レスポンシブデザインで、@media screen を利用している方は気をつけてください。スタイルシートの書き方は作成者の癖があるので、@media screen で一括りにまとめてセレクタを書いていたり、セレクタ毎に @media screen があったりします。一番早いのは自分で使いやすいように書き直してしまうことですが・・・。又、複数のスタイルシートを読み込んでいる場合もあると思いますので慎重に。

「後から読み込みをし描画」

次は、ファーストビュー以外の部分で、後から読み込みをし描画をする方法です。

仕組みは簡単です。JavaScriptを利用し読み込み、描画・実行をさせます。この時に、JavaScriptの同期・非同期・DOMの操作という知識が必要になりますが、これらはJavaScriptの基礎知識で、図を使って詳しく説明しているサイトがたくさんあるので検索してみてください。

実現するスクリプトは色々な書き方があります、なので参考程度に書きます。

まずはCSSです、このサイトでは外部スタイルシートを下記のようなスクリプトで読み込ませています、

<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">

<style type="text/css">
 #インライン化するスタイルシートを記入
</style>

</head>
<body>
<footer>
</foter>

# ↓非同期で読み込み、描画する外部スタイルシート

<script>
(function(d){
var s = d.getElementsByTagName('script')[0];
var c1 = d.createElement('link');
c1.rel = 'stylesheet';
c1.href = '/css/style.css';
s.parentNode.insertBefore(c1, s);
})(document);
</script>

</body></html>

上のように非同期のスクリプトで読み込ませることで、htmlを解析したところで1度描画が発生、外部スタイルシートを読み込んだ時に2度目の描画が発生し外部スタイルシートのスタイルが適用されるようになります。構築後のDOMを操作し、htmlの構造も壊れません。

2枚目、3枚目のスタイルシートも、c1. の部分を c2.c3. として追記することで読み込ませることができます。ただ、非同期なので、先に読み込まれたスタイルシートから適用されていきます。順番にスタイルシートを適用させたいときは別なスクリプトが必要になります。

上のリンク先でも、スタイルシートを非同期で読み込ませる方法が記載されています。

次は、外部のJavaScriptファイルの読み込みです。

外部から読み込むJavaScriptファイルは、提供元で非同期のモノがあれば利用するようにします。

JavaScriptを読み込ませるには、 <script src="http://~.net/~.js" async></script>async をつけて非同期で読み込ませます。もしくは、非同期でJavaScriptを読み込み実行するスクリプトを自分で書きます。

広告のAdsenseを利用している方なら、同期・非同期の言葉を見たことがあるかもしれません。同期は、1度目の描画をする前に広告を読み込みます。非同期は、1度目の描画が発生した後に読み込み・読み込みが完了次第描画を行います。ファースビューの領域でAdsenseを掲載していると、下の方にスクロールを始めた頃にやっと表示されるような場面もあるかと思いますが、同期・非同期の違いのためです。

他にも、非同期で外部スタイルシートを読み込んだのを確認した後に外部のJavaScriptを読み込み実行させたい、バラバラに表示でなく順序立てたいなどの状況もあると思います、それもスクリプトで実現できます。

スクリプトの書き方は正解というものがないような気がするし、それこそ凄い数のサイトがスクリプトを掲載・解説してくれているので、検索されてみてください。多分、こんなことを実現したいというスクリプトは、世界の誰かがインターネット上で掲載をしてくれていると思います。

スクリプトの検索なら、USA版のGoogle検索がオススメです。Javascriptのファイル名とasyncなどの言葉で検索してみてください。

動作のチェックをするには

htmlを読み込み・解析した段階で描画ができているかは、ブラウザやGTmetrixのウォーターホールで確認をします。画像を掲載したかったのですが、分かりやすいウォーターホールが形成できなかったので省略します・・・。

省略しますが、ブラウザで非同期の表示を体験する方法を記載します。

ブラウザのChromeで「帯域制限」を利用します。

Chromeのメニュー画面

メニューバーの「表示」から「開発/管理」、「デベロッパーツール」を選択。

Chromeのデベロッパーツールの画面

ウォータホールの画面で、「No throttling」という部分をクリック。

Chromeの帯域制限プリセット

プリセットで3G回線などがありますが、今はとにかく遅くしたいので「Add」を選択。

Chromeの帯域制限の設定画面

とにかく遅い状態にしたいので、仮に「10kb/s」・Latencyは「900ms」としてみました。

帯域制限したChromeの画面

作成した「Throttling Profiles」を選択。これで帯域制限状態になります。この状態で、ご自身のサイトにアクセスをしてみてください。

htmlファイルが読み込まれた段階で画面が描画され、スタイルシートなどは後から順次適用されていけばOKです。

帯域制限でとても遅くしているので(ISDNや電話回線の時代なみ)、ページの読み込みに数分かかるかもしれません・・・。

逆に考えると、高速化を何もしない時にこの帯域制限を利用すると、遅い回線でアクセスしてくる方にはどういう風にサイトが表示されるかがチェックできます。

imgタグについて

最後に、画像を表示するときの imgタグ についてです。

画像を表示する時は、画像の表示領域を imgタグ に記載をしたほうがいいと思います。

<img src="/images/~.jpg" alt=" " width="600" height="297" />
  • width=“横幅(px)”
  • height=“縦幅(px)”

WordPressを使用し、WordPressの機能で記事に画像を貼り付けている方は標準で記載がされています。

この表示領域を記載すると、ブラウザは画像が手元になくても表示領域を確保してレンダリングを開始します。記載がない場合は、画像がブラウザに到達してから領域確保・描画をするので、画面がガタガタと揺れたような描画になることが起こり得ます。なんというんでしょうか、画像を後から差し込んでいくような描画と言えばいいのか・・・。

もし、PageSpeed Insightsでファースビューにある画像が「レンダリングをブロック〜」と指摘されるときは、この表示領域が記載できているかを確認してみてください。

私は記載をすることで指摘がなくなったページがありました。

手打ちでhtmlタグを打っていると、画像のサイズを確認するのが面倒になるんです・・・。私です、後で入力しようと思っていて良く忘れます・・・。

ポイント

スクロールせずに見えるコンテンツのレンダリングの項目にこだわって作業しても、1ページあたりの通信量はほぼ変わりません。見かけ上、ページの表示が早くなりますが、読み込み完了までの時間はほとんど変わらないです。

面倒なので全てのCSSをインライン化したりもしてみていましたが、外部スタイルシートならブラウザのキャッシュも効くし、何よりもCSSは .css のCSSファイルで htmlタグ とは別に書いた方が楽です。

あまりこだわらずにほどほどに。

注意点

友人から教えてもらった事なのですが、自分でスクリプトを組んだり・サイトデザインを大幅に変えた時は、Googleウェブマスターツールの「Fetch as Google」でチェックしてみてください。

Fetch as Googleの画面

「取得してレンダリング」で、PC と スマホ で正常に表示できるか、Googleがきちんとページを認識できているかが分かります。

それと、これはGoogleにインデックスされた後になるので、ページを公開してしばらくしてからですが、ページの一番最後のほうの文章をGoogleで検索してヒットするか?キャッシュは正しく表示されるか?も確認してみてください。

Googleで全文一致検索の画面

このページの一番最後のほうにある文章を検索した画像です。きちんとページの最後のほうにある文章も認識されています。

検索は "検索したい文字"" ダブルクォーテーションで挟んで「全文一致」で検索します。

検索結果の三角記号をクリックするとキャッシュを表示できます。

Googleでキャッシュを表示する三角記号

Googleのキャッシュ表示の画面

上のような画面でキャッシュされたデータが表示されます。Googleがページ(html)を取得した日時も表示されます。GMTで表示されるので、日本は9時間プラスしてあげてください。

文章の検索・キャッシュの確認も、サイトデザインを大幅に変更した後もGoogleに正しくページが認識されているかを確認するためです。

これは私だけだと思うのですが、JavaScriptでページをいじくりまわすということをした時に、コードに不備があったせいかGoogleにページを正しく認識してもらえていなかったようで、ほとんど全てのページがインデックスから消えてしまったことがあります。

コードを実装してから1ヶ月半ぐらいしてから気がついたのですが、シンプルなhtmlのページに戻して、再度Google検索で表示されるようになるまで1ヶ月以上かかりました。

よっぽど変な事をしなければ問題ないと思いますが・・・。

表示可能コンテンツの優先順位を決定する

この項目は、上の項目「7.スクロールせずに見えるコンテンツのレンダリングをブロックしている」と同時に考える必要があるのですが・・・。

きちんと説明することができません・・・。ごめんなさい。

こうするといいですよ〜という事が説明できればいいのですが・・・、上のインライン化を作業しているうちにいつの間にか指摘されなくなったり、再度指摘されたり。

「画像の読み込みが終わらないと、ファーストビューの 〜% しかレンダリングできませんでした。表示可能コンテンツの優先順位を決定してください。」のような表示が出ていたページがこのサイトにありましたが、何もしていないのに指摘されなくなったこともあります。

省略!

WordPressについて

WordPressを利用していると、テーマファイルやプラグインによって、 <head><footer> で色々な JavaScript や CSS の読み込みを行うようなタグが排出されてしまい、「スクロールせずに見えるコンテンツのレンダリングをブロック」や 「表示可能コンテンツの優先順位を決定」 という指摘が多く出ることもあります。

ん〜??となって、プラグインを停止したり・テーマファイルを改造する前に、必ずバックアップをオススメします。

私です、バックアップをせずにいじくりまわしたらグチャグチャのまま戻れなくなりました・・・。

funcitions.php へ以下のように記載をして、ヘッダーの「wp_head();」で余計なモノが出力されないようにしていました。こんなモノもあるんだ程度に、サンプルとしてみてください。

remove_action( 'wp_head', 'feed_links_extra', 3 );
remove_action( 'wp_head', 'feed_links', 2 );
remove_action( 'wp_head', 'rsd_link' );
remove_action( 'wp_head', 'wlwmanifest_link' );
remove_action( 'wp_head', 'index_rel_link' );
remove_action( 'wp_head', 'parent_post_rel_link', 10, 0 );
remove_action( 'wp_head', 'start_post_rel_link', 10, 0 );
remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0 );
remove_action( 'wp_head', 'wp_generator' );

//絵文字関係削除
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('admin_print_scripts', 'print_emoji_detection_script');
remove_action('wp_print_styles', 'print_emoji_styles' );
remove_action('admin_print_styles', 'print_emoji_styles');
//Wordpress4.4からのoembed関係削除
remove_action('wp_head','rest_output_link_wp_head');
remove_action('wp_head','wp_oembed_add_discovery_links');
remove_action('wp_head','wp_oembed_add_host_js');
remove_action('wp_head','wp_shortlink_wp_head');

まとめ

PageSpeed Insights の指摘事項は参考程度に受け止めておくのが一番良いと思います。

現実的に対応するとしたら、

  • GZIP圧縮を有効にする
  • 画像を、Webのページにあったサイズに最適化する(高解像度を見せたいなら別途リンクを貼る)

の2つぐらいの対応になると思いました。

次が、サーバーの応答時間を短縮するになるかと思います。

ブラウザキャッシュの7日は長すぎると思うし、Minifyは効果が分かりにくい。レンダリングブロックや表示可能コンテンツの優先順位の項目は、作業内容のワリに見かけじょう速くなるだけで、ん〜・・・。となります。

頑張って削って高速化しても、大きいファイルサイズの画像1枚で、全てを台無しにしてしまう事もあるので、画像の扱いは気をつけた方がいいと思います。

PageSpeed Insights で検索していると、SEOという言葉を目にしますが、私は全く関係ないと思っています。GoogleBotは、htmlはhtmlだけ。画像は画像だけというように、てんでバラバラに気ままにアクセスにきます。瞬間的なトータルのページスピードは見ていないと思うので、ページの表示スピードがー!とGoogle検索に言われても・・・。

PageSpeed Insights で大事だと思ったのは、こういった技術的な方法があるんだ!と気が付かせてくれたことです。何もない状態から始めるよりは、最初の一歩・とっかかりとしてありがたいなと思いました。おかげて色々な知識がつきました。

ただ、ページの高速化という手段が目的になってもいけないと思うので、何事もほどほどに。

2017年4月4日に全体的にページの内容を更新しました。