Ubuntu16.04でNginxのヘッダーモジュールを使用してブラウザキャッシュを実装する方法
序章
Webサイトの読み込みが速いほど、訪問者が滞在する可能性が高くなります。 ウェブサイトが画像でいっぱいで、バックグラウンドでロードされたスクリプトによって実行されるインタラクティブなコンテンツである場合、ウェブサイトを開くことは簡単な作業ではありません。 これは、サーバーから1つずつ多くの異なるファイルを要求することで構成されます。 これらのリクエストの量を最小限に抑えることは、Webサイトを高速化する1つの方法です。
これはさまざまな方法で実行できますが、実行する最も重要な手順の1つは、ブラウザーのキャッシュを構成することです。 これは、一度ダウンロードしたファイルをサーバーに何度も要求する代わりに、ローカルコピーから再利用できることをブラウザに通知しています。 これを行うには、ブラウザに動作方法を指示する新しいHTTP応答ヘッダーを導入する必要があります。
ここで、Nginxのヘッダーモジュールが機能します。 このモジュールを使用して、任意のヘッダーを応答に追加できますが、その主な役割は、キャッシュヘッダーを適切に設定することです。 このチュートリアルでは、Nginxのヘッダーモジュールを使用してブラウザのキャッシュを実装する方法を見ていきます。
前提条件
このチュートリアルに従うには、次のものが必要です。
-
この初期サーバーセットアップチュートリアルでセットアップされた1つのUbuntu16.04サーバー(sudo非rootユーザーを含む)。
-
Ubuntu 16.04チュートリアルにNginxをインストールする方法に従って、サーバーにNginxをインストールします。
この記事では、ヘッダーモジュールに加えて、Nginxのマップモジュールも使用します。 マップモジュールの詳細については、 Ubuntu16.04でNginxのマップモジュールを使用する方法をご覧ください。
ステップ1—テストファイルの作成
このステップでは、デフォルトのNginxディレクトリにいくつかのテストファイルを作成します。 後でこれらのファイルを使用して、Nginxのデフォルトの動作を確認し、ブラウザーのキャッシュが機能していることをテストします。
ネットワーク上で提供されるファイルの種類を決定するために、Nginxはファイルの内容を分析しません。 それは法外に遅いでしょう。 代わりに、ファイル拡張子を検索して、ファイルの目的を示すファイルのMIMEタイプを判別します。
この動作のため、テストファイルの内容は関係ありません。 ファイルに適切な名前を付けることで、たとえば、完全に空のファイルの1つが画像で、もう1つがスタイルシートであるとNginxを騙して考えることができます。
名前の付いたファイルを作成します test.html
デフォルトのNginxディレクトリで truncate
. この拡張機能は、それがHTMLページであることを示します。
- sudo truncate -s 1k /var/www/html/test.html
同じ方法でさらにいくつかのテストファイルを作成しましょう:1つ jpg
画像ファイル、1つ css
スタイルシート、および1つ js
JavaScriptファイル。
- sudo truncate -s 1k /var/www/html/test.jpg
- sudo truncate -s 1k /var/www/html/test.css
- sudo truncate -s 1k /var/www/html/test.js
次のステップは、作成したばかりのファイルを使用して、新規インストールでキャッシュ制御ヘッダーを送信することに関してNginxがどのように動作するかを確認することです。
ステップ2—デフォルトの動作を確認する
デフォルトでは、すべてのファイルのデフォルトのキャッシュ動作は同じです。 これを調べるために、手順1で作成したHTMLファイルを使用しますが、これらのテストは任意のサンプルファイルで実行できます。
それでは、 test.html
ブラウザが応答をキャッシュする時間に関する情報が提供されます。 次のコマンドは、ローカルのNginxサーバーにファイルを要求し、応答ヘッダーを表示します。
- curl -I http://localhost/test.html
いくつかのHTTP応答ヘッダーが表示されます。
Output: Nginx response headersHTTP/1.1 200 OK
Server: nginx/1.10.0 (Ubuntu)
Date: Sat, 10 Sep 2016 13:12:26 GMT
Content-Type: text/html
Content-Length: 1024
Last-Modified: Sat, 10 Sep 2016 13:11:33 GMT
Connection: keep-alive
ETag: "57d40685-400"
Accept-Ranges: bytes
最後から2番目の行で、 ETag
ヘッダー。要求されたファイルのこの特定のリビジョンの一意の識別子が含まれます。 前を実行した場合 curl
コマンドを繰り返し実行すると、まったく同じものが表示されます ETag
価値。
Webブラウザを使用する場合、 ETag
値は保存され、サーバーに返送されます。 If-None-Match
ブラウザが同じファイルを再度要求する場合(たとえば、ページを更新する場合)にヘッダーを要求します。
次のコマンドを使用して、コマンドラインでこれをシミュレートできます。 必ず変更してください ETag
このコマンドの値は、 ETag
前の出力の値。
- curl -I -H 'If-None-Match: "57d40685-400"' http://localhost/test.html
これで、応答が異なります。
Output: Nginx response headersHTTP/1.1 304 Not Modified
Server: nginx/1.10.0 (Ubuntu)
Date: Sat, 10 Sep 2016 13:20:31 GMT
Last-Modified: Sat, 10 Sep 2016 13:11:33 GMT
Connection: keep-alive
ETag: "57d40685-400"
今回、Nginxは 304 NotModifiedで応答します。 ネットワーク経由でファイルを再度送信することはありません。 代わりに、ローカルでダウンロード済みのファイルを再利用できることをブラウザに通知します。
これはネットワークトラフィックを減らすので便利ですが、優れたキャッシュパフォーマンスを達成するには十分ではありません。 の問題 ETag
つまり、ブラウザ常には、キャッシュされたファイルを再利用できるかどうかを尋ねるリクエストをサーバーに送信します。 サーバーがファイルを再送信する代わりに304で応答したとしても、要求を行って応答を受信するのに時間がかかります。
次のステップでは、headersモジュールを使用してキャッシュ制御情報を追加します。 これにより、ブラウザは、サーバーに明示的にキャッシュするかどうかを明示的に要求することなく、一部のファイルをローカルにキャッシュできるようになります。
ステップ3—Cache-ControlおよびExpiresヘッダーの構成
に加えて ETag
ファイル検証ヘッダーには、2つのキャッシュ制御応答ヘッダーがあります。 Cache-Control
と Expires
. Cache-Control
は新しいバージョンであり、より多くのオプションがあります Expires
また、キャッシュの動作をより細かく制御したい場合は、一般的に便利です。
これらのヘッダーが設定されている場合、要求されたファイルを再度要求することなく、一定期間(永久を含む)ローカルに保持できることをブラウザーに通知できます。 ヘッダーが設定されていない場合、ブラウザは常にサーバーにファイルを要求し、 200OKまたは304NotModifiedの応答を期待します。
ヘッダーモジュールを使用して、これらのHTTPヘッダーを設定できます。 ヘッダーモジュールはコアNginxモジュールです。つまり、使用するために個別にインストールする必要はありません。
ヘッダーモジュールを追加するには、でデフォルトのNginx構成ファイルを開きます。 nano
またはお気に入りのテキストエディタ。
- sudo nano /etc/nginx/sites-available/default
を見つける server
次のような構成ブロック:
. . .
# Default server configuration
#
server {
listen 80 default_server;
listen [::]:80 default_server;
. . .
ここに次の2つの新しいセクションを追加します。 server
ブロック、さまざまなファイルタイプをキャッシュする期間を定義し、その中に1つを定義して、キャッシュヘッダーを適切に設定します。
. . .
# Default server configuration
#
# Expires map
map $sent_http_content_type $expires {
default off;
text/html epoch;
text/css max;
application/javascript max;
~image/ max;
}
server {
listen 80 default_server;
listen [::]:80 default_server;
expires $expires;
. . .
前のセクション server
ブロックは新しいです map
ファイルタイプとその種類のファイルをキャッシュする期間の間のマッピングを定義するブロック。
このマップでは、いくつかの異なる設定を使用しています。
-
デフォルト値はに設定されています
off
、これはキャッシュ制御ヘッダーを追加しません。 キャッシュがどのように機能するかについて特に要件がないコンテンツにとっては安全な賭けです。 -
為に
text/html
、値をに設定しますepoch
. これは特別な値であり、明示的にキャッシュが発生しないため、ブラウザはWebサイト自体が最新であるかどうかを常に確認します。 -
為に
text/css
とapplication/javascript
、スタイルシートとJavascriptファイルであり、値を次のように設定します。max
. これは、ブラウザがこれらのファイルを可能な限りキャッシュすることを意味し、通常これらのファイルが多数あることを考えると、リクエストの量を大幅に削減します。 -
最後の設定は
~image/
、これは、を含むすべてのファイルタイプに一致する正規表現です。image/
MIMEタイプ名(image/jpg
とimage/png
). スタイルシートのように、安全にキャッシュできるWebサイトには多くの画像があるため、これを次のように設定します。max
同じように。
サーバーブロック内では、 expires
ディレクティブ(ヘッダーモジュールの一部)は、キャッシング制御ヘッダーを設定します。 からの値を使用します $expires
マップに設定された変数。 このように、結果のヘッダーはファイルタイプによって異なります。
ファイルを保存して閉じ、終了します。
新しい構成を有効にするには、Nginxを再起動します。
- sudo systemctl restart nginx
次に、新しい構成が機能することを確認しましょう。
ステップ4—ブラウザキャッシュのテスト
テストHTMLファイルに対して前と同じリクエストを実行します。
- curl -I http://localhost/test.html
今回は反応が異なります。 2つの追加のHTTP応答ヘッダーが表示されます。
HTTP/1.1 200 OK
Server: nginx/1.10.0 (Ubuntu)
Date: Sat, 10 Sep 2016 13:48:53 GMT
Content-Type: text/html
Content-Length: 1024
Last-Modified: Sat, 10 Sep 2016 13:11:33 GMT
Connection: keep-alive
ETag: "57d40685-400"
Expires: Thu, 01 Jan 1970 00:00:01 GMT
Cache-Control: no-cache
Accept-Ranges: bytes
The Expires
ヘッダーには過去の日付が表示され、 Cache-Control
で設定されています no-cache
、これは、ファイルの新しいバージョンがあるかどうかを常にサーバーに確認するようにブラウザに指示します( ETag
以前のようにヘッダー)。
テスト画像ファイルとの応答の違いが表示されます。
- curl -I http://localhost/test.jpg
HTTP/1.1 200 OK
Server: nginx/1.10.0 (Ubuntu)
Date: Sat, 10 Sep 2016 13:50:41 GMT
Content-Type: image/jpeg
Content-Length: 1024
Last-Modified: Sat, 10 Sep 2016 13:11:36 GMT
Connection: keep-alive
ETag: "57d40688-400"
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Accept-Ranges: bytes
この場合、 Expires
遠い将来の日付を示し、 Cache-Control
含む max-age
情報。これは、ファイルを秒単位でキャッシュできる時間をブラウザに通知します。 これにより、ダウンロードされた画像を可能な限りキャッシュするようにブラウザに指示されるため、この画像がその後表示されると、ローカルキャッシュが使用され、サーバーにリクエストが送信されなくなります。
結果は両方で同様になるはずです test.js
と test.css
、JavaScriptファイルとスタイルシートファイルの両方にキャッシュヘッダーも設定されているため。
これは、キャッシュ制御ヘッダーが適切に構成されていることを意味し、ブラウザーのキャッシュによるパフォーマンスの向上とサーバー要求の減少により、Webサイトが恩恵を受けます。 Webサイトのコンテンツに基づいてキャッシュ設定をカスタマイズする必要がありますが、この記事のデフォルトから始めるのが妥当です。
結論
ヘッダーモジュールを使用して、任意のヘッダーを応答に追加できますが、キャッシング制御ヘッダーを適切に設定することは、その最も有用なアプリケーションの1つです。 これにより、特に携帯電話会社のネットワークなど、待ち時間が長いネットワークで、Webサイトユーザーのパフォーマンスが向上します。 また、速度テストを結果に織り込む検索エンジンでより良い結果をもたらす可能性があります。 ブラウザのキャッシュヘッダーの設定は、GoogleのPageSpeedテストツールからの主要な推奨事項の1つです。
ヘッダーモジュールの詳細については、Nginxの公式ヘッダーモジュールドキュメントをご覧ください。