背景

元々、文字データはそのままネットワーク上を流れていました。最大の理由はネットワークの通信量が大きくなかったこと、コンピュータの性能が悪く、圧縮、解凍に時間がかかるため、圧縮、解凍してデータを送受信するよりもそのまま送受信したほうが効率的だったからです。

また今のように1台のサーバに多数のPCが接続するような形ではなく、それぞれのコンピュータ同士が1対1で通信するような形が主でした。そのためネットワークの帯域(送れるデータ量)が小さくても1台1台にとっては十分なデータ量でした。圧縮してデータの送受信をしようとしても、コンピュータ側にそのための性能もありませんでした。主なデータはhtmlとcssくらいでした。

しかし現在のPCやスマートフォン、レンタルサーバは十分な性能があります。1台のサーバに複数の接続があり、次々とデータの要求をされます。javascriptで作成されたアプリケーションやライブラリなど1つ1つのデータ量が多いコンテンツが増え、その一方、データを送るネットワークやルータには十分な帯域がありません。

最近5Gが騒がれていますが、サーバからスマートフォンにデータを送る際に、5G回線を通っても、その途中でどこか1箇所でも帯域が細い回線があれば、細い回線の通信速度しか出ません。

一方、サーバの方は、CPUの1コアあたりの処理性能向上に加え多コア化、httpサービスの処理方式変更によりC10K問題が解決され多くのリクエストをさばけるようになりました。

その結果としてネットワーク通信帯域がボトルネックとなってきます。そのためデータ容量をコンパクトにする必要があります。

画像については「次世代フォーマットでの画像の配信」や「効率的な画像フォーマット」によりデータ量を削減できることを以前の記事で述べました。

画像データが小さくなると残りはテキストデータということになります。画像データは元々圧縮されているためよいのですが、テキストデータはそのままだと、圧縮されずにネットワークを流れることになります。このテキストデータを圧縮すると、元のテキストデータと比べ小さなデータ量になります。

テキストデータ量が減った分、データ転送を完了するまでの時間が短くなり利用者の待ち時間も短くなり高速にWebページが表示されるようになります。

↑目次

減少するデータ量

テキストデータを圧縮すると実際にどの程度の時間短縮になるのかを確認してみます。以下はPageSpeed Insightsに表示されていた内容です。

上記のswiper.jsはスマートフォンのスワイプ操作に対応するためのjavascriptプログラムです。234.5KiBの容量がありますが圧縮することで191.4KiBの容量が削減できます。swiper.jsの容量は234.5⇒43.1KiBになります。javascriptやcss、htmlのテキストコンテンツを圧縮するでけで、データ量を元データの2割以下にまで減らすことができます。テキスト圧縮の有効性がお分かりいただけるとおもいます。

次にテキスト圧縮の設定について述べます。

↑目次

テキスト圧縮時のブラウザとサーバのやりとり

テキスト圧縮をおこなうにはサーバ側でテキスト圧縮を有効にする必要があります。ブラウザはサーバにWebページのデータを要求する際に、例えば以下のようにブラウザで対応している圧縮形式を指定します。
 

Accept-Encoding: gzip, deflate, br

サーバはブラウザが対応する中からサーバで対応できる圧縮形式で圧縮し、どの形式で圧縮したかがわかるようにしてブラウザにデータを返します。

 

Content-Encoding: gzip

 

ウイルスチェックソフトがインストールされていると、ウイルスチェックソフトで圧縮データが解凍され、解凍後のデータがブラウザに表示される場合があります。その場合にはレスポンスのヘッダが以下のように書き換えられることがあります。

x-content-encoding-over-network: gzip

↑目次

どの圧縮形式を用いるか

ブラウザが対応しているの圧縮形式のうちサーバで対応できている圧縮形式を使うのが楽です。まず最優先で考えたいのがbr、次点でgzip、それ以外がdeflateとなります。

brはGoogleが開発した次世代のテキスト圧縮技術です。gzipよりも高速かつコンパクトにテキストコンテンツを圧縮することが可能になっています。

brがいくら高速、高圧縮にテキストデータを圧縮できるとしても、最新の技術のためサーバ側で対応していない事もあります。apacheの場合にはmod_brotliを有効化できれば、brでの配信が可能になります。

brに対応していないサーバでは事前にコンテンツをbrotli形式やgzipで圧縮しリクエストヘッダにより圧縮済みのファイルにリクエストを書き換えて配信する方法があります。

↑目次

サーバでの設定例

ここではmod_brotliが有効化されていないサーバでの設定例を述べます。方針は以下の通りになります。

1. 事前にgzip(拡張子.gz)やbrotli(拡張子.brotli)で圧縮したファイルを「元々のファイル名」+「圧縮拡張子」の形で同じフォルダに格納
2. ブラウザからのリクエストヘッダのAccept-Encodingの値を見て読み込むファイルの拡張子(bortoliかgzかオリジナルか)を決める
3. 拡張子の条件から元々のリクエストファイル名をリクエストファイル名+圧縮拡張子に書き換える
4. Accept-Encodingの値によってキャッシュは分けておく

上記をhtml拡張子のファイルのみに限って書くと以下のようになります。

<IfModule rewrite_module="">
<IfModule headers_module="">

RewriteEngine on

# Brotli
RewriteCond %{HTTP:Accept-Encoding} br
RewriteCond %{REQUEST_URI} \.html$
RewriteCond %{REQUEST_FILENAME}\.brotli -s
RewriteRule .* %{REQUEST_URI}.brotli [L]

<Files *.html.brotli>
Header set Content-Encoding br
ForceType text/html
</Files>

# gzip
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_URI} \.html$
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule .* %{REQUEST_URI}.gz [L]

<Files *.html.gz>
Header set Content-Encoding gzip
ForceType text/html
</Files>

# Vary
<FilesMatch>
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>
</IfModule>

 

同様にcssやjavascriptについても事前に圧縮しておき上記のようにrewiteすることで圧縮転送できるようになります。

CMSの場合にはデフォルト設定が圧縮ありになっていることもあります。また圧縮配信用のプラグインがある場合もあります。レンタルサーバについては、運営会社によりデフォルトの設定が異なるため「CMS名」 + 「Content-Encoding」や「CMS名」 + 「テキスト圧縮」 + 「レンタルサーバのサービス名」 などで調べてみてください。

↑目次

動作確認

実際に圧縮した状態で送信されてきたかどうか確認するにはChromeの開発者ツールを用います。

「F12」キーをおして開発者ツールを起動後、Networkを選択します。その後Webページにアクセスすると取得してきたコンテンツが表示されます。

コンテンツを選択することで、Response Headersが表示されます。

※上記ではウイルスチェックソフトにてContent-Encodingがx-content-encoding-over-networkに書き換えられています。

↑目次

まとめ

テキスト圧縮をおこなうことで、データ容量を小さくしWebサイトからのデータ転送時間を短くすることができます。大きなjavascriptやcssを用いていると大きな効果が得られるためぜひ試してみてください。

↑目次