WordPressサイト高速化のチューニング

Googleは、2010年4月9日、検索ランキングアルゴリズムの要素としてページ読込速度を組み込んだことを発表しています。
つまり、サイトの表示速度が検索順位決定の要素のひとつとして考慮されるということです。
Googleでは、サイトの高速化を支援してくれる「PageSpeed Insights」という表示速度改善ツールが公開されています。

PageSpeed Insights とは

PageSpeed Insights は、ウェブページのコンテンツを解析し、ページの読み込み時間を短くするための方法を提案します。ページの読み込み時間を短縮することで、直帰率が低下しコンバージョン率が上昇する可能性があります。

PageSpeed Insights
https://developers.google.com/speed/pagespeed/insights/

Googleでは、このスコアが、モバイル85点以上/デスクトップ90点以上を十分な速度だと判断しているようですが、現実的には、サーバーのスペックや、コンテンツの内容によっては難しい場合もありますので、デスクトップで80点代をもくひょうとしてチューニングします。
PageSpeed Insightsでの診断される要素結果からの、高速化に向けた方法と改善策をまとめていきます。

■画像を最適化する

ページ上の画像を最適化して、視覚的な品質に大幅な影響を与えずにサイズを削減し、ユーザーがリソースの読み込みを待機する時間を削減するために画像のサイズを最小限にします。画像のフォーマットや圧縮を適切に行うと、データのバイト数を大幅に節約できます。

推奨される解決方法

1. 画像圧縮ツールを使用する

画像の品質に影響を与えずに、PEG や PNG ファイルに対して高度なロスレス圧縮を実行するオンラインツールを使用する方法がありますが、WordPressで投稿するたびに、画像を圧縮してから投稿するのは現実的ではありません。
そんな場合に活躍するのは、投稿時にアップロードした画像を自動で圧縮してくれるWordPressプラグインです。

2. WordPressプラグインを使用
EWWW Image Optimizer
アップロードした画像について、自動でファイルサイズを圧縮してくれるプラグイン。
テーマ内で使用している画像も最適化することができます。

WP Smush.it
画像のファイルサイズを圧縮するプラグイン。

■CSS の配信を最適化する

レンダリングをブロックする外部スタイルシートがページに含まれていて、画面へのコンテンツの描画を遅延させている。

推奨される解決方法

・小さな CSS ファイルのインライン化

・外部 CSS リソースが小さい場合は、HTML ドキュメントに直接挿入する。
・大きなデータ URI をインライン化しない
・CSS 属性をインライン化しない
(コードの不要な重複につながる場合があるため、HTML 要素に CSS 属性（< p style=...> など）をインライン化するのはできるだけ避ける。)

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

サーバーからのレスポンスに明示的なキャッシュヘッダーが含まれていないことや、リソースが短時間のみキャッシュされるよう指定されていることを PageSpeed Insights が検出した場合にトリガーされます。

推奨される解決方法

サーバーでブラウザのキャッシュを有効にします。
静的なリソースのキャッシュの有効期間は1週間以上にします。
1. METAタグで設定

<meta http-equiv="Expires" content="604800">

※ブラウザキャッシュの有効期限を1週間に設定

2. .htaccess に記述

<Files ~ ".(gif|jpe?g|png|ico|woff)$">
Header set Cache-Control "max-age=2592000, public"
</Files>

■リソース（HTML、CSS、JavaScript）を圧縮する

リソースの圧縮（ミニファイ）によって、余分なスペース、改行、インデントなどの不要なバイトを取り除くことでデータサイズを圧縮して削減します。

推奨される解決方法

・オンラインツールで、圧縮（ミニファイ）する。

■圧縮を有効にする

gzip 形式で圧縮すると、ウェブサイトを表示するのに必要なリソースのダウンロードにかかる時間を削減できます。

推奨される解決方法

,htacessに記述

# WebフォントをApache側で圧縮して転送
<IfModule mod_mime.c>
	AddType font/opentype         .otf
	AddType font/eot              .eot
	AddType font/truetype         .ttf
	AddType application/font-woff .woff
</IfModule>
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE font/opentype font/eot font/truetype application/font-woff
</IfModule>

