ホームページの高速化の意義 現在のグーグル検索順位を決定する基準の一つにホームページの高速表示は不可欠だ。表示が遅くて待たせることはユーザビリティとして適切ではないとグーグルは考えている。その他にも見た目のデザインやコンテンツの確かさ、有益な情報が入っているかが重要な順位を決める要因になりうる。
ホームページ高速化の優先順位 とりわけSEOとして考えていくなら第一にホームページの表示速度が重要で尚且つ、スマホの表示速度を優先度上げて考えるべきだ。理由として今の一般ユーザのアクセスの大半はスマホから来ているからなのです。
高速化の作業優先度を挙げるとしたら以下のような感じになるでしょう。
スマートフォンの高速化 画像の圧縮 javascriptの圧縮 CSSの圧縮 コンテンツがphp言語ならOPcacheを使ってコンパイル済みを共有メモリへロード DNSの応答高速化 サーバのキャッシュと転送の圧縮処理 ホスティング高速化 HTTP/2を使ったWEBサーバへ切り替え。もしくはフロントをHTTP/2で置き換え。バッックエンドはHTTP/1.xでもOK。 スマートフォンの高速化 スマートフォンの高速化は第一に画像の調整につきます。PCでは画像のサイズを気にせずとも、スマホでは様々な場所へ移動してしまうため、回線状態の悪いことも想定して遅い速度でも閲覧できるよう画像の最適化は重要です。
画像はサイズも大切ですが画像形式、圧縮の技術を考慮するべきです。さらに画像のサイズをPC、スマホ、タブレットで変えて準備すると高速に表示できるはずです。レスポンシブならmetaタグでviewportを指定してサイズに合わせたCSSを読み出すか、あるいはcssファイル側で@media only screen and (max-device-width : 480px)のようにデバイスのスクリーン幅に合わせて変形を決めることができます。
WORDPRESS等のCMSではこのような画像を自動で間引いたり、最適にCSSを調整してくれるpluginがあります。このようなプラグインを使ってPC用画像とスマホ用画像を別々に分けて作るのは大変良いことです。
画像の圧縮 WORDPRESSで利用できる主な画像最適化プラグインを下記に案内します。導入して使ってみてください。無料で使えるものもかなりありますが、概ね数に制限があります。ページ数だったり、画像の数などです。
また重要なのは、設定の際に他のプラグインでやっている機能を重複しないようにしてください。同じ処理を２回、３回やっても無駄なので。むしろ遅くなります。またキャッシュも設定を変更したら
一度キャッシュクリアしてから速度を測定しましょう。そうしないと古いキャッシュで速度測定することになります。
Compress JPEG & PNG images WP Smush EWWW Image Optimizer ※尚、WORDPRESSを使っていないサイトの場合は、専用ホスティングもしくは自前の専用サーバでLinuxやMacOSを使い圧縮することができます。
JPEG圧縮（jpegoptim） PNG圧縮（optipng） 【JPEGの圧縮ツールの導入】
#CentOS7.10の場合
# yum install epel-release
# yum --enablerepo=epel -y install jpegoptim
# Ubuintu/Debianの場合
# apt-get update
# apt-get install jpegoptim
【PNG圧縮ツールの導入】
# CentOS7の場合
yum -- enablerepo = epel - y install optipng
# Debian/Ubuntu
apt - get update
apt - get install optipng
【圧縮ツールの使い方】
#単体でファイルを亜朱する場合
# jpegoptim --strip-all ファイル名
# optipng ファイル名
#findで特定フォルダー配下をリカーシブに探索して圧縮を行う場合
# find ./ -name *.jpg -print | xargs jpegoptim --strip-all
# find ./ -name *.png -print | xargs optipng
主なキャッシュプラグイン キャッシュだけではなくHTML,CSS,Javascriptを圧縮したり、統合化をしてくれるものもあります。
Autoptimize Powered Cache W3 Total Cache WP Fastest Cache コンテンツがphp言語ならOPcacheを使ってコンパイル済みを共有メモリへロード PHPはスクリプトであるためリクエストごとにコンパイルをします。しかしこれだと時間がかかってしまいます。スクリプトを読むことなくパフォーマンスの向上を図るため、OPcacheを使うことで一度コンパイルしたコードをメモリー上に共有し再利用します。
# yum install php71 - php - opcache php71 - php - pecl - apcu -- enablerepo = remi - php71 , epel
# vi / etc / php . ini
下記を追加
zend_extension = / opt / remi / php71 / root / usr / lib64 / php / modules / opcache . so
[ opcache ]
opcache . enable = 1
opcache . enable_cli = 1
opcache . memory_consumption = 128
opcache . interned_strings_buffer = 8
opcache . max_accelerated_files = 4000
opcache . revalidate_freq = 60
opcache . fast_shutdown = 1
phpinfo() Or php -v によるZendクレジットで導入が確認できる Opcache導入が成功すると下記のクレジットが表示されます。
WEBサーバは再起動してください。コマンドラインではphp -vで確認できます。
This program makes use of the Zend Scripting Language Engine :
Zend Engine v3 . 1.0 , Copyright ( c ) 1998 - 2018 Zend Technologies
with Zend OPcache v7 . 1.30 , Copyright ( c ) 1999 - 2018 , by Zend Technologies
☆CentOSのバージョンによっては/etc/php.d/配下にxx-opcache.iniでopcache.soを指定するかもしれません。
☆Opcacheはphpの低いバージョンはダメ。おそらくphp5.6前後以上と思われる。
サーバの転送の圧縮処理とキャッシュ制御技術 Apache WEBサーバの転送はgzipで圧縮して転送を行うことが可能です。Apache2.4以前のバージョンではmod_deflateモジュールとを使ってAddOutputFilterByTypeでmimeフィルターする方法が途中まで主流でしたが既に廃れたやり方と言われています。
つまりdeflateモジュールをmod_filterを使ってmimeフィルターかけて圧縮することがApacheからも推奨されています。尚コンテンツ圧縮は転送量が減る反面、CPUの処理は増えるため、ボトルネックがCPUの処理能力の場合は逆にレスポンスが低下します。また、Apache2.4バージョン以降ではmod_filterを使うことが大前提でアナウンスされています。
結論を言ってしまうとどちらのバージョンでもmod_filterでFilterProviderでコンテンツタイプをフィルターして使うのですが若干記述に違いがありますので注意が必要です。
双方の処理ではDeflateCompressionLevel による圧縮レベルが指定できますが現実には、一番低いレベルの”１”で十分であります。レベルを上げても圧縮率が大して変わらないためCPUに余計な負荷を与えてしまい全体でみるとマイナスになってしまうからです。
Apache2.4以下の場合(つまりApache2.2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
FilterDeclare COMPPRESS
DeflateCompressionLevel 1
< Directory "/var/www/vhosts/test.servers.net" >
FilterProvider COMPRESS DEFLATE resp = Content - Type $ text / html
FilterProvider COMPRESS DEFLATE resp = Content - Type $ text / css
FilterProvider COMPRESS DEFLATE resp = Content - Type $ text / plain
FilterProvider COMPRESS DEFLATE resp = Content - Type $ text / xml
FilterProvider COMPRESS DEFLATE resp = Content - Type $ text / x - component
FilterProvider COMPRESS DEFLATE resp = Content - Type $ application / javascript
FilterProvider COMPRESS DEFLATE resp = Content - Type $ application / json
FilterProvider COMPRESS DEFLATE resp = Content - Type $ application / xml
FilterProvider COMPRESS DEFLATE resp = Content - Type $ application / xhtml + xml
FilterProvider COMPRESS DEFLATE resp = Content - Type $ application / rss + xml
FilterProvider COMPRESS DEFLATE resp = Content - Type $ application / atom + xml
FilterProvider COMPRESS DEFLATE resp = Content - Type $ application / vnd . ms - fontobject
FilterProvider COMPRESS DEFLATE resp = Content - Type $ application / x - font - ttf
FilterProvider COMPRESS DEFLATE resp = Content - Type $ image / svg + xml
FilterProvider COMPRESS DEFLATE resp = Content - Type $ image / vnd . microsoft . icon
FilterProvider COMPRESS DEFLATE resp = Content - Type $ font / opentype
FilterChain COMPRESS
FilterProtocol COMPRESS DEFLATE change = yes ; byteranges = no
< / Directory >
Apache2.4以上の場合
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
FilterDeclare COMPRESS
DeflateCompressionLevel 1
< Directory "/var/www/vhosts/test.servers.net" >
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m|^text/html|"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m|^text/css|"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m|^text/plain|"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m|^text/xml|"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m|^text/x-component|"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m|^application/javascript|"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m|^application/json|"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m|^application/xml|"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m|^application/xhtml+xml|"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m|^application/rss+xml|"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m|^application/atom+xml|"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m|^application/vnd.ms-fontobject|"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} = 'application/x-font-ttf'"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} = 'image/svg+xml'"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} = 'image/vnd.microsoft.icon'"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} = 'font/opentype'"
FilterChain COMPRESS
FilterProtocol COMPRESS DEFLATE change = yes ; byteranges = no
< / Directory >
上記を短くまとめると以下のようになります。
FilterDeclare COMPRESS
DeflateCompressionLevel 1
< Directory "/var/www/vhosts/test.servers.net" >
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m#^text/#i"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m#^application/(javascript|json|xml|xhtml\+xml|rss\+xml|atom\+xml|rss\+xml|vnd\.ms\-fontobject|x\-font\-ttf)#i"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m#^image/(svg\+xml|vnd\.microsoft\.icon)#i"
FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} = 'font/opentype'"
FilterChain COMPRESS
FilterProtocol COMPRESS DEFLATE change = yes ; byteranges = no
< / Directory >
<<注意点モジュールの確認>> 下記のモジュールが予めコメントが外れていることを確認しましょう。
LoadModule deflate_module modules / mod_deflate . so
LoadModule filter_module modules / mod_filter . so
以上の記述とチェックが終わったらWEBサーバを再起動して圧縮の確認を行ってください。
WEBサイトの圧縮レベルを確認するサイト キャッシュの処理 ブラウザ側にキャッシュをさせるタイマーをサーバー側で設定できるのがmod_expireになります。あくまでもキャッシュなので
必ず１回目のページアクセスは遅いということを理解しておきましょう。タイマーが切れたタイミングでWEBサーバにコンテンツを取りに行きます。
尚、予めmod_expireモジュールのコメント外れていることを必ず確認してください。
ExpiresActive On
ExpiresDefault “access plus 1 seconds ”
ExpiresByType text / html “access plus 1 seconds ”
ExpiresByType image / gif “access plus 2592000 seconds ”
ExpiresByType image / jpeg “access plus 2592000 seconds ”
ExpiresByType image / png “access plus 2592000 seconds ”
ExpiresByType image / x - icon “access plus 2592000 seconds ”
ExpiresByType text / css “access plus 604800 seconds ”
ExpiresByType text / javascript “access plus 216000 seconds ”
ExpiresByType application / x - javascript “access plus 216000 seconds ”
ExpiresByType application / x - shockwave - flash “access plus 216000 seconds ”
DNSの高速化とサーバホスティングの高速化 最近のクラウド、VPSなどの専用サーバホスティングは高速DNSサーバを備えているケースが多く、自前でDNSを用意するよりもいいかもしれません。インターネット上のジオメトリック的にDNSが有利にキャッシュされ盥回しされるため応答が早くなる可能性が高いと思います。
また、VPSもクラウドも専用サーバホスティングの世界ではHDDタイプとSSDタイプに選択肢が別れているものも当たり前になってきています。ネットワークの太い回線帯域を持っている方が圧倒的にサイトの表示は早いのでサーバスペック（コアの数）よりは回線の太さが重要かもしれません。また処理によって書き込みが中程度に多いのならばSSDも良いと思います。
以前はSSDの信頼性も？がついてましたがかなり安全であることがわかってきました。流石に大容量はHDDにかなわないのですが、容量がそれほどいかないサイトならSSDで十分とも言えます。
過去に使って見てよかったホスティングをとりあえず案内します。
Amazon EC2 ｜ Amazon Lightsail Azure Google Cloud Conoha Kagoya VPS Web Arena Suite Prov4 
昨今、大人気のDockerですが、システムはもちろんのこと中でも教育用に使われる機会は多いのではないかと感じます。WORDPRESSやLinux、各種言語の環境を素早く整えるために便利だと感じます。
h2oを使ってみようと思った理由はHTTP/2.xで通信できることかな。最近のGoogle検索順位は早さも大切な評価ウェイトをしめているためサイトの速度アップは重要なことです。
