GTMatrix の診断結果でF判定になった項目の対策まとめ

公開日: : 最終更新日:2014/05/07 ブログ ,

ブログを運営している誰もが取り組む「ブログ表示の高速化」。

優先度が低かったので測定すらしていませんでしたが、作業の合間に GTmetrix を試してみました。

結果は散々たるものでしたが今後に向けての改善ポイントが分かったのは収穫です。
今回の測定結果とその対策をまとめたのでメモしておきます。

icatch-measure_4153762400_mini

photo credit: Barbara.K via photopin cc

目次

1. 測定結果

GTMatrix の判定結果は次の通りでした。

2014-05-07-GTmetrix-01

“Page Speed Grade” で 29% の F 判定、”YSlow Grade” は 73% の C 判定でした。
“Page load time” は 4.97 秒。

お世辞にも速いとは言えない結果です。

高速化については何も取り組んでこなかったので「まぁ、そんなもんだよね」と淡々と受け止めています。
まだまだアクセスが多くないので無理ない範囲で徐々に改善していこうかなと。

2. 今回 F 判定になった項目

とは言え、どういう部分を指摘されたのかは知っておきたかったので、 F 判定になった項目を確認しました。

“Page Speed” タブに表示された項目で F になったものは次の4つでした。

  1. Serve scaled images
  2. Leverage browser caching
  3. Specify image dimensions
  4. Minify CSS

確認した内容は次の通りです。

2-1. Serve scaled images

icatch-scaled_3383629917_mini

photo credit: JD Hancock via photopin cc

これは「画像のサイズ(大きさ)が適切でないため HTML や CSS でリサイズしている」という意味です。

これはボクのミスが原因でした。

記事の「導入部分」の下に画像を載せるように記事を書いています。
ここに表示させる画像はサイドバーの「NEW ENTRY」に表示されるサムネイルにも使われています。

この「サムネイルにも使われています」ってのが問題でして、サムネイル用の大きさではないので元画像をサムネイルの大きさにリサイズして表示されることになります。

ですが、こういう怠けたことをしていると「いやいや、ちゃんとした大きさの画像を用意してよね。。。」と怒られて上記のような F 判定になってしまうようです。

要は、サムネイル画像は適切な大きさのものをちゃんと用意しようねってことなんですが、CSS を使った画像のサイズ指定も高速化の妨げになるとは知りませんでした。

2-2. Leverage browser caching

icatch-leverage_10310176123_mini

photo credit: giulia.forsythe via photopin cc

これは「ブラウザのキャッシュを効かせろ」ってことです。

キャッシュの仕組みについて簡単に説明しておきます。

キャッシュの仕組み

WordPress は動的にコンテンツを生成するアプリケーションです。

画面を表示するには HTML が必要です。
HTML はヘッダやらフッタやらサイドバーとか記事本文で構成されており、これらの要素を組み合わせて HTML が出来上がります。

この組み合わせる作業をアクセスがあるごとに行って HTML を作成することを「動的」と言います。

WordPress は、デフォルトだと毎回 HTML を生成してブラウザに返します。

そうではなく、生成済みの HTML をポイっと返したほうが(生成する時間が短縮されるので)レスポンスは速くなります(この「生成済みの HTML を返すこと」を「静的」と言います)。

なので、HTML をキャッシュさせるとそこそこの効果があると思います (この対応は高速化というよりは、サーバの負荷軽減の色合いが強いかもしれませんが)。

また、HTML 自体を閲覧者のブラウザに持ってもらうという方法もあります。
わざわざサーバにアクセスしなくても、手元の HTML を表示すればいいので一瞬で表示されます。
こちらはサーバに取りにこないのでかなりの効果が期待できます。

以上、簡単ではありますが、これがキャッシュの仕組みです。

WordPress のプラグインでコンテンツをキャッシュする

“wordpress cache plugin” で検索すると、次のプラグインがヒットしました。
このプラグインは有名ですよね。

使用上の注意

いいことづくめに聞こえるキャッシュですが、使用するに当たってちょっと注意することがあります。

キャッシュを有効にすると、コンテンツを修正しても修正前の古いコンテンツがある程度の期間は表示されてしまう可能性があります。

思わぬトラブルを防ぐためにも、その辺りの回避方法を理解したうえで導入するのがいいかと思います。

2-3. Specify image dimensions

icatch-dimensions_5617415541_mini

photo credit: THEMA.FELIX via photopin cc

これについては、次のように画面に表示されていました。
画像の width または height の指定に誤りがあるということだと思われます。

The following image(s) are missing width and/or height attributes.

ここにリストアップされていた画像はどれも アマゾンランクレット というブログパーツのものでした。

