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.
Chrome : V8 Engine
Update – 19/03/2015
- Script Streaming
Starting in version 41, Chrome parses async and deferred scripts on a separate thread as soon as the download has begun. This means that parsing can complete just milliseconds after the download has finished, and results in pages loading as much as 10% faster.
- Code caching
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. Across all page loads, this allows Chrome to avoid about 40% of compile time and saves precious battery on mobile devices.
Opera : 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,
Firefox : SpiderMonkey Engine
Nanojit as its native back-end, a JIT compiler. 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
The trace monitor’s initial state is monitoring. This means that
spidermonkey is interpreting bytecode. 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. This number is called the hit count for the PC. If the hit
count of a particular PC reaches a threshold value, the target is
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. 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. 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.
It’s been pointed out that Mozilla developer Boris Zbarsky has stated that Gecko does not cache compiled scripts yet. Taken from this SO answer.
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
this at the moment.
This was written by Maciej Stachowiak, the lead developer of Safari. 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.
IE : Chakra Engine
JScript Classic acts like a compiled language in the sense that before any JScript Classic program runs, we fully syntax check the code, generate a full parse tree, and generate a bytecode. We then run the bytecode through a bytecode interpreter. In that sense, JScript is every bit as “compiled” as Java. The difference is that JScript does not allow you to persist or examine our proprietary bytecode. Also, the bytecode is much higher-level than the JVM bytecode — the JScript Classic bytecode language is little more than a linearization of the parse tree, whereas the JVM bytecode is clearly intended to operate on a low-level stack machine.
This suggests that the bytecode does not persist in any way, and thus bytecode is not cached.
Opera does it, as mentioned in the other answer. (source)
Firefox (SpiderMonkey engine) does not cache bytecode. (source)
WebKit (Safari, Konqueror) does not cache bytecode. (source)
I’m not sure about IE[6/7/8] or V8 (Chrome), I think IE might do some sort of caching while V8 may not. IE is closed source so I’m not sure, but in V8 it may not make sense to cache “compiled” code since they compile straight to machine code.
It’s worth nothing that Google Dart explicitly tackles this problem via “Snapshots” – the goal is to speed up the initialization and loading time by loading the preparsed version of the code.
InfoQ has a good writeup @ http://www.infoq.com/articles/google-dart
I think that the correct answer would be “not always.” From what I understand, both the browser and the server play a role in determining what gets cached. If you really need files to be reloaded every time, then I think you should be able to configure that from within Apache (for example). Of course, I suppose that the user’s browser could be configured to ignore that setting, but that’s probably unlikely.
Because whenever a page is loaded by the browser, it creates 2 trees
1.Content tree and