javascript - 浏览器是否在每个页面加载时解析javascript？(Do browsers parse javascript on every page load?)

Question

Do browsers (IE and Firefox) parse linked javascript files every time the page refreshes?(浏览器（IE和Firefox）每次页面刷新时都会解析链接的javascript文件吗？)

They can cache the files, so I'm guessing they won't try to download them each time, but as each page is essentially separate, I expect them to tear down any old code and re-parse it.(他们可以缓存文件，因此我猜他们不会每次都尝试下载它们，但由于每个页面基本上是分开的，我希望它们可以拆除任何旧代码并重新解析它。) This is inefficient, although perfectly understandable, but I wonder if modern browsers are clever enough to avoid the parsing step within sites.(这是低效的，虽然完全可以理解，但我想知道现代浏览器是否足够聪明以避免站点内的解析步骤。) I'm thinking of cases where a site uses a javascript library, like ExtJS or jQuery, etc.(我在想一个网站使用javascript库的情况，比如ExtJS或jQuery等。)   ask by translate from so

Answer 1

These are the details that I've been able to dig up.(这些是我能够挖掘的细节。)

It's worth noting first that although JavaScript is usually considered to be interpreted and run on a VM, this isn't really the case with the modern interpreters, which tend to compile the source directly into machine code (with the exception of IE).(首先值得注意的是，虽然JavaScript通常被认为是在VM上进行解释和运行，但现代解释器并不是这种情况，现代解释器倾向于将源代码直接编译为机器代码（IE除外）。) Chrome : V8 Engine(Chrome：V8引擎) V8 has a compilation cache.(V8有一个编译缓存。) This stores compiled JavaScript using a hash of the source for up to 5 garbage collections.(这使用源的哈希存储编译的JavaScript，最多可存储5个垃圾收集。) This means that two identical pieces of source code will share a cache entry in memory regardless of how they were included.(这意味着两个相同的源代码将共享内存中的缓存条目，无论它们是如何包含的。) This cache is not cleared when pages are reloaded.(重新加载页面时不会清除此缓存。) Source(资源) Update - 19/03/2015(更新 - 19/03/2015) The Chrome team have released details about their new techniques for JavaScript streaming and caching .(Chrome团队发布了有关JavaScript流媒体和缓存新技术的详细信息 。) Script Streaming(脚本流) Script streaming optimizes the parsing of JavaScript files.(脚本流优化了JavaScript文件的解析。) [...]([...]) Starting in version 41, Chrome parses async and deferred scripts on a separate thread as soon as the download has begun.(从版本41开始，Chrome会在下载开始后立即在单独的线程上解析异步和延迟脚本。) This means that parsing can complete just milliseconds after the download has finished, and results in pages loading as much as 10% faster.(这意味着解析可以在下载完成后的几毫秒内完成，并使页面加载速度提高10％。) Code caching(代码缓存) Normally, the V8 engine compiles the page's JavaScript on every visit, turning it into instructions that a processor understands.(通常情况下，V8引擎会在每次访问时编译页面的JavaScript，并将其转换为处理器可以理解的指令。) This compiled code is then discarded once a user navigates away from the page as compiled code is highly dependent on the state and context of the machine at compilation time.(一旦用户导航离开页面，该编译的代码就被丢弃，因为编译代码在编译时高度依赖于机器的状态和上下文。) Chrome 42 introduces an advanced technique of storing a local copy of the compiled code, so that when the user returns to the page the downloading, parsing, and compiling steps can all be skipped.(Chrome 42引入了一种存储已编译代码的本地副本的高级技术，因此当用户返回页面时，可以跳过下载，解析和编译步骤。) Across all page loads, this allows Chrome to avoid about 40% of compile time and saves precious battery on mobile devices.(在所有页面加载中，这使Chrome可以避免大约40％的编译时间，并在移动设备上节省宝贵的电池。) Opera : Carakan Engine(歌剧：Carakan Engine) In practice this means that whenever a script program is about to be compiled, whose source code is identical to that of some other program that was recently compiled, we reuse the previous output from the compiler and skip the compilation step entirely.(实际上，这意味着无论何时编译脚本程序，其源代码与最近编译的其他程序的源代码相同，我们都会重用编译器的先前输出并完全跳过编译步骤。) This cache is quite effective in typical browsing scenarios where one loads page after page from the same site, such as different news articles from a news service, since each page often loads the same, sometimes very large, script library.(这种缓存在典型的浏览场景中非常有效，其中一个页面从同一站点加载页面，例如来自新闻服务的不同新闻文章，因为每个页面通常加载相同的，有时非常大的脚本库。) Therefore JavaScript is cached across page reloads, two requests to the same script will not result in re-compilation.(因此，JavaScript在页面重新加载时被缓存，对同一脚本的两个请求不会导致重新编译。) Source(资源) Firefox : SpiderMonkey Engine(Firefox：SpiderMonkey引擎) SpiderMonkey uses Nanojit as its native back-end, a JIT compiler.(SpiderMonkey使用Nanojit作为其本机后端，一个JIT编译器。) The process of compiling the machine code can be seen here .(编译机器代码的过程可以在这里看到。) In short, it appears to recompile scripts as they are loaded.(简而言之，它似乎在加载时重新编译脚本。) However, if we take a closer look at the internals of Nanojit we see that the higher level monitor jstracer , which is used to track compilation can transition through three stages during compilation, providing a benefit to Nanojit :(但是，如果我们仔细研究一下 Nanojit的内部结构，我们会看到用于跟踪编译的更高级别的监视器jstracer可以在编译期间过渡到三个阶段，为Nanojit提供了一个好处：) The trace monitor's initial state is monitoring.(跟踪监视器的初始状态是监视。) This means that spidermonkey is interpreting bytecode.(这意味着spidermonkey正在解释字节码。) Every time spidermonkey interprets a backward-jump bytecode, the monitor makes note of the number of times the jump-target program-counter (PC) value has been jumped-to.(每次spidermonkey解释向后跳转字节码时，监视器都会记录跳转目标程序计数器（PC）值跳转到的次数。) This number is called the hit count for the PC.(此编号称为PC的命中计数。) If the hit count of a particular PC reaches a threshold value, the target is considered hot.(如果特定PC的命中计数达到阈值，则认为目标是热的。) When the monitor decides a target PC is hot, it looks in a hashtable of fragments to see if there is a fragment holding native code for that target PC.(当监视器确定目标PC很热时，它会查找片段的哈希表，以查看是否存在包含该目标PC的本机代码的片段。) If it finds such a fragment, it transitions to executing mode.(如果找到这样的片段，它将转换为执行模式。) Otherwise it transitions to recording mode.(否则它将转换为录制模式。) This means that for hot fragments of code the native code is cached.(这意味着对于代码的hot片段，本机代码被缓存。) Meaning that will not need to be recompiled.(意义不需要重新编译。) It is not made clear is these hashed native sections are retained between page refreshes.(在页面刷新之间保留这些散列的原生部分并不清楚。) But I would assume that they are.(但我会认为他们是。) If anyone can find supporting evidence for this then excellent.(如果有人能找到支持证据，那就太好了。) EDIT : It's been pointed out that Mozilla developer Boris Zbarsky has stated that Gecko does not cache compiled scripts yet .(编辑 ：它已经指出，Mozilla开发鲍里斯Zbarsky曾表示，壁虎不缓存编译脚本呢 。) Taken from this SO answer .(取自这个SO答案 。) Safari : JavaScriptCore/SquirelFish Engine(Safari：JavaScriptCore / SquirelFish Engine) I think that the best answer for this implementation has already been given by someone else .(我认为这个实施的最佳答案已经由其他人提供 。) We don't currently cache the bytecode (or the native code).(我们目前不缓存字节码（或本机代码）。) It is an(它是一个)
option we have considered, however, currently, code generation is a(我们已经考虑过的选项，但是，目前，代码生成是一个)
trivial portion of JS execution time (< 2%), so we're not pursuing(JS执行时间的微不足道的部分（<2％），所以我们不追求)
this at the moment.(这一刻。) This was written by Maciej Stachowiak , the lead developer of Safari.(这是由Safari的首席开发人员Maciej Stachowiak撰写的。) So I think we can take that to be true.(所以我认为我们可以认为这是真的。) I was unable to find any other information but you can read more about the speed improvements of the latest SquirrelFish Extreme engine here , or browse the source code here if you're feeling adventurous.(我无法找到任何其他信息，但你可以阅读更多有关最新的速度提升SquirrelFish Extreme引擎在这里 ，或浏览源代码， 在这里 ，如果你喜欢冒险的感觉。) IE : Chakra Engine(IE：Chakra引擎) There is no current information regarding IE9's JavaScript Engine (Chakra) in this