Azure Webサイトでのスクリプト/スタイルの長い待機（TTFB）時間
AzureWebサイトでこの興味深い問題が発生しています。私のウェブサイトでは、4つのスクリプトファイルと3つのスタイルファイルを使用しており、それぞれが縮小されています。それらはそれほど大きくはなく、最大のものは200KB近くあります。ウェブサイトはすでに始まっていました。 AzureのAlwaysOnオプションがオンになっています。データを求めてWebApiを呼び出すと、50ミリ秒未満で返されます。
また、アプリをリロードすると、最も小さなスクリプトから最初のバイトを取得するためだけに250ミリ秒が必要になり、他のアプリにはさらに多くの時間が必要になります。初期HTMLは60ミリ秒でロードされます。スクリプト/スタイルはキャッシュされるためダウンロードされませんが、TTFB時間がパフォーマンスを低下させています。これは、すべてのリロードを繰り返します。アプリには高度な構成が含まれていないため、アプリよりもはるかに高速に実行されます。
何がそのような問題を引き起こす可能性がありますか？
静的ファイルはキャッシュされますが、ブラウザーはif-modifys-sinceヘッダーを使用して要求を発行します（結果は304になります）。
実際のコンテンツをダウンロードする必要はありませんが、RTT +サーバーの思考時間が続行するのを待つ必要があります。
私は2つのことを提案します：
- Cache-ControlヘッダーとExpireヘッダーを追加-場合によっては304を回避するのに役立ちます（F5キーを押さない限り）
- 適切なCDNを使用-Incapsulaなど、RTT +思考時間を最小限に抑えます。また、さまざまなリソースのキャッシュ設定を簡単に制御するためにも使用できます。
ここでもっと良いもの。
幸運を！
から ここ ：
前に見たように、IIS 7は静的ファイルの圧縮バージョンをキャッシュします。したがって、圧縮バージョンがすでにキャッシュにある静的ファイルの要求が到着した場合、それは必要ありません。再び圧縮されます。
しかし、キャッシュに圧縮バージョンがない場合はどうなりますか？ IIS 7は、ファイルをすぐに圧縮してキャッシュに入れますか？答えは「はい」ですが、ファイルが頻繁に要求されている場合に限ります。要求頻度が低いファイルを圧縮しないことにより、 IIS 7は、CPU使用率とキャッシュスペースを節約します。
デフォルトでは、ファイルが10秒に2回以上要求された場合、ファイルは頻繁に要求されたと見なされます。
したがって、ユーザーに非圧縮バージョンのjavascriptファイルが提供される理由は、圧縮のデフォルトのしきい値を満たしていないためです。つまり、javascriptファイルは10秒以内に2回要求されませんでした。
これを制御するには、圧縮を制御する<serverRuntime>要素で変更する必要のある属性が1つあります：frequentHitThreshold。一度要求されたときにファイルを圧縮するには、<serverRuntime>要素を次のように変更します。
<serverRuntime enabled="true" frequentHitThreshold="1" />
これは、提供されているjavascriptファイルが多数あり、ユーザーが頻繁にいる場合、CPUパフォーマンスにわずかに影響しますが、CPUにこれらのファイルの圧縮から影響を与えるほど頻繁にユーザーがいる場合は、既に圧縮されてキャッシュされています。
Azure Storageにファイルを保存し、AzureCDNで提供することで終了しました。高速な応答を提供し、費用はかかりません。 GulpによるPre-buildイベントで、公開するたびにそれらをblobに追加します。
スクリプトとスタイルは静的ファイルであり、デフォルトでは、クライアントに送信される前に圧縮されます（HTTPヘッダー "content-encoding"：gzipで確認できます）。したがって、TTFBは、ネットワークレイテンシ、ブラウザのHTTPチャネルのスケジューリング、およびサーバーからの静的ファイル圧縮時間で構成されます。
一方、Web APIデータは動的データであり、デフォルトでは圧縮されていないため、そのTTFBが静的ファイルのTTFBよりも小さい可能性があります。
ただし、静的圧縮をオフにする必要はありません。オフにしないと、TTFBは最小化されますが、コンテンツの転送時間は長くなります。実際には、TTFBについて心配する必要はありません。詳細を参照してください： https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/
私の推測では、Azureは常にオンになっています。
CloudFlareが提供するものと同じように機能する場合、基本的にリクエストをプロキシし、キャッシュしようとします。
Azure側でのこのキャッシュの正確な実装によっては、スクリプト出力が完了するのを待ってキャッシュをキャッシュ/検証してから、ブラウザーに渡す場合があります。
キャッシュ構成を確認し、可能であればスクリプトの常時オンを無効にする可能性があります。