本記事のゴール
サイトやサービスのユーザーの体験をユーザーエクスペリエンス (UX) と読んだりしますが、UX の観点からサイトの表示速度は重要なファクターかと思います。本記事では、AWS 上で構築した WordPress サイトの表示速度を上げるためのチューニングについてまとめます。
サイトの表示速度の計測
サイトの表示速度を上げる前に、そもそもサイトの表示速度を計測する必要があります。本記事では、Google 社が提供している、PageSpeed Insights を使います。
早速測定していきましょう。公開しているサイト、ページの URL を入力すれば、測定可能です。
モバイル、PC それぞれで表示速度が計測されますが、左がモバイルでの現状の表示速度、右がパソコンでの現在の表示速度となります。
また、このように「改造できる項目」ということでサイト表示速度改善のためのサジェストも出てきます。
本記事ではこちらのサジェストに従ってチューニングを進めてみます。
事前準備
すぐにチューニングに取り掛かりたいところなのですが、CloudFront でキャッシュをしていると、キャッシュの影響でうまく速度が計測できない可能性があるので、ここで CloudFront でのキャッシュを一時的に無効にします。
CloudFrontのディストリビューションを選択していただいて、「Behaviors」で、「Default(*)」を選択、「Edit」で編集します。
「Cache Based on selected Request Headers」を「All」に変更してください。これでキャッシュを無効化できます。
レンダリングを妨げるリソースの除外
今回ボトルネックになったこちらの対処から進めていきます。ツール上では、
ページの First Paint をリソースがブロックしています。重要な JavaScript や CSS はインラインで配信し、それ以外の JavaScript やスタイルはすべて遅らせることをご検討ください。
https://developers.google.com/speed/pagespeed/insights/
と表示されています。
したがって、CSS のインライン配信、遅延読込ができるプラグイン、Autoptimize を導入していきます。
いつものようにインストールして有効化します。
さっそくAutoptimize の設定を見ていきましょう。まずは「JavaScript オプション」。
「JavaScript コードの最適化」にチェックを入れ、「JS ファイルを連結する」にチェックを入れてみました。
次に、「CSS オプション」。
「CSS コードを最適化」にチェックを入れ、「CSS ファイルを連結する」、「インラインの CSS も連結」の 2 つにチェックしました。なお、「CSS のインライン化と遅延」にもチェックを入れ、Critical Path CSS Generator を使ってファーストビュー CSS を取得し設定してみたりもしてみましたが、たしかに効果は高いものの支配的ではなく、なおかつ一部の CSS がどうしても遅れて読み込まれる関係でサイトの表示が良くなかったので、今回はチェックから外すことにしました。
なお、今回最も効果があったのは「追加」タブの設定で、
このように「Google フォントの削除」と「絵文字の削除」を行いました (絵文字等使う予定があれば、「CSS のインライン化と遅延」を検討ください。詳細はこちら)。
ここで再度 PageSpeed Insights で計測すると (左がモバイル、右が PC)、
おお、早速なかなかの改善！レンダリングを妨げるリソースの除外項目が既にボトルネックではなくなっています。
テキスト圧縮の有効化
今度は、「テキスト圧縮の有効化」についてです。こちらは Nginx 側で対応が可能です。
サーバーに SSH でログインいただき、いつものようにスーパーユーザーになってください。その上で、/etc/nginx/nginx.conf を以下のように編集していきます。
...
http {
...
server {
...
}
gzip on;
gzip_comp_level 6;
gzip_proxied any;
gzip_proxied expired no-cache no-store private auth;
gzip_vary on;
gzip_min_length 1000;
gzip_disable "MSIE [1-6]\.";
gzip_types text/plain text/css text/xml text/javascript application/json application/javascript application/x-javascript application/xml application/rss+xml application/atom+xml image/x-ms-bmp image/svg+xml;
}細かい説明は割愛しますが、Nginx で gzip による圧縮を有効にするには、上記のような設定を加えておけば OK かと思います。
設定を変更したら、Nginx を再起動してください。
# systemctl restart nginxこの設定を加えた後の結果がこちら (あいも変わらず左がモバイル、右が PC)。
モバイルが 74 点と、だいぶ改善してきました。PC は 94 点と、圧縮を有効にする前と比べると悪化です・・。
PC のスコアが悪くなるとはいっても、gzip 圧縮の有効化は強くオススメです。といいますのも、AWS からデータが転送される際に料金が発生するのですが、gzip 圧縮しておくことでその転送料が抑えられるためです。
最初のサーバー応答速度を速くしてください
こちらについては、Nginx のproxy cache と FastCGI を使って WordPress の投稿、固定ページを始めとした動的コンテンツをキャッシュすることで高速化を図ります。
まず、/etc/nginx/nginx.conf を、以下のように追記します。
...
http {
...
server {
...
# location ~* /wp-config.php {
# deny all;
# }
include conf.d/wordpress.conf;
}
...
fastcgi_buffers 8 64k;
fastcgi_buffer_size 64k;
fastcgi_connect_timeout 60;
fastcgi_send_timeout 60;
fastcgi_read_timeout 300;
fastcgi_cache_path /var/lib/nginx/cache/worklog.be levels=1:2 keys_zone=worklog:18m inactive=5m max_size=10g;
proxy_cache_path /var/lib/nginx/cache/proxy.worklog.be levels=1:2 keys_zone=proxy_worklog:18m inactive=5m max_size=10g;
}また、/etc/nginx/conf.d/wordpress.conf を設けます。それに伴い、/wp-config.php へのアクセス拒否の設定はコメントアウトしている点に注意してください。
index index.php;
error_page 404 /index.php?error=404;
set $is_mobile '';
if ($http_user_agent ~* '(Mobile|Android|Silk/|Kindle|BlackBerry|Opera\sMini|Opera\sMobi)') {
set $is_mobile 'mobile.';
}
if ($request_method != GET) {
set $do_not_cache 1;
}
if ($request_uri ~* '/(wp-admin/|wp-login.php|wp-cron.php|xmlrpc.php|\??feed|wp-json|sitemap.xml)') {
set $do_not_cache 1;
}
if ($http_cookie ~* 'comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in') {
set $do_not_cache 1;
}
location ~* \.(jpg|jpeg|gif|png|css|js|swf|ico|pdf|svg|eot|ttf|woff)$ {
expires 60d;
access_log off;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
set $do_not_cache 0;
set $keys_zone worklog;
location ~ \.php {
try_files $uri /index.php;
include fastcgi_params;
fastcgi_pass unix:/var/run/php-fpm/www.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_no_cache $do_not_cache;
fastcgi_cache_bypass $do_not_cache;
fastcgi_cache $keys_zone;
fastcgi_cache_key $is_mobile$scheme://$host$request_uri;
fastcgi_cache_valid 200 5m;
fastcgi_cache_valid 301 302 1h;
fastcgi_cache_valid 404 1m;
fastcgi_cache_valid any 1s;
}
location ~* /wp-config.php {
deny all;
}このように、キャッシュするパスとキャッシュしないパスを事細かく書き分けていきます。
上記設定できましたら、キャッシュを保管するためのディレクトリを予め作成しておき、さらに所有権を nginx グループの nginx ユーザに変更しておきます。
# mkdir /var/lib/nginx/cache
# chown -R nginx:nginx /var/lib/nginxそうしまたら、Nginx を再起動します。
# systemctl restart nginx再び、パフォーマンス測定へ。今回は動的コンテンツのキャッシュを有効にしたということで、キャッシュの有効性確認のためにパフォーマンス測定を 2 度流して測定します。
ご覧のとおり、モバイルで 85 点、PC では既に 98 点を達成しました。
次世代フォーマットでの画像の配信
私も画像は PNG で作成していたのですが、画像の圧縮率の関係で次世代フォーマットの画像の方が望ましいということで、変更します。本記事では既にアップロードされているものも含めて WordPress 上の JPEG/PNG 画像を次世代フォーマット WebP へ変更する手順について解説します。
本記事では、無償でお手軽に使えそうな WebP Express プラグインを使用します。
いつものようにインストール、有効化します。
その後、WebP Express の設定を「CDN friendly」に、Scope を「All content」にします。
「CDN friendly」モードにすることで、サーバー内の元画像を WebP に変換したものをサーバー内に保存、変換した画像ファイルを読ませることができます。このようにすることで、データ転送に係る時間を抑えるだけでなく、データ転送量を抑える (すなわち、AWS でかかるデータ転送料を抑える) ことができるようになります。また、こちらの「CDN friendly」モードは、Nginx を利用している場合に推奨される方法でもあるようです。WebP Express でも他の WebP 変換プラグインと同様に .htaccess を生成する機能を活用することもできますが、Nginx では .htaccess は使えないので。
次に、WebP Express で画像の「Bulk Convert」、すなわち WebP への一斉変換を実行します。
Bulk Convert 中は、以下のような画面で次々と画像が変換されていくことが確認できるはずです。
画像が変換できたら、Alter HTML でHTML を変換します。
以上で次世代画像フォーマットへの対応は完了です。再度、PageSpeed Insight で測定してみましょう。
ありゃりゃ。今度はパフォーマンスが劣化しました。パフォーマンスに特に変わりはありませんでした。
次世代画像フォーマットへの対応は、ご覧の通り、筆者の対応ではむしろパフォーマンスが下がる結果となりました。ただ、データ転送料を減らすことができる明確なメリットがあるので、筆者としてはこのままの設定としたいと考えています。
ネクストアクション
いかがだったでしょうか。次回は、WordPress サイトをレンタルサーバーで構築するか、AWS で構築するかの比較論を行いたいと思います。
