序章

Nginx は、ウェブページのリクエストを処理する際に優れていますが、ウェブページは高速に見える場合でも、デフォルトのNginx構成により、Googleの PageSpeed Insightsツールがサイトの非効率性にフラグを立てて評価します不完全に。 Googleは、サイトの検索位置を決定する際の重要な要素として、サイトの速度を使用します。

このチュートリアルでは、ドメインの構成ファイルをすばやく編集して、サイトの応答速度とそのPageSpeedメトリックを即座に向上させます。 目的は、80/100を超えるスコアを達成することです。これを超えると、Googleがスコアに緑色のマーカーを適用し、高速サイトを通知します。

まず、特定の種類のファイルに対してGzip圧縮を有効にします。 次に、追加のブーストのためにブラウザーのキャッシュを構成します。 これらの方法は、構築されているソフトウェアやCMSに関係なく、Nginxで実行されているサイトの速度を向上させます。 たとえば、Wordpressのインストールが遅く、パフォーマンスが低い場合、コアのラインに触れたり、高価なパフォーマンスのプラグインにお金を払ったりすることなく、即座に利益を得ることができます。 このアプローチは、サーバーがNginxであり、構成ファイルを編集できる限り、サイトが低電力の共有ホスティングで実行されている場合でも機能します。

前提条件

このチュートリアルを完了するには、次のものが必要です。

ステップ1—初期PageSpeedスコアを取得する

変更を加える前に、既存のPageSpeedスコアをキャプチャして、チュートリアルが完了したら比較するパフォーマンスベースラインを作成しましょう。 これを行うには、サイトのURLをGoogleのPageSpeedInsightsサービスに貼り付け、 RunInsightsをクリックします。

次のような結果が表示されます。

この例では、圧縮とブラウザーのキャッシュがサーバーで正しく構成されていないため、モバイルでは63、デスクトップでは74という低いスコアが表示されます。 このチュートリアルの終わりまでに、これら2つの項目は、Nginx構成の変更によってすべてのデバイスタイプで解決されます。

:場合によっては、デフォルトのNginx構成で、グローバル構成ファイルでGzip圧縮とキャッシュが既に有効になっていることがあり、その結果、完全なPageSpeedスコアのように見えます。 その場合は、読み続けてください。デフォルトでは、実際のセットアップには十分ではありません。

いくつかの応答を圧縮するようにNginxを構成することから始めましょう。

ステップ2—圧縮を有効にする

CSS、JavaScript、および画像ファイルは大きくなる可能性があり、ユーザーがダウンロードする必要のあるデータの量が増加します。 圧縮とは、これらのアセットのサイズがよりコンパクトなバージョンに縮小され、より小さくても必要なすべてのデータが含まれていることを意味します。 Gzipは、Nginxでこの圧縮を実行するための1つのオプションです。 これはすべての主要なLinuxディストリビューションで利用可能であり、有効にして正しく構成する必要があります。 Gzip圧縮を有効にすると、ブラウザは静的アセットをより迅速にダウンロードできるため、PageSpeedツールはそれに対処する必要があるものとしてフラグを立てます。

圧縮を有効にするには、nanoまたはお気に入りのテキストエディターでサイトのNginx構成ファイルを開きます。 この例では、デフォルトのファイルを使用します。

  1. 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;

あなたはの間の数を選ぶことができます 19 この値の場合。 5 サイズとCPU使用率の間の完全な妥協点であり、ほとんどのASCIIファイル(レベル9とほぼ同じ)に対して約75% rの教育を提供します。

次に、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構成をテストします。

  1. sudo nginx -t

このチュートリアルに記載されているとおりに変更を加えた場合、エラーメッセージは表示されません。

この変更により、サイトの速度が最大に向上しますが、ブラウザーのキャッシュを活用するようにNginxを構成することもできます。これにより、サーバーのパフォーマンスがさらに低下します。

ステップ3—ブラウザキャッシュの設定

ドメインに初めてアクセスすると、これらのファイルがダウンロードされ、ブラウザのキャッシュに保存されます。 その後のアクセス時に、ブラウザはファイルを再度ダウンロードする代わりにローカルバージョンを提供できます。 これにより、前回のアクセス以降に変更されたデータを取得するだけでよいため、Webページの読み込みが大幅に高速化されます。 これは、ユーザーにはるかに優れたエクスペリエンスを提供し、GoogleのPageSpeedInsightsが実装を推奨する理由です。

もう一度、エディターでデフォルトのNginx構成ファイルを開きます。

  1. 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;
}

:これは頻繁に変更されるコンテンツの構成です。 開発活動が最小限である単純なブログを運営している場合、毎週新しいダウンロードを強制する意味はありません。 代わりに、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;
    }
}

ファイルを保存して閉じ、終了します。 構成にエラーがないことを確認します。

  1. sudo nginx -t

次に、Nginxを再起動して、これらの新しいディレクティブを着信リクエストに適用します。

  1. sudo systemctl restart nginx

より良いPageSpeedスコアを提供するようにNginxを調整しました。 これらの変更がPageSpeedにどのように影響するかを見てみましょう。

ステップ4—結果を測定する

これらの構成変更によってPageSpeedスコアが何ポイント上昇したかを確認するには、URLを貼り付けて Run Insights をクリックし、PageSpeedInsightsツールを使用してサイトをもう一度実行します。 圧縮とブラウザのキャッシュに関する警告がなくなったことがわかります。

新しいスコアを最初のベースラインメトリックと比較します。 このチュートリアルを完了すると、以前よりも少なくとも10ポイント高いグレードが得られるはずです。

私たちの目標は、80を超えるスコアを取得することでした。 サイトがまだこのしきい値を下回っている場合は、他にも注意が必要なことがあります。 PageSpeed Insightsは、これらが何であるかを正確に詳しく説明し、各問題の修正方法を表示リンクをクリックすると、修正方法を示します。 正確な手順はサイトごとに異なり、このチュートリアルの範囲外です。

結論

Nginxの構成に簡単な変更を加えることで、Webサイトを高速化しました。 PageSpeedスコアが大幅に向上し、サイトの読み込みが大幅に高速化されました。 これにより、ユーザーはより幸せになり、Googleから見たサイトの品質が向上します。 PageSpeedは非常に重要なランキング信号であり、ドメインが訪問者に快適な体験を提供していることを示しています。

Nginx構成を変更することは、PageSpeedを改善する1つの方法にすぎず、それだけでは不十分な場合があります。 それでも、パフォーマンスの高いコードを記述し、適切にキャッシュし、コンテンツ配信ネットワーク(CDN)を介してアセットを提供し、可能な場合はミニファイを使用して処理を高速化する必要があります。