最近、私はますます多くの仕事をクライアント側にシフトしていることに気づき、それ故に私のJSファイルはますます大きくなる傾向があります。ほとんどのHTMLページのヘッダーに6つ以上のJSインポートが含まれるようになり、これが読み込み時間を犠牲にしていることに気付きました。
最近、1つのHTTPリクエストで複数のJSファイルをダウンロードできるこのスクリプトを発見しました。これはPHPで書かれており、Djangoファンなので、Pythonで書き直す予定です。事前に縮小され連結されたファイルへのHTTPリダイレクトを使用することを計画しており、301のコストはどうなるのか疑問に思いました。それがばかげた考えかどうか教えてください。
一方、静的ファイルの提供にスクリプトロジックを導入することについては少し心配しており、たとえば、JSファイルを連結して最小化し、HTMLで複数のJSダウンロードを置き換えるantタスクのような実行可能なビルドの代替手段があるかどうか疑問に思いました。スクリプトのように、1つの大きなヘッダーを持つヘッダー。
PHP の場合、ビルド ステップを導入すると、PHP を使用する主な利点の 1 つが失われるという理由だけで、動的に行うことを好みます。実際、自己宣伝の危険を冒して、まさにこの問題についてPHP でスーパーチャージ Javascript を作成しました。
もちろん、他のテクノロジーは異なる場合があります。
これも PHP ですが、使用するコードの塊ではありません (ただし、完全に機能するコードが必要な場合は、パート 6に直接ジャンプできます)。正しい方法と、なぜそのようにするのか。
私は Javascript ファイルのバンドル (おそらくアプリケーション全体で 1 つだけ) を用意し、各ページは標準的な手段で必要な動作をアクティブ化するだけですが、すべてのコード本体はキャッシュされ縮小されたより大きな JS ファイルにあります。この方法が最も速く機能し、良い方法です。
ビルド プロセスの一部としてそれが必要な場合は、ビルド プロセスがある場合は合理的な解決策ですが、コードを縮小することをお勧めします。これを行うためのツールはたくさんあります。YUI Compressorをご覧ください。
JS ファイルの静的な結合を行う場合、gzip や関連する問題など、上記の他のものは依然として関連しています。
YUI コンプレッサーは良い選択です。Ant ベースのビルド プロセスのセットアップ方法については、次のチュートリアルをご覧ください: http://www.javascriptr.com/2009/07/21/setting-up-a-javascript-build-process /
Ruby ベースの代替手段として、Sprocketsをお勧めします