サイドバーがさみしかったので設置させてもらっていたのですが、(積極的に売り込んでいないので当たり前ですが)収益もないし高速化を妨げるようなので一旦無効してしまいました。

2-4. Minify CSS

icatch-minify_2655496451_mini

photo credit: Creativity+ Timothy K Hamilton via photopin cc

この項目は「CSS を Minify させろ」っていう意味です。

JavaScript や CSS の内容を変えずにファイルサイズ(キロバイトとかの容量)を削減しファイルの転送量を減らして、その結果、サイトの表示を高速化させる方法を “Minify” と言います。

WordPress のプラグインで CSS の Minify をする

“wordpress css minify plugin” で検索すると、次の2つのプラグインが1位・2位でヒットしました。

  1. WP Minify
  2. Better WordPress Minify

言語を「日本語」に限定すると “WP Minify” の方がヒットするので、おそらく “WP Minify” のほうが使われているんだと思います。予想ですけど。

“WP Minify” は、次の説明文にもあるように Minify のほかにもファイルの「結合」もしてくれるようです。

This plugin uses the Minify engine to combine and compress JS and CSS files to improve page load time.

WordPress › WP Minify « WordPress Plugins

一般的には JavaScript や CSS、画像などのファイルが減ると次のような嬉しいがあります。

  • サーバからの転送量が減る → 表示の高速化
  • ブラウザがそれらファイルを読み込む時間が減る → 表示の高速化

読み込むファイルの数やファイルサイズを抑えるとそれだけ速く画面を表示できるので、結合も高速化の手法に挙げられます。

この辺りも “WP Minify” が選ばれる原因になっているんでしょうかね。

Web サービスを使って CSS を Minify する

プラグインに頼らず自分で Minify をやる場合は、次のような Minify してくれる Web サービスを使うのが便利です。

自分で Minify するとなると、CSS を修正する毎にサーバに Minify した CSS をアップロードし直すことになります。
手間なだけでメリットを感じないですが、あまりプラグインを入れたくない場合はこういう運用になるんでしょうね。

3. まとめ

以上、GTMatrix を使って F 判定になった項目を確認しました。

“Specify image dimensions” だけはブログパーツを外すだけだったので外して再測定してみましたが、これだけでは評価が上がりませんでした。

やっぱり優先順位はあるようで、ロードを短縮する対策を行ったほうが手っ取り早く効果が得られると思います。

Googleアドセンス用(PC)

  • このエントリーをはてなブックマークに追加
  • follow us in feedly

関連記事

2014-04-07-icatch

ブログを本格的に始めて3ヶ月経って分かったこと

tomoyamkung のブログ を2014年1月から本格的に始めました。 それから3ヶ月が経ちま

記事を読む

icatch-seeking_mini

Stinger3 の追尾式 SNS ボタンを削除する方法

Stinger3 ではデフォルトで画面左下に追尾式の SNS ボタンが表示されます。 これはこれであ

記事を読む

icatch-feedly-buttom

Stinger3 に Feedly ボタンを設置しました

Google Reader が終了してしまってから RSS フィードの購読に使っている Feedly

記事を読む

icatch-blog-customize_mini

Stinger3 の single.php で使われている style.css をカスタマイズ

デフォルトの状態でも読みやすいと感じる Stinger3 ですが、このブログはプログラムのソースコー

記事を読む

icatch-money-93206_640

9円!!

このブログに設置してある Google Adsense の見積もり収益額を確認すると、現時点での今月

記事を読む

icatch-pocket

Stinger3 に Pocket ボタンを設置しました

「あとで読む」系のサービスのひとつである Pocket。 ボクも Pocket を使っていまして、通

記事を読む

Googleアドセンス用(PC)

Message

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です


− 四 = 0

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Googleアドセンス用(PC)

icatch-jersey_multi_pathparams
Jerseyの@PathParamはスラッシュの間に複数指定できる

http://hoge-api/user/{id}.{format}

icatch-vagrant_box_customize
VagrantのBoxファイルをカスタマイズして独自のBoxファイルを作成する

配布されている Vagrant の Box ファイルを使って検証環境を

icatch-2015-006-1
バリデーションチェックにJava8のOptionalを使ってスマートに書く(自分比)

Web アプリのバリデーションチェックにアノテーションを使うことが増え

icatch-2015-005-1
ユニットテストの偏りを防ぐ命名規則の付け方

ユニットテスト名に以下の命名規則を付けるようにして二ヶ月ぐらい経った。

icatch-2015-004-1
Vagrantで起動したCentOS上のOctopressをホストOSから確認する設定

タイトルの通りだが、Vagrant を使って起動した CentOS に

→もっと見る

PAGE TOP ↑