[解決済み] GithubはjavascriptライブラリのCDNとして使うべき？[クローズド］

質問

自分のサーバーの代わりに CDN から javascript ライブラリを提供することは、非常に大きな利点があります。 サーバーの作業が減り、CDN がサーバーよりもユーザーに近い場所にコピーを持っている可能性があり、最も重要なことは、ユーザーのブラウザがその URL からすでにキャッシュしている可能性が高いということです。 最後の1つは、誰にとっても総仕事が少なくなることを意味するので、明らかに全面的に有利であり、私たち（開発者）が javascript を提供するために CDN に頼ることが多ければ多いほど、その可能性は高くなります。

しかし、人気のある javascript CDN (Google、Microsoft、その他?) は、少数のファイルしかホストしません。 他のものについては、私たち自身がそれらをホストするか、または... ソース コントロール サーバーを CDN の一種として使用するかという選択肢があります。 Githubなどがグローバルに提供するために最適化されたファイルのキャッシュを地理的に分散して持っているとは思えません。 しかし、もしそれが一般的であれば、ユーザーのブラウザにキャッシュされている可能性は十分にあります。 私たちのサーバーから github に作業をオフロードするという主張は、Github が進んでこれを行うことを志願している場合にのみ有効です。

では、それは一般的なことなのでしょうか？ 私たちはお互いにこれを行うよう奨励すべきでしょうか？ Github は気にしますか? 彼らは公式の方針を表明していますか？

どのように解決するのですか？

パフォーマンスやIE9との互換性を重視するのであれば、JavaScriptのファイルに対してそのようなことをするべきではありません。

GitHub は、quot;raw" ファイルに遠い将来の expires ヘッダーを付けて提供することはありません。 クロスサイトキャッシングの可能性がなければ、JavaScript をホストするために公開 CDN を使用する最大の利点を失うことになります。 実際、GitHub を CDN として使用すると、各ユーザーが最初にファイルをリクエストした後、単に自分のサーバーでファイルをホストするよりも遅くなります (自分のサーバーでキャッシュを正しく設定したと仮定しての話です)。

もう一つの問題は、GitHub はファイルの実際の MIME タイプに一致する content-type ヘッダーを持つ "raw" ファイルを提供しないことです。 IE9 (そしておそらく他のブラウザ/プロキシ/ファイアウォール/その他) では、正しい content-type で提供されない JavaScript ファイルは、デフォルトでブロックされます。 たとえば、BlockUI のデモ ページで、その動作を確認することができます。