従来のリソース検証モデル
Googleの開発者は昨日、Firefoxのモデルでブラウザを最適化するためのFacebookとMozillaとの共同プロジェクトの結果を発表しました。 最適化後、モバイル版とデスクトップ版のChromeでのページの再読み込みが大幅に加速しました。 Googleによると、Chromeの最新バージョンはページを平均28％再読み込みします。
通常、ページがリロードされると、ブラウザは検証します。キャッシュ内の画像と他のすべてのリソースがまだ有効で再利用できることを確認するためだけに、ブラウザは何百ものネットワーク要求を送信します。 このページのリロードメカニズムは、サイトおよびWeb開発テクノロジのすべての変更にもかかわらず、 長年にわたって変更されていませんでした。 小さい要素の場合、HTTP応答が304のこの要求の速度は、Webページ要素をロードする通常の要求の速度とほぼ同じです。
ブラウザとサイトを改善する時が来ました。
Googleの開発者である豊島隆氏は、検証は以前はそれほど大きな問題にはならなかったと説明しますが、Webテクノロジーの開発により、通常、すべてのページに数百のネットワークリクエストが数十の異なるドメインに送信されます 。 これは、サーバーへのpingがデスクトップよりも高く、接続が不安定なモバイルデバイスでは特に不快です。 大きな遅延と不安定な接続により、モバイルブラウザのパフォーマンスとページの読み込み速度に重大な問題が発生します。
Mozillaは、ブラウザーの改善について最初に考えました。 昨年、彼らはCache-Controlのサポートを導入しました： Firefox 49の不変の機能。 サーバーの助けを借りて、サーバーは決して変わらないリソースを示すことができます。 そのようなアイテムは二度とリクエストされません。 たとえば、フォント、スクリプト、スタイルシート、ページのデザインに含まれる多数の画像などです。 したがって、一般的にあらゆるリソースを最適化できます。 リソースが変更されると、別の名前でレイアウトされます（Facebookでは、リソース名がコンテンツのハッシュに対応するシステムが実装されます）。
従来のモデルでは、
cache-control
は限られたリソースの有効期間を設定します。
$ curl https://example.com/foo.png > GET /foo.png < 200 OK < last-modified: Mon, 17 Oct 2016 00:00:00 GMT < cache-control: max-age=3600 <image data>
この期間の後、ブラウザはリソースの有効性をチェックします。
$ curl https://example.com/foo.png -H 'if-modified-since: Mon, 17 Oct 2016 00:00:00 GMT' > GET /foo.png > if-modified-since: Mon, 17 Oct 2016 00:00:00 GMT If the image was not modified < 304 Not Modified < last-modified: Mon, 17 Oct 2016 00:00:00 GMT < cache-control: max-age=3600 If the image was modified < 200 OK < last-modified: Tue, 18 Oct 2016 00:00:00 GMT < cache-control: max-age=3600 <image data>
immutable
パラメーターは、ブラウザーからリソースの有効性を検証する義務を取り除きます。
$ curl https://example.com/foo.png > GET /foo.png < 200 OK < last-modified: Mon, 17 Oct 2016 00:00:00 GMT < cache-control: max-age=3600, immutable <image data>
この機能がFirefoxに登場するのとほぼ同時に、Facebookはこの機能をサポートするためにサーバーインフラストラクチャを変更し始めました。 Mozilla開発者は、Facebookのような他のWebサイトがこの機能を徐々に導入していることを喜んでいます。
Chrome開発者もFirefoxの例に従いました。 たとえば、Chromeの最新バージョンでは、キャッシュされたリソースを検証するためのネットワーク要求が60％減少します。つまり、ページの読み込み速度が平均28％速くなります。
Firefoxテストでは、結果が確認されます。 Firefoxは1ページあたり平均150件のリクエストではなく、25件のみを送信し、場合によってはページの読み込みが2倍になります。
ユーザーが通常ページをリロードするのはなぜですか？ 通常、これは2つのケースで発生します。ページが正しくロードされなかったため、またはコンテンツが古くなっているためです。 数十年前に開発された更新メカニズムでは、最初の再起動シナリオのみが考慮されていました。 当時は、静的なWebページが毎分変化することを誰も想像できませんでした。 したがって、古いメカニズムは2番目のシナリオに非効率的に対処し、ページがリロードされるたびに同じリソースの検証要求を送信していました。 開発者は、このようなチェックは不要であると考えています。
現在、ChromeとFirefoxは簡易モードでページをリロードします-メインのリソースのみがチェックされ、その後ページは正常にロードされます。 このような最適化はあらゆる点で優れています。ダウンロード速度が加速され、ネットワークトラフィックが削減され、モバイルデバイスのバッテリー電力が節約されます。 Facebookは、サーバー上の静的要素に対するリクエストの数が60％減少したと報告しました。
このビデオは、典型的なAmazonページがアメリカの携帯電話会社のスマートフォンからどのようにリロードされるかを示しています。 再起動時間が20秒から約13秒に短縮されていることがわかります。Chromeの新しいバージョンでは、サーバーからの応答後、ページが画面上でほぼ瞬時に更新され、部分的に読み込まれません。
ブラウザーの改善に最も関心のあるFacebookの同僚が開発を支援しました。 興味深いことに、2014年にFacebookのエンジニアは調査を実施し、304 HTTPを返すほとんどのリクエストを送信するのはChromeであることがわかりました。
問題は、Chromeブラウザーに固有の完全に不要なコードであり 、リソースの再評価を頻繁にアクティブにします。 2015年に不要な再検証を排除した後、状況は改善されました。
現在、作業は継続されており、「永遠の」リソースの出現により、更新の頻度はさらに低くなります。 Chrome開発者は、この変更にはコードの比較的小さな変更が必要だと言います。 これは、わずかな最適化で優れた結果が得られることの良い例です。
不変要素のサポートとともに、Facebookはbrotli圧縮を導入した最初のサイトの1つでした。 その助けにより、動的マークアップは圧縮され、キャッシュできません。 古いgzipと比較して、brotliを使用すると、トラフィックが約20％節約されます。
サーバー上の不変要素のサポートは、トラフィックとCPU負荷が軽減されるため、ユーザーとサーバーの所有者の両方にとって有益です。