[ACCEPTED]-Do browsers parse javascript on every page load?-javascript-engine

These are the details that I've been able 113 to dig up. It's worth noting first that 112 although JavaScript is usually considered 111 to be interpreted and run on a VM, this 110 isn't really the case with the modern interpreters, which 109 tend to compile the source directly into 108 machine code (with the exception of IE).

Chrome : V8 Engine

V8 107 has a compilation cache. This stores compiled 106 JavaScript using a hash of the source for 105 up to 5 garbage collections. This means 104 that two identical pieces of source code 103 will share a cache entry in memory regardless 102 of how they were included. This cache is 101 not cleared when pages are reloaded.

Source

Update - 19/03/2015

The 100 Chrome team have released details about their new techniques for JavaScript streaming and caching.

1. Script Streaming

Script streaming 99 optimizes the parsing of JavaScript files. [...]

Starting 98 in version 41, Chrome parses async and deferred 97 scripts on a separate thread as soon as 96 the download has begun. This means that 95 parsing can complete just milliseconds after 94 the download has finished, and results in 93 pages loading as much as 10% faster.

2. Code caching

Normally, the 92 V8 engine compiles the page’s JavaScript 91 on every visit, turning it into instructions 90 that a processor understands. This compiled 89 code is then discarded once a user navigates 88 away from the page as compiled code is highly 87 dependent on the state and context of the 86 machine at compilation time.

Chrome 42 introduces 85 an advanced technique of storing a local 84 copy of the compiled code, so that when 83 the user returns to the page the downloading, parsing, and 82 compiling steps can all be skipped. Across 81 all page loads, this allows Chrome to avoid 80 about 40% of compile time and saves precious 79 battery on mobile devices.

Opera : Carakan Engine

In practice this 78 means that whenever a script program is 77 about to be compiled, whose source code 76 is identical to that of some other program that 75 was recently compiled, we reuse the previous 74 output from the compiler and skip the 73 compilation step entirely. This cache is 72 quite effective in typical browsing scenarios 71 where one loads page after page from the 70 same site, such as different news articles 69 from a news service, since each page often 68 loads the same, sometimes very large, script 67 library.

Therefore JavaScript is cached across 66 page reloads, two requests to the same script 65 will not result in re-compilation.

Source

Firefox : SpiderMonkey Engine

SpiderMonkey 64 uses Nanojit as its native back-end, a JIT compiler. The 63 process of compiling the machine code can 62 be seen here. In short, it appears to recompile scripts 61 as they are loaded. However, if we take a closer look at the 60 internals of Nanojit we see that the higher level 59 monitor jstracer, which is used to track compilation 58 can transition through three stages during 57 compilation, providing a benefit to Nanojit:

The 56 trace monitor's initial state is monitoring. This 55 means that spidermonkey is interpreting 54 bytecode. Every time spidermonkey interprets 53 a backward-jump bytecode, the monitor makes 52 note of the number of times the jump-target 51 program-counter (PC) value has been jumped-to. This 50 number is called the hit count for the PC. If 49 the hit count of a particular PC reaches 48 a threshold value, the target is considered 47 hot.

When the monitor decides a target PC 46 is hot, it looks in a hashtable of fragments 45 to see if there is a fragment holding native 44 code for that target PC. If it finds such 43 a fragment, it transitions to executing 42 mode. Otherwise it transitions to recording 41 mode.

This means that for hot fragments of code 40 the native code is cached. Meaning that 39 will not need to be recompiled. It is not 38 made clear is these hashed native sections 37 are retained between page refreshes. But 36 I would assume that they are. If anyone can find supporting evidence for this then excellent.

EDIT: It's been 35 pointed out that Mozilla developer Boris 34 Zbarsky has stated that Gecko does not cache 33 compiled scripts yet. Taken from this SO answer.

Safari : JavaScriptCore/SquirelFish Engine

I think that 32 the best answer for this implementation 31 has already been given by someone else.

We don't currently cache the 30 bytecode (or the native code). It is an
option 29 we have considered, however, currently, code 28 generation is a
trivial portion of JS 27 execution time (< 2%), so we're not pursuing
this 26 at the moment.

This was written by Maciej Stachowiak, the 25 lead developer of Safari. So I think we 24 can take that to be true.

I was unable to 23 find any other information but you can read 22 more about the speed improvements of the 21 latest SquirrelFish Extreme engine here, or browse the source code 20 here if you're feeling adventurous.

IE : Chakra Engine

There is 19 no current information regarding IE9's JavaScript 18 Engine (Chakra) in this field. If anyone knows anything, please comment.

This is quite 17 unofficial, but for IE's older engine implementations, Eric 16 Lippert (a MS developer of JScript) states in a blog reply here that:

JScript 15 Classic acts like a compiled language in 14 the sense that before any JScript Classic 13 program runs, we fully syntax check the 12 code, generate a full parse tree, and generate 11 a bytecode. We then run the bytecode through 10 a bytecode interpreter. In that sense, JScript 9 is every bit as "compiled" as 8 Java. The difference is that JScript does not allow you to persist or examine our proprietary bytecode. Also, the bytecode is much higher-level 7 than the JVM bytecode -- the JScript Classic 6 bytecode language is little more than a 5 linearization of the parse tree, whereas 4 the JVM bytecode is clearly intended to 3 operate on a low-level stack machine.

This 2 suggests that the bytecode does not persist 1 in any way, and thus bytecode is not cached.

Opera does it, as mentioned in the other 8 answer. (source)

Firefox (SpiderMonkey engine) does 7 not cache bytecode. (source)

WebKit (Safari, Konqueror) does 6 not cache bytecode. (source)

I'm not sure about IE[6/7/8] or 5 V8 (Chrome), I think IE might do some sort 4 of caching while V8 may not. IE is closed 3 source so I'm not sure, but in V8 it may 2 not make sense to cache "compiled" code 1 since they compile straight to machine code.

As far as I am aware, only Opera caches 2 the parsed JavaScript. See the section "Cached 1 compiled programs" here.

It's worth nothing that Google Dart explicitly tackles 4 this problem via "Snapshots" - the 3 goal is to speed up the initialization and 2 loading time by loading the preparsed version 1 of the code.

InfoQ has a good writeup @ http://www.infoq.com/articles/google-dart

I think that the correct answer would be 12 "not always." From what I understand, both 11 the browser and the server play a role in 10 determining what gets cached. If you really 9 need files to be reloaded every time, then 8 I think you should be able to configure 7 that from within Apache (for example). Of 6 course, I suppose that the user's browser 5 could be configured to ignore that setting, but 4 that's probably unlikely.

So I would imagine 3 that in most practical cases, the javascript 2 files themselves are cached, but are dynamically 1 re-interpreted each time the page loads.

The browser definitely makes use of caching 17 but yes, the browsers parse the JavaScript 16 every time a page refreshes. Because whenever 15 a page is loaded by the browser, it creates 14 2 trees 1.Content tree and 2.render tree.

This 13 render tree consists of the information 12 about the visual layout of the dom elements. So 11 whenever a page loads, the javascript is 10 parsed and any dynamic changes by the javascript 9 will like positioning the dom element, show/hide 8 element, add/remove element will cause the 7 browser to recreate the render tree. But 6 the modern broswers like FF and chrome handle 5 it slightly differently, they have the concept 4 of incremental rendering, so whenever there 3 are dynamic changes by the js as mentioned 2 above, it will only cause those elements 1 to render and repaint again.