#あらかじめ圧縮したWebフォントファイルが同じディレクトリにあればそれを使用
<IfModule mod_rewrite.c>
  RewriteCond %{HTTP:Accept-encoding} !gzip
  RewriteRule .* - [S=4]
  RewriteCond %{REQUEST_URI} \.otf$
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI}\.gz -s
  RewriteRule .* %{REQUEST_URI}\.gz [L,QSA,T=font/opentype,E=no-gzip:1]
  RewriteCond %{REQUEST_URI} \.eot$
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI}\.gz -s
  RewriteRule .* %{REQUEST_URI}\.gz [L,QSA,T=font/eot,E=no-gzip:1]
  RewriteCond %{REQUEST_URI} \.ttf$
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI}\.gz -s
  RewriteRule .* %{REQUEST_URI}\.gz [L,QSA,T=font/truetype,E=no-gzip:1]
  RewriteCond %{REQUEST_URI} \.woff$
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI}\.gz -s
  RewriteRule .* %{REQUEST_URI}\.gz [L,QSA,T=application/font-woff,E=no-gzip:1]
</IfModule>

#コンテントタイプを設定する
<FilesMatch "\.(?i:otf(\.gz)?)$">
  ForceType font/opentype
</FilesMatch>
<FilesMatch "\.(?i:ttf(\.gz)?)$">
  ForceType font/eot
</FilesMatch>
<FilesMatch "\.(?i:eot(\.gz)?)$">
  ForceType font/truetype
</FilesMatch>
<FilesMatch "\.(?i:woff(\.gz)?)$">
  ForceType application/font-woff
</FilesMatch>

#Webフォントファイルがブラウザ側でキャッシュされるようにする
<FilesMatch "\.(?i:(otf|ttf|eot|woff)(\.gz)?)$">
    ExpiresDefault A25920000
</FilesMatch>

<IfModule mod_expires.c>
# キャッシュの有効期限を設定
ExpiresActive On
ExpiresByType text/css "access plus 1 days"
ExpiresByType image/gif "access plus 1 weeks"
ExpiresByType image/jpeg "access plus 1 weeks"
ExpiresByType image/png "access plus 1 weeks"
ExpiresByType application/x-javascript "access plus 1 weeks"
</IfModule>

SetOutputFilter DEFLATE
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico)$ no-gzip dont-vary
Header append Vary User-Agent env=!dont-vary

このソースは、Webフォント読み込み時の設定も含まれていますが、一般的には、text/htmlのみgzip圧縮すればよいでしょう。
※ちなみに、isotypeテーマでは、gzip圧縮形式で圧縮することより、80%近くのリソースが軽減されます。

レスポンシブウェブデザイにおける高速化

Googleは2013年8月、「1秒以内にAbove the foldを表示することが重要である」と発表しました。

「サイトをスクロールするのは23％のみ。残り77％はスクロールしない。」
http://www.smashingmagazine.com/2009/09/24/10-useful-usability-findings-and-guidelines/

そして、2015年4月21日より、スマートフォン利用に最適化されたサイトが「モバイルでの」検索結果で優遇されやすくなるように変更されると発表されました。

スマートフォン向け検索でのランキングの変更について
http://googlewebmastercentral-ja.blogspot.jp/2013/06/changes-in-rankings-of-smartphone.html

Google、モバイルフレンドリーアップデート

以下は、モバイルデバイスが対象となる要素です。

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

リダイレクトパターンの良い例と悪い例

特に良い例: example.com はレスポンシブなウェブデザインを使用し、リダイレクトは必要としない
良い例: example.com -> m.example.com/home
悪い例: example.com -> www.example.com -> m.example.com -> m.example.com/home

Googleは3つのタイプのモバイルサイト構成をサポートしています。

1. レスポンシブ・ウェブデザイン（同じURLと1つのHTML/CSS）
2. 動的な配信（同じURLと別々のHTML/CSS）
3. モバイル専用のURL（異なるURLと別々のHTML/CSS）

Googleが、一番推奨する方法が、3.レスポンシブwebデザインです。

■タップターゲットのサイズを適切に調整する

特定のタップターゲット（ボタン、リンク、フォームのフィールドなど）が小さすぎたり、互いに近すぎたりするために、タッチスクリーンがタップしにくくないか。

