私は最近、JavaScriptとCSSファイルを共通のライブラリDLLに埋め込み、展開とバージョン管理を大幅に簡素化しました。私は、Webアプリケーションで同じことをしたいという理由があるのか、それともWebアプリケーションの通常のファイルとして残しておき、共有コンポーネントにのみ組み込みリソースを使用するのが最善かどうか疑問に思っていましたか？CSS/JavaScriptファイルをWebアプリケーションに埋め込む必要がありますか？
埋め込みに利点はありますか？
もちろん、彼らが何をしているか知っている人なら、アセンブリリフレクタを使用して、JSまたはCSSを抽出することができます。しかし、これはFireBugのようなものを使ってこの情報を得るよりもはるかに多くの作業が必要です。通常のエンドユーザは、リソースを浪費するだけで、このようなトラブルのすべてに行きたいという欲求はありません。この種のものに興味がある人は、エンドユーザーではなく悪意のあるユーザーになる可能性があります。ユーザーがDLL上でアセンブリリフレクタのようなツールを使用することができれば、おそらくセキュリティに関する他の多くの問題を抱えているでしょう。その時点であなたのサーバーはすでに侵害されているからです。リソースの埋め込みに対するセキュリティは、私の決定の要因ではありませんでした。
重要な点は、ユーザーがこれらのリソースに愚かなことをしないようにすることです。ユーザーが不要であると考えて削除するか、そうでなければ改ざんするなどです。
関連するファイルの数が少ないため、アプリケーションを展開目的でパッケージ化する方がずっと簡単です。
ページで使用されるDLL（クラスライブラリ）が大きければ、それは本当ですが、これでページが大きくなるわけではありません。 ASP.NETは、クライアント（ブラウザ）に送信する必要があるコンテンツを生成します。ページが機能するために必要なコンテンツよりも、クライアントに送信されるコンテンツはもうありません。これらのページを提供するのに役立つクラスライブラリが、クライアントとサーバーの間で送信されるデータのサイズにどのような影響を与えるかは私には分かりません。
しかし、Rjlopesには、JavaScriptが埋め込まれたJavaScript/CSSリソースをキャッシュできないという点があります。私はそれをチェックアウトする必要がありますが、私はRjlopesが正しいことを疑う：JavaScript/CSSファイルは、フルページのポストバックがサーバーに行われるたびにダウンロードする必要があります。これが正しいと判明した場合、このパフォーマンスヒットはあなたの決定の要因になるはずです。
埋め込みリソース、resex、および単一ファイルの使用のパフォーマンスの違いをテストすることはできませんでした。私はこれとRjlopesが提唱しているブラウザのキャッシングポイントについて非常に興味があるので、私は今日後でそれに着くことを望みます。
私はキャッシュの問題に非常に関心があります。ブラウザがファイルをキャッシュできるように一貫したURLを使用しないとは想像もしません。 –
ScriptManagerでレンダリングされた埋め込みJSファイルは実際にキャッシュされ、アプリケーション全体で一貫したURLを使用します。私たちはいくつかのクライアントサイトでこれをうまく利用しています。 –
更新していただきありがとうございます。同じことがPage.ClientScript.GetWebResourceUrlメソッドに適用されるかどうか知りますか？ – Frinavale
埋め込み理由：ブラウザはJavaScriptファイルを並行してダウンロードしません。ファイルがダウンロードされるまで、ロック状態があります。
埋め込み理由：JavaScriptコードがすべて必要なわけではありません。したがって、帯域幅/処理を不必要に増加させる可能性があります。
cuzillion（http://stevesouders.com/cuzillion/） /埋め込みの選択とページ上の配置は、ページ全体の読み込み時間に影響する可能性があります。 – easement
@easement、それは興味深いページですが、少し工夫したようです。外部スタイルシートを追加すると、2秒の遅延が追加されることがわかります。これは任意のようです。そして、組み込みリソースの考え方には対応していないようです。 –
一部のブラウザは並行して検索しますが、そうではありませんか？あるいは少なくとも私はあなたがそうするようにFirefoxに言うことができると思います。あなたはそれらを埋め込むときに、あなたが埋め込んだファイルの数にかかわらず1つのリンクしか持たないのですか？もしそうでなければ、それはそれが大きな違いになるとは思わないでしょう。 –
私はこの同じ決定を一度しなければなりませんでした。 JavaScript/CSSリソースをDLLに埋め込む理由は、アプリケーションのデプロイ後に、（私のWebアプリケーションを購入した奇妙なエンドユーザーによる）これらのファイルの改ざんを防ぐためでした。
ブラウザがJavaScriptファイルをどのようにダウンロードするかについての、Easementのコメントの妥当性については疑問に思っています。ブラウザがダウンロードして使用できるようにするために、ページがブラウザに送信される前に、埋め込まれたJavaScript/CSSファイルがASP.NETによって一時的に再作成されることは間違いありません。私はこれについて興味があり、私は自分のテストを実行するつもりです。私はあなたが誰かがあなたのJSやCSSを改ざんしたい場合、彼らは単にリソースに行く、リフレクター付きアセンブリを開く必要があることを知っている....あなたはそれが行く方法を知っている
-Frinny
をもらおうと、彼らが望むものを編集します（おそらく、アセンブリが署名されていればもっと多くの作業が必要になります）。
ページにjsとcssを埋め込むと、ページが大きくなり（リクエストごとにダウンロードするKBが増えます）、ブラウザは次のリクエストのためにJSとCSSをキャッシュできなくなります。良いニュースは、あなたが少ない要求（少なくとも私が好きで、複数のjsとcssと1つを組み合わせている場合は2以上）、さらにはjavascriptが連続してダウンロードされるという問題があることです。
ブラウザキャッシュについては、私が気づいている限り、WebRecource.axdの応答に「304 not modified」と表示されます。だから、彼らはキャッシュから取ってきたと思います。
私はこの同じ決定を一度しなければなりませんでした。 JavaScript/CSSリソースをDLLに埋め込む理由は、アプリケーションのデプロイ後に、（私のWebアプリケーションを購入した奇妙なエンドユーザーによる）これらのファイルの改ざんを防ぐためでした。 埋め込み理由：JavaScriptコードがすべて必要なわけではありません。したがって、帯域幅/処理を不必要に増加させる可能性があります。
ソリューションのために[ここ]（http://stackoverflow.com/a/40399162/5137413）を参照してください。私はこの鼓動があなたを助けることを願っています –