前書き
Nginxは、ウェブページのリクエストの処理に優れていますが、ウェブページは高速に見える場合でも、デフォルトのNginx構成により、GoogleのPageSpeed Insightsツールがサイトの非効率性にフラグを立て、評価が低くなります。 Googleは、サイトの速度をサイトの検索位置を決定する重要な要素として使用します。
このチュートリアルでは、ドメインの構成ファイルをすばやく編集して、サイトの応答速度とそのPageSpeedメトリックを瞬時に向上させます。 目標は、80/100を超えるスコアを達成することです。これは、Googleがあなたのスコアに緑色のマーカーを適用し、高速サイトを知らせるしきい値を超えるためです。
まず、特定の種類のファイルに対してGzip圧縮を有効にします。 次に、ブラウザのキャッシングを構成して、さらにブーストします。 これらの方法は、Nginxで構築されているソフトウェアまたはCMSに関係なく、Nginxで実行されているサイトの速度を改善します。 たとえば、Wordpressの低速でパフォーマンスの低いインストールでは、コアのラインに触れたり、高価なパフォーマンスプラグインの費用を支払うことなく、即座に利益が得られます。 このアプローチは、サーバーがNginxであり、構成ファイルを編集できる限り、サイトが低電力の共有ホスティングで実行されている場合でも機能します。
前提条件
このチュートリアルを完了するには、次のものが必要です。
-
sudo非rootユーザーとファイアウォールを含むthis initial server setup tutorialでセットアップされた1つのUbuntu16.04サーバー。
-
How To Install Nginx on Ubuntu 16.04チュートリアルに従って、サーバーにNginxをインストールします。
[[step-1 -—- get-the-initial-pagespeed-score]] ==ステップ1—初期PageSpeedスコアを取得します
変更を行う前に、既存のPageSpeedスコアをキャプチャして、チュートリアルが完了したときに比較するパフォーマンスベースラインを用意します。 これを行うには、サイトのURLをGoogle’s PageSpeed Insights serviceに貼り付け、Run Insightsをクリックします。
次のような結果が表示されます。
この例では、サーバーで圧縮とブラウザーのキャッシュが正しく構成されていないため、モバイルで63、デスクトップで74という低いスコアが表示されます。 このチュートリアルの終わりまでに、これら2つの項目は、Nginxの構成変更により、すべてのデバイスタイプで解決されます。
[.note]＃Note：場合によっては、デフォルトのNginx構成で、グローバル構成ファイルでGzip圧縮とキャッシュが既に有効になっていることがあり、その結果、完全なPageSpeedスコアのように見えます。 その場合は、デフォルトでは実際のセットアップには十分ではないため、読み続けてください。
＃
まず、Nginxを構成して、いくつかの応答を圧縮します。
[[step-2 -—- enableing-compression]] ==ステップ2—圧縮を有効にする
CSS、JavaScript、および画像ファイルは大きくなる可能性があり、ユーザーがダウンロードする必要があるデータの量が増えます。 圧縮とは、これらのアセットのサイズを小さくして、より小さく、必要なデータをすべて含むよりコンパクトなバージョンにすることを意味します。 Gzipは、Nginxでこの圧縮を実行するための1つのオプションです。 すべての主要なLinuxディストリビューションで利用可能であり、有効化して正しく設定する必要があります。 Gzip圧縮が有効になっていると、ブラウザーは静的アセットをより速くダウンロードできるため、PageSpeedツールは対処する必要があるものとしてフラグを立てます。
圧縮を有効にするには、nanoまたはお気に入りのテキストエディターでサイトのNginx構成ファイルを開きます。 この例では、デフォルトファイルを使用します。
sudo nano /etc/nginx/sites-available/default次のようなサーバー構成ブロックを見つけます。
/etc/nginx/sites-available/default
server {
listen 80 default_server;
listen [::]:80 default_server;
. . .
}圧縮を設定するために一連のスニペットを追加しましょう。
まず、Gzip圧縮を有効にして、圧縮レベルを設定します。
/etc/nginx/sites-available/default
server {
listen 80 default_server;
listen [::]:80 default_server;
gzip on;
gzip_comp_level 5;この値には、1と9の間の数値を選択できます。 5は、サイズとCPU使用率の間の完全な妥協点であり、ほとんどのASCIIファイルで約75％の削減を提供します（レベル9とほぼ同じ）。
次に、Nginxに、既に小さく、さらに縮小する可能性が低いものを圧縮しないように指示します。 デフォルトは20バイトですが、通常、圧縮後にファイルが大きくなるため、これは不適切です。 代わりに256に設定してください。
/etc/nginx/sites-available/default
...
gzip_comp_level 5;
gzip_min_length 256;次に、CloudFrontのようなプロキシ経由で接続しているクライアントでもデータを圧縮するようにNginxに指示します。
/etc/nginx/sites-available/default
...
gzip_min_length 256;
gzip_proxied any;次に、クライアントのAccept-Encoding機能ヘッダーが変化するたびに、リソースの圧縮バージョンと通常バージョンの両方をキャッシュするようにこれらのプロキシに指示します。 これにより、今日非常にまれな非Gzip対応クライアントが、プロキシが圧縮バージョンを提供した場合にちらつきが表示される問題を回避できます。
...
gzip_proxied any;
gzip_vary on;最後に、圧縮する出力のMIMEタイプを指定します。 画像、JSONデータ、フォント、その他の一般的なファイルタイプを圧縮します。
/etc/nginx/sites-available/default
...
gzip_vary on;
gzip_types
application/atom+xml
application/javascript
application/json
application/ld+json
application/manifest+json
application/rss+xml
application/vnd.geo+json
application/vnd.ms-fontobject
application/x-font-ttf
application/x-web-app-manifest+json
application/xhtml+xml
application/xml
font/opentype
image/bmp
image/svg+xml
image/x-icon
text/cache-manifest
text/css
text/plain
text/vcard
text/vnd.rim.location.xloc
text/vtt
text/x-component
text/x-cross-domain-policy;
# text/html is always compressed by gzip module完了すると、セクション全体が次の例のようになります。
/etc/nginx/sites-available/default
server {
listen 80 default_server;
listen [::]:80 default_server;
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_proxied any;
gzip_vary on;
gzip_types
application/atom+xml
application/javascript
application/json
application/ld+json
application/manifest+json
application/rss+xml
application/vnd.geo+json
application/vnd.ms-fontobject
application/x-font-ttf
application/x-web-app-manifest+json
application/xhtml+xml
application/xml
font/opentype
image/bmp
image/svg+xml
image/x-icon
text/cache-manifest
text/css
text/plain
text/vcard
text/vnd.rim.location.xloc
text/vtt
text/x-component
text/x-cross-domain-policy;
# text/html is always compressed by gzip module
}ファイルを保存して閉じます。
設定ファイルに多くの行を追加しましたが、何かを壊す可能性のある文字やセミコロンが欠落している可能性が常にあります。 この時点でファイルにエラーがないことを確認するには、Nginx構成をテストします。
sudo nginx -tこのチュートリアルに記載されているとおりに変更を加えた場合、エラーメッセージは表示されません。
この変更により、サイトの速度が最大に向上しますが、ブラウザのキャッシュを活用するようにNginxを構成することもできます。これにより、サーバーのパフォーマンスがさらに向上します。
[[step-3 -—- configuring-browser-caching]] ==ステップ3—ブラウザーキャッシュの構成
ドメインに初めてアクセスすると、これらのファイルがダウンロードされ、ブラウザのキャッシュに保存されます。 その後のアクセスでは、ブラウザはファイルを再度ダウンロードする代わりにローカルバージョンを提供できます。 これにより、最後のアクセス以降に変更されたデータのみを取得する必要があるため、Webページのロードがはるかに高速になります。 これは、ユーザーにはるかに優れたエクスペリエンスを提供し、GoogleのPageSpeed Insightsでの実装が推奨される理由です。
もう一度、エディターでデフォルトのNginx構成ファイルを開きます。
sudo nano /etc/nginx/sites-available/defaultブラウザにCSS、JavaScript、画像、PDFファイルをキャッシュに7日間保存するよう指示する小さなコードを追加します。
Gzip圧縮の以前のコードの直後に、サーバーブロック内に次のスニペットを挿入します。
/etc/nginx/sites-available/default
...
# text/html is always compressed by gzip module
location ~* \.(jpg|jpeg|png|gif|ico|css|js|pdf)$ {
expires 7d;
}[.note]＃Note：これは頻繁に変更されるコンテンツの構成です。 開発活動が最小限である単純なブログを実行している場合、毎週新しいダウンロードを強制する意味はありません。 代わりに、30日以上など、より長い期間アセットをキャッシュするようにブラウザに指示できます。
＃
最終的なNginx構成ファイルは次のようになります。
/etc/nginx/sites-available/default
server {
listen 80 default_server;
listen [::]:80 default_server;
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_proxied any;
gzip_vary on;
gzip_types
application/atom+xml
application/javascript
application/json
application/ld+json
application/manifest+json
application/rss+xml
application/vnd.geo+json
application/vnd.ms-fontobject
application/x-font-ttf
application/x-web-app-manifest+json
application/xhtml+xml
application/xml
font/opentype
image/bmp
image/svg+xml
image/x-icon
text/cache-manifest
text/css
text/plain
text/vcard
text/vnd.rim.location.xloc
text/vtt
text/x-component
text/x-cross-domain-policy;
# text/html is always compressed by gzip module
location ~* \.(jpg|jpeg|png|gif|ico|css|js|pdf)$ {
expires 7d;
}
}ファイルを保存して閉じ、終了します。 構成にエラーがないことを確認します。
sudo nginx -t次に、Nginxを再起動して、着信要求にこれらの新しいディレクティブを適用します。
sudo systemctl restart nginxより良いPageSpeedスコアを提供するようにNginxを調整しました。 これらの変更がPageSpeedにどのように影響するかを見てみましょう。
[[step-4 -—- measure-the-results]] ==ステップ4—結果を測定する
これらの構成変更によってPageSpeedスコアが何ポイント上昇したかを確認するには、URLを貼り付けてRun Insightsをクリックし、PageSpeedInsightsツールを使用してサイトをもう一度実行します。 圧縮およびブラウザキャッシュの警告が消えていることがわかります。
新しいスコアを最初のベースラインメトリックと比較します。 このチュートリアルを完了すると、以前より少なくとも10ポイント高い評点が得られます。
私たちの目標は、80以上のスコアを持つことでした。 サイトがまだこのしきい値を下回っている場合は、他にも注意が必要なことがあります。 PageSpeed Insightsは、これらが何であるかを正確に詳しく説明し、各問題のShow how to fixリンクをクリックした場合にそれらを修正する方法を示します。 正確な手順はサイトごとに異なり、このチュートリアルの範囲外です。
結論
Nginxの設定に簡単な変更を加えることで、Webサイトを高速化しました。 これで、PageSpeedスコアが大幅に向上し、サイトの読み込みが大幅に高速化されました。 これにより、ユーザーの満足度が向上し、Googleの目にはサイトの品質が向上します。 PageSpeedは非常に重要なランキングシグナルであり、ドメインが訪問者に快適な体験を提供していることを実証しています。
Nginxの設定を変更することはPageSpeedを改善する1つの方法にすぎず、それだけでは不十分な場合があります。 パフォーマンスコードを記述し、物事を適切にキャッシュし、コンテンツ配信ネットワーク（CDN）を介してアセットを提供し、可能な限りミニフィケーションを使用して物事を高速化する必要があります。