推奨される解決方法

・サイト上で最も重要なタップターゲット（ユーザーが最も頻繁に使用するもの）は、高さと幅を 48 CSS ピクセル以上にする。（ビューポートを正しく設定済みと仮定した場合）。

・使用頻度の低いリンクは、それより小さくてもかまわないが、リンク同士や他のリンク群との間にスペースを確保し、10 ミリの指の腹で誤って両方のリンクを一度に押してしまうことのないようにする。

■プラグインを使用しない

推奨される解決方法

以前はプラグインが必要だったコンテンツのほとんどは、現在はネイティブなウェブ技術を使って作成できます。たとえば、音声と動画、最先端のグラフィックスやプレゼンテーション効果、ネットワーク接続、ローカルストレージ、ファイルアクセスなどに対する最高水準のサポートが必要なコンテンツです。これらのウェブプラットフォームの機能を使用すれば、リッチコンテンツをすべての端末からアクセス可能にすることができます。

動画プレーヤーなどについて、Flashなどを使用せずに、HTML5のvidepタグ等を使用します。

■ビューポートを設定する

適切なビューポートを指定する。

推奨される解決方法

携帯端末に適切に表示されるよう最に、ドキュメントの先頭に width=device-width、initial-scale=1 を指定したメタビューポートが含めます。

<meta name=viewport content="width=device-width, initial-scale=1">

■コンテンツのサイズをビューポートに合わせる

ページのコンテンツが、指定されたビューポートサイズ内に水平に収まるようにします。

推奨される解決方法

画面サイズは端末によって大きく異なるため（携帯電話とタブレットの違い、携帯電話の機種の違いなど）、さまざまな端末でページが正しく表示されるようにビューポートを設定します。

■読みやすいフォントサイズを使用する

ページ内のテキストが小さすぎて読みにくくないこと。

推奨される解決方法

さまざまな端末で、フォントが期待どおりに拡大縮小されるように、ビューポートを設定します。

ビューポートを設定したら、以下の追加の推奨事項を実装します。

1. 16 CSS ピクセルの基本フォントサイズを使用します。使用するフォントのプロパティに基づいて、必要に応じてサイズを調整します。
2. 基本サイズに対して相対的なサイズを使って、フォントの拡大縮小を定義します。
3. テキストは文字間に縦方向のスペースが必要であり、フォントごとに調整する必要がある場合があります。一般的には、ブラウザのデフォルトの行の高さ 1.2 em をおすすめします。
4. 使用されるフォントの数と拡大縮小を制限します。フォントの種類やサイズが多すぎると、乱雑で複雑すぎるページレイアウトになります。

基本フォントサイズは16px、行間は1.2em。フォントの種類やサイズは限定したほうがよいとされています。

4 月 21 日より、Google 検索ランキングを決める要素の 1 つに、サイトがモバイル向けかどうかが含まれます。
サイトがあらゆるモバイル端末に最適化されているかどうかをチェックするには、モバイルフレンドリーテストをご利用します。

モバイルフレンドリーテスト
http://www.google.com/webmasters/tools/mobile-friendly/?hl=ja

スクロールしないで見ることができる画面の領域、いわゆるAbove the foldのコンテンツを1秒未満で表示することをGoogleは推奨しています。

Above the foldのコンテンツ表示のスピードアップに役立つ3つのテクニック
・Above the foldのコンテンツに適用するCSSは外部参照させずにインライン化

・外部参照のCSSファイルは1つだけにする（HTTPリクエストで生じるレイテンシーを削減するため）

・JavaScriptの読み込みを延ばす

参考
https://www.suzukikenichi.com/blog/3-techniques-to-speed-up-loading-above-the-fold-content/

以上、Googleのデベロッパーページとアナウンスから、サイトの高速化と、SEO最適化につながる要素とその対策方法についてまとめてみましたが、現実的なサイトの運用においては、サーバー環境、サイトの性質から、これらを100%クリアすることは難しいでしょう。

ただ、これらのGoogleテスターツールで解析して、出来うる範囲でチューニングをすることは、サイトの高速化、ユーザビリティーにもつながりますから、それが良質なサイトとして検索結果に反映されるのは、現実に即しているといえるでしょう。