こんなに読む気にならない#
この記事では、強制キャッシュを使用する際に、ユーザーが変更された静的リソースをタイムリーに享受できるようにする方法について説明します。
以下のいくつかの方法があります。
- リソースファイル名を変更する、例えば：
custom-v1.css - リソースファイル名を変更し、ファイル内容に基づいてハッシュ値を生成する（内容が変更されればハッシュも変更され、逆に変更されなければハッシュは変わらない）（index.v1tg6l.css）
- リソースにリクエストパラメータを追加する（このパラメータには何の効果もなく、単に URL を変更するためのもの）第二条と同様にハッシュを生成する（index.css?v=qb6l0p）
本文#
私たちは原点に立ち返り、原始的なフロントエンド開発から始めましょう。上の画像は「かわいい」index.html ページとそのスタイルファイル a.css で、テキストエディタでコードを書き、コンパイルは不要で、ローカルプレビューを確認し、OK を出したらサーバーにアップロードし、ユーザーのアクセスを待ちます。フロントエンドはこんなにシンプルで、楽しいですね、敷居も低いです、すぐに学べるのではないでしょうか！
そして、私たちはページにアクセスし、効果を見て、ネットワークリクエストを確認します、200！素晴らしい、完璧です！では、開発は完了したのでしょうか？待ってください、まだ終わっていません！大企業にとって、あの異常なアクセス量とパフォーマンス指標は、フロントエンドを全く「楽しく」させません。あの a.css のリクエストを見てください、もしユーザーがページにアクセスするたびにロードする必要があるなら、パフォーマンスに大きな影響を与え、帯域幅を無駄にするのではないでしょうか。私たちはできればこうしたいのです：
304 を利用して、ブラウザにローカルキャッシュを使用させます。しかし、これで十分なのでしょうか？ダメです！304 は協調キャッシュと呼ばれ、このものはサーバーと一度通信する必要があります。私たちの最適化レベルは異常なので、このリクエストを完全に排除し、こうする必要があります：
ブラウザにローカルキャッシュを強制的に使用させる（cache-control/expires）、サーバーと通信しないようにします。さて、リクエストに関する最適化は異常レベルに達しましたが、問題が発生しました：ブラウザにリソースリクエストをさせないのに、このキャッシュはどうやって更新するのでしょうか？素晴らしい、誰かが方法を思いついたと思います：ページ内で参照されるリソースパスを更新することで、ブラウザにキャッシュを放棄させ、新しいリソースをロードさせます。こんな感じです：
次回のリリース時に、リンクアドレスを新しいバージョンに変更すれば、リソースが更新されるのではないでしょうか。OK、問題は解決しましたか？！もちろん、そうではありません！大企業の異常が再びやってきました。この状況を考えてみてください：
ページが 3 つの css を参照していて、あるリリースで a.css だけを変更した場合、すべてのリンクをバージョンアップすると、b.css や c.css のキャッシュも無効になり、無駄になってしまうのではないでしょうか？！再び異常モードを発動させると、私たちはこの問題を解決するためには、URL の変更をファイル内容に関連付ける必要があることに気づきます。つまり、ファイル内容が変化したときだけ、対応する URL が変更されるようにし、ファイルレベルでの正確なキャッシュ制御を実現するのです。ファイル内容に関連するものは何でしょうか？私たちは自然にデータの要約アルゴリズムを利用してファイルの要約情報を求めることを思いつきます。要約情報はファイル内容と一対一で対応し、単一ファイル粒度のキャッシュ制御の根拠を持つことができます。さて、私たちは URL を要約情報を含むように変更します：
これでファイルが変更されると、そのファイルに対応する URL だけが更新されます。ここまで考えると、完璧なように思えます。あなたはこれで十分だと思いますか？大企業はあなたに言います：甘い考えだ！ああ～～～～、少し息をつかせてください。現代のインターネット企業は、ウェブサイトのパフォーマンスをさらに向上させるために、静的リソースと動的ウェブページを分散してデプロイします。静的リソースは CDN ノードにデプロイされ、ウェブページで参照されるリソースも対応するデプロイパスに変更されます：
さて、静的リソースを更新する際には、同時に HTML 内の参照も更新する必要があります。こんな感じです：
今回のリリースでは、ページ構造とスタイルを変更し、静的リソースに対応する URL アドレスも更新しました。今、コードをリリースする準備ができました。親愛なるフロントエンド開発者の皆さん、私たちは先にページをリリースしますか、それとも先に静的リソースをリリースしますか？先にページをデプロイし、その後リソースをデプロイします：二者のデプロイ間隔内にユーザーがページにアクセスすると、新しいページ構造で古いリソースがロードされ、この古いバージョンのリソースが新しいバージョンとしてキャッシュされます。その結果、ユーザーはスタイルが崩れたページにアクセスすることになります。手動でリフレッシュしない限り、リソースキャッシュが期限切れになるまで、ページは常にエラーを実行します。先にリソースをデプロイし、その後ページをデプロイします：デプロイ間隔内に古いバージョンのリソースがローカルキャッシュされているユーザーがウェブサイトにアクセスすると、リクエストされたページが古いバージョンであり、リソースの参照が変更されていないため、ブラウザはローカルキャッシュを直接使用します。この場合、ページは正常に表示されます。しかし、ローカルキャッシュがないか、キャッシュが期限切れのユーザーがウェブサイトにアクセスすると、古いバージョンのページが新しいバージョンのリソースをロードすることになり、ページがエラーを実行します。しかし、ページのデプロイが完了すると、このユーザーは再度ページにアクセスすると正常に戻ります。さて、上記の分析で言いたいことは：誰を先にデプロイしてもダメです！どちらもデプロイ中にページが乱れる問題を引き起こします。したがって、アクセス量の少ないプロジェクトでは、開発者に苦労させて、真夜中にこっそりリリースし、先に静的リソースをデプロイし、その後ページをデプロイすることができます。そうすれば、問題が少なくなるようです。しかし、大企業は超異常で、「絶対的な低ピーク期」はありません。「相対的な低ピーク期」しかありません。だから、安定したサービスのためには、極限を追求し続けなければなりません！この奇妙な問題は、リソースのオーバーライドリリースに起因しており、リリース待ちのリソースが既にリリースされたリソースをオーバーライドすることで、この問題が発生します。それを解決するのは簡単で、非オーバーライドリリースを実現することです。
上の図を見てください。ファイルの要約情報を使用してリソースファイルの名前を変更し、要約情報をリソースファイルのリリースパスに含めることで、内容が変更されたリソースは新しいファイルとしてオンラインにリリースされ、既存のリソースファイルをオーバーライドしません。リリースプロセスでは、まず静的リソースを全量デプロイし、その後ページをグレーディングデプロイします。これで問題が比較的完璧に解決されます。したがって、大企業の静的リソース最適化プランは、基本的に以下のいくつかの要素を実現する必要があります：超長時間のローカルキャッシュの設定 —— 帯域幅を節約し、パフォーマンスを向上させるコンテンツ要約をキャッシュ更新の根拠として使用 —— 正確なキャッシュ制御静的リソースの CDN デプロイ —— ネットワークリクエストの最適化リソースリリースパスの非オーバーライドリリースを実現 —— スムーズなアップグレード全体を通して、比較的完全な静的リソースキャッシュ制御プランが実現されます。また、静的リソースのキャッシュ制御は、フロントエンドのすべての静的リソースが読み込まれる場所でこの処理を行う必要があることに注意してください。そうです、すべてです！何の js、css は言うまでもなく、js、css ファイル内で参照されるリソースパスも含める必要があります。要約情報が関与するため、参照リソースの要約情報も参照ファイル自体の内容を変更することになり、級連の要約の変化を引き起こします。大まかな図は次のようになります：
さて、私たちはフロントエンドエンジニアリングにおける静的リソースキャッシュが直面する最適化とデプロイの問題を迅速に学びましたが、新たな問題が発生しました：これではエンジニアはどうやってコードを書くのでしょうか！！！最適化とエンジニアリングの結合処理の考え方を説明すると、モジュール化開発、リソースロード、リクエストの統合、フロントエンドフレームワークなどに関する一連のエンジニアリング問題が引き起こされます。以上は単なる始まりであり、解決策が本質です。しかし、言いたいことは非常に多く、時間があればゆっくり展開しましょう。あるいは、私のブログを見てその中のいくつかの解体を見てください：fouber/blog・GitHub とにかく、フロントエンドのパフォーマンス最適化は絶対にエンジニアリングの問題です！