0

アプリには数百の JavaScript ファイルがあり、現在圧縮されていない状態で提供されています。クライアントのパフォーマンスをもう少し向上させるための解決策の 1 つは、javascript ファイルを縮小することです。ビルドでこれを行う自動化されたソリューションを作成しましたが、これらの新しいファイルがデプロイされると、クライアントに再送信されるかどうかを決定するファイルのタイムスタンプが変更されます。これは、将来のすべてのリリースで、すべての JavaScript ファイルに新しいタイムスタンプが設定されることを意味します。私たちのクライアントは、縮小されたすべての JavaScript ファイルを再度ダウンロードするため、縮小のパフォーマンス面が損なわれます。

これは他の誰かが遭遇した問題ですか? あなたの解決策は何ですか？プロジェクトで使用されている、縮小されていない JavaScript ファイルと縮小された JavaScript ファイルが別々にあり、ビルドで縮小を実行していませんか?

他の解決策 (ソース管理リポジトリで実際に変更されたファイルのみを検索するなど) を念頭に置いていますが、これは、他の人が何をしているかを知りたかった 1 つの質問です。

4

4 に答える 4

4

実際に変更されたファイルを特定する必要があります。または、それについて心配する必要はなく、縮小されたファイルで得られる改善を楽しんでください。いずれにせよ、クライアントはファイルをキャッシュに長期間保持しない可能性があるため、ファイルを非常に頻繁に更新しない限り、キャッシュ動作を管理しようとしてもほとんどメリットがない可能性があります。

于 2008-10-02T17:41:35.150 に答える
2

ソース フォルダーとターゲット フォルダーの各ファイルの CRC または MD5 ハッシュをチェックし、ファイルが変更された場合にのみ上書きを実行するスクリプトを作成できます。これにより、変更されていないファイルのタイムスタンプが保持され、目的のキャッシュ動作が得られます。

同様に、以前のタイムスタンプを記録し、上書きを行ってから、touch コマンド (これらのファイルが UNIX システム上にあると仮定) を使用して、タイムスタンプを元の値に戻すことができます。

最初のオプションは、タイムスタンプを常に同じ値に盲目的に設定するよりもおそらく優れています。これは、サーバーが変更されていないと主張するために、一部のクライアントが変更された JS ファイルをしばらく取得しないことを意味する可能性があるためです。

于 2008-10-02T18:04:16.330 に答える
0

これらのスクリプトファイルを一定期間にわたってロールアウトして、1人のユーザーの要求に過度に長い時間がかかることがないようにすることができます。しかし、真剣に、私たちはどのくらいのJavaScriptについて話しているのですか？あなたのページに関連付けられたスクリプトの1回限りの再ダウンロードは、本当に大したことですか？これを実行するためにどれだけの労力を費やす必要があるかを考え、それを利益と比較検討してください。

于 2008-10-02T17:45:18.027 に答える
0

Flickr で有名な Cal​​ Henderson によるhttp://www.thinkvitamin.com/features/webapps/serving-javascript-fastを読んでください。うまくいけば、それが役に立つでしょう。

于 2008-10-03T10:57:01.910 に答える