ExtJSでプロジェクトを開発している場合、ライブラリ配布ツリーはおそらくソースツリーにあり、その機能が使用されているすべてのページで接続します。 また、ライブラリ自体もホスティングに保管してください。 もちろん、これは正確でシンプルなアプローチですが、制限があります。 まず、ほとんどの場合、ページの最大のコンポーネントになるのはExtJSです。これは、合計ボリュームが約1 MBであるため、ブラウザーがライブラリ全体をロードするまでページの速度が低下するためです。 方法として、誰もが圧縮を設定することをお勧めします（たとえば、mod_deflate、コンテンツが圧縮されたブラウザがほとんどないこと、そしてそれを持っている人は誰でもそれ自体に対して悪意のあるピノキオです）、キャッシュタグなど。 さて、最後の手段として-あなたのプロジェクトのために、あるいは各ページのために、必要なコンポーネントを含むライブラリのバージョンを収集すること。 フレームワークの構造と、 サイトに配置されたデザイナーについては既に書きました。これにより、個人用ディストリビューションを自動的に作成できます。
ただし、これらのプラグインを保存する別のオプションがあります。 CDN-Content Delivery Networksなどのシステムがあります。これは、強力な高速チャネルに接続され、特定のファイルを要求するユーザーの近くにある地理的に分散したサーバーの独自のネットワークを持っています。 CDNに保存されている場合、ファイルはユーザーに最も近いサーバーから返されます。つまり、ファイルの読み込みが速くなります。
CacheFlyとのパートナーシップにより、ExtJSはそのようなネットワークにビルドを保存できるようになりました。 JSファイル自体に加えて、スタイルファイルも保存されます（ext-all.css、これも非常に膨大です）。 さらに、Webインターフェイスを介してフレームワークの独自のアセンブリを作成するようになったので、すぐにCDNに入れて、リンクを変更するだけで直接使用できます。 フレームワークアセンブリのバージョンが既に誰かによって使用されている場合、新しいファイルは作成されず、既にキャッシュされているものへのリンクが与えられることに注意してください。
もちろん、多くのプロジェクトでは、この方法で達成される加速はそれほど重要ではないかもしれませんが、私たちは0.5秒勝ちました...しかし、信じてください、最適化のための闘争に制限はなく、アプリケーションで最短時間を獲得するのに役立つすべてのものが顧客に評価されます。
書くだけでなく、CacheFlyサーバーからのダウンロードが実際にプロジェクトサーバーから直接ファイルを接続する場合よりも速くなるかどうかを確認することにしました。
正直なところ、ロードは確かに遅くはありません。 特に、ダウンロードは別のホストからであるという事実により、ブラウザーが同時に他のファイルを要求することを意味します。これは、1つのドメインへの同時要求数が制限されているため重要です。 pingでサイトの可用性を確認すると、値は平均してサーバーのデータ以下でしたが、前回確認したとき、CacheFlyの方が差が1.5倍大きくなりました。 そのため、何かアドバイスをすることは困難です。個人的に試してみる必要がありますが、悪化することはありません。