Webアプリケーションのパフォーマンスを向上させようとしています。メインのHTMLページを返すのにかかる時間を最適化するために使用できるメトリックがありますが、これらのHTMLページから含まれる外部のCSSファイルとJavaScriptファイルが心配です。これらは、HTTP Expiresヘッダーを使用して静的に提供されますが、アプリケーションのすべてのページ間で共有されます。
ブラウザは表示されるページごとにこれらのCSSファイルとJavaScriptファイルを解析する必要があるため、サイトのすべてのCSSファイルとJavaScriptを共通ファイルに共有すると、パフォーマンスに悪影響が出るのではないかと心配しています。これらのファイルを分割して、各ページからそのページに必要なCSSとJavaScriptのみにリンクする必要がありますか、それとも努力の成果がほとんどありませんか？
このためのメトリックを生成するのに役立つツールはありますか？
コンテキスト： HTTPオーバーヘッドがJSやCSSの解析よりも重要であることは事実ですが、ブラウザーのパフォーマンスに対する解析の影響を無視することは（JSが1メガ未満であっても）問題を解決するための良い方法です。
YSlow、Fiddler、およびFirebugは、解析速度を監視するための最良のツールではありません。ごく最近更新されていない限り、HTTP経由でJSをフェッチしたり、キャッシュからロードしたりするのに必要な時間と、実際のJSペイロードの解析に費やした時間は区別されません。
解析速度を測定するのは少し難しいですが、私が取り組んだプロジェクトでこのメトリックを何度も追跡しました。ページの読み込みへの影響は、JSが約500kであっても重要でした。明らかに、古いブラウザが最も苦しんでいます...うまくいけば、Chrome、TraceMonkeyなどがこの状況を解決するのに役立ちます。
提案：サイトのトラフィックの種類によっては、JSペイロードを分割して、最も人気のあるページで使用されないJSの大きなチャンクが送信されないようにすることをお勧めします。クライアント。もちろん、これは、新しいクライアントがこのJSが必要なページにアクセスしたときに、それをネットワーク経由で送信する必要があることを意味します。
ただし、たとえば、トラフィックパターンが原因で、ユーザーの80％がJSの50％を必要としない場合もあります。その場合は、JSが必要なページでのみ、より小さなパッケージ化されたJSペイロードを使用する必要があります。そうしないと、ユーザーの80％が、ページの読み込みごとに不要なJS解析ペナルティを受けることになります。
結論： JSキャッシングとより小さなパッケージ化されたペイロードの適切なバランスを見つけることは困難ですが、トラフィックパターンによっては、すべてのJSをすべてのページロードに粉砕する以外の手法を検討する価値があります。
YSlowはそうだと思いますが、すべての要求がループバック接続を介していない限り、心配する必要はないことに注意してください。分割ファイルのHTTPオーバーヘッドは、CSS / JSファイルが数メガバイトを超えない限り、解析よりもはるかにパフォーマンスに影響を与えます。
仮面の素晴らしい答えに加えて、一部のブラウザーでは、より大きな js リソースの解析時間が非線形的に増加すると言えます。つまり、1 MB の JS ファイルは、2 つの 500k ファイルよりも解析に時間がかかります。そのため、トラフィックの多くが JS をキャッシュしている可能性が高いユーザー (再訪問者) であり、すべての JS ファイルが安定してキャッシュされている場合は、すべてをロードすることになったとしても、それらを分割することは理にかなっています。すべてのページビュー。