サーバ通信の設定による高速化

サーバ設定による高速化

高速化の手段は様々ある

AMP化や次世代フォーマットの画像を使用するといった、物理的なファイルを軽量化する手段だけではなく、サーバの通信方法や出力をチューニングする事でも、サイトのレスポンスを向上させることができます。

ソフトウェアやハードウェアに関する高速化は別途「爆速サイトの作り方」でも解説しているので、そちらも併せて御覧ください。

gzipの導入

物理的にファイルサイズを圧縮したり、そもそもシンプルなコンテンツに作り替える手法も、Google Page Speed Insightにおいても推奨されている項目ではありますが、大本のサーバ設定において、通信方式にgzipを導入することも高速化させる為の有効な手段になります。

このgzipは、Apacheであればmod_deflateというオプションモジュールを導入することにより実装可能です。
少し難しい話になりますが、.htaccessといったファイルに、以下のような記述をしておくと、適切なモジュールがインストールされているサーバに限り、gzipを簡単に組み込む事が出来ます。

<IfModule mod_deflate.c>
SetOutputFilter DEFLATE

# Mozilla4系などの古いブラウザで無効、しかしMSIEは除外
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

# gifやjpgなど圧縮済みのコンテンツは再圧縮しない
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI _\.utxt$ no-gzip

# htmlやcssなどは圧縮
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom_xml
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
</IfModule>

また、Apacheと双璧をなす、NginxではデフォルトでgzipのHTTP圧縮通信に対応しており、nginx.confにおいて、

gzip on;
gzip_types image/png image/gif image/jpeg text/javascript text/css;

といった記述することでも簡単に導入することができます。

どういった仕組みか

改めての解説となりますが、gzipはサイト上のコンテンツを圧縮して、転送量を減らすことで高速表示を可能にするモジュールです。
転送量が減る反面、CPUの処理が増えるため、処理能力にボトルネックがある場合は逆にレスポンス速度が低下してしまう恐れがあります。

圧縮といえば、普段身近にあるものとして、zip形式やtgz形式のファイルがあります。
これらの圧縮技術と同様で、クライアントからホストサーバにリクエストが行われた際、サーバ上で予めコンテンツを圧縮して、返送の際にはクライアントに圧縮されたデータを戻すといった仕組みになります。

ホストサーバでは圧縮処理が行われることになるので、大量のリクエストが発生する場合は、むしろレスポンス低下を招くことになりますが、極端に質の低い共有サーバといったサービスを使用していない限り、パフォーマンスは向上します。

Google PageSpeed Insightにより評価される項目の1つ

何より注目するべきところは、サイトにgzipが導入されていると、Google PageSpeed Insightで評価される点です。

Enable text compression

通信量が減るということは、ファイル容量が減ることと同じことなので、適切にgzipが導入されていれば、当然通信スピードが早くなります。
しかしながら、Googleは【First Contentful Paint(以下FCP)】も評価基準の1つとしており、サーバへの問い合わせ後、何らかのコンテンツがクライアント側に始めて表示されるタイミングも重要視しているのです。
gzip処理をおこなうことにより、サーバに大きな負荷が掛かってしまうと、そもそも初回レンダリングが遅くなってしまう可能性があるので、FCPが遅くなってしまうようであれば、導入は控えたほうが良いと考えられます。

Browser Cachingの導入

通信量を削減するもう1つのサーバ設定手段として、Browser Cachingの導入が挙げられます。

gzipと同様にGoogle PageSpeed Insightで改善が要求される重要な項目の1つです。
しかしながら、gzipと大きく異る点として、Browser Cachingはサーバ側にあまり負荷が掛かりません。

実装方法はWEBサーバがApacheの場合、.htaccessなどに処理を記載することで実現可能です。
以下にサンプルを載せますが、幾分強めのキャッシュ設定ですので適宜調整してください。

ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
また、WEBサーバがNginxであれば、nginx.confに以下のような記述を行います。

expires 10d;

どういった仕組みか

その名の通り、クライアント(ユーザー)側のブラウザにサイトコンテンツをキャッシュさせる技法です。
サーバサイドの設定でブラウザにリソースを保持させる期間を指定することになります。

しかしながら、これにもデメリットもあります。
指定期間の間は、ブラウザ側に保持されてるキャッシュデータを手動で消去しない限り、仮にサーバ側のコンテンツが更新されていたとしても、古いデータが表示されることになります。

リアルタイムにコンテンツを更新しているような情報配信サイトは、過度にキャッシュを効かせてしまうと不都合が生じる可能性があります。

gzipと同じくGoogle PageSpeed Insightにより評価

Browser Caching

Browser Cachingによってクライアント側でコンテンツデータが保持されることにより、2度目のアクセス以降、一定期間は送受信とサーバ処理自体が発生しませんので、確実にサイトの高速化が図れると言えるでしょう。

まとめ

データ通信量を最小限に抑えることは、回線速度を強化するよりも効率的ではありますが、何も考えずにgzipやBrowser Cachingを導入すれば良いというわけではありません。
その特色や仕組み、メリット・デメリットを理解した上で、導入前と導入後のサーバレスポンスや通信負荷をしっかりと確認することが必要となります。
適切なサーバ設定で最大限の通信パフォーマンスを発揮できるようにチューニングを行えるように経験を積みましょう。

当サイトの運営者。
主にSEO、SXO、Googleの考え方について、現場での経験をもとに、どのように対策を行えば良いかを具体的に解説できるよう努めています。詳しくはプロフィールをご覧ください。

記事が気に入ったらシェアをお願いします!

, , , , , , ,