私は何年もの間エンジニアの周りにいたので、コンテキストを提供しなければ、「何を達成しようとしていますか?」という形で何百もの答えが返ってくることを知っています。私の質問の動機となる背景を説明します。しかし、私が尋ねている質問のバックグラウンド コンテキストを混同しないでください。これは特に、ページ リクエスト間でオブジェクト コードをキャッシュできないようにする JavaScript セマンティクスに関連しています。Web アプリケーションを高速化する方法についてアドバイスを与えるつもりはありません。これは私の質問とはまったく関係がありません。おそらく、JavaScript コンパイラーまたは少なくとも動的言語のコンパイラーに取り組んだことがある人だけが答えられるでしょう。
バックグラウンド：
Web アプリケーションのパフォーマンスを改善しようとしています。その多くのリソースの中で、40,000 行、130 万文字の事前縮小された 1 つの巨大な JavaScript ファイルが含まれています。縮小後もサイズは大きく、ソースがクライアント側にキャッシュされている場合でも、同期的にロードされると window.onload イベントに約 100 ミリ秒追加されます。(リクエストログを見て、リソースがリクエストされていないことを観察することで、リソースがキャッシュされていない可能性を最終的に除外しました。)
キャッシュされた後も遅いことを確認した後、主要なブラウザーでの JavaScript キャッシングについて調査を開始し、それらのいずれもオブジェクト コードをキャッシュしないことを知りました。
私の質問は、この研究に基づくいくつかの仮説的な主張の形です。これらの主張が間違っている場合は、反論してください。
JavaScript オブジェクト コードは、最新のブラウザーではキャッシュされません。
「オブジェクト コード」とは、単純な線形化された解析ツリーを表すバイト コードからネイティブ マシン コードまで、あらゆるものを意味します。
Web ブラウザの JavaScript オブジェクト コードは、キャッシュするのが困難です。
つまり、キャッシュされた JS ソース ファイルを外部タグに含めている場合でも、スクリプトに関数定義のみが含まれている場合でも、そのスクリプトをページに含めるには直線的なコストがかかります。オブジェクトコードにコンパイルされます。
JavaScript オブジェクト コードは、コンパイルするために JS ソースを評価する必要があるため、キャッシュするのが困難です。
ステートメントには、静的な分析が困難な動的な方法でダウンストリーム ステートメントのコンパイルに影響を与える機能があります。
3a. (3) は主に eval() のおかげで真です。
評価は、DOM に副作用をもたらす可能性があります。
したがって、JavaScript ソースはすべてのページ リクエストでコンパイルする必要があります。
おまけの質問: 最新のブラウザーは、キャッシュされた JS ソース ファイルの解析ツリーをキャッシュしますか? そうでない場合、なぜですか？
編集:これらのアサーションがすべて正しい場合は、オブジェクト コードとしてキャッシュできなかった JS コードのサンプルを提供し、その理由を説明するなどして、それらが正しい理由を詳しく説明できる人に答えを提供します。いいえ。
アプリを高速化するためにここから先に進む方法についての提案に感謝し、ほとんど同意します。しかし、私が埋めようとしている知識のギャップは、JS オブジェクト コードのキャッシュに関連しています。