
Do browsers parse javascript on every page load? - dazbradbury
http://stackoverflow.com/a/9261355/892397
======
wingo
Parsing is not the slow part.

Fetching js over the net is slow (multiple orders of magnitude slower than
parsing).

Optimized compilation is slow (an order of magnitude).

But you can't even do baseline compilation without knowing what's in your
evironment. For example, JSC (from WebKit) compiles to bytecode. But the
compilation process happens lazily, as functions are first executed. (There is
a quick pass to check syntax, beforehand. V8 does this too AFAIR.)

But OK, let's say you're parsing. You parse, create an AST, and go to compile
it. The result of bytecompiling for V8 is native code! You can't cache that
effectively, it will embed too many runtime constants. For JSC you do produce
bytecode, but that bytecode too is dependent on runtime object layouts: for
example if you reference a binding in the global object, and the binding is
present, then the compiler will produced an indexed lookup into the global.
That depends on what's in the global when the compilation unit (function,
eval, or global code) is compiled. Caching is a security / correctness risk,
in that context.

And then you have the negative impacts of caches on browser memory footprint
(and associated GC cost).

It's no wonder why modern JS engines prefer to just keep around the source,
and re-parse on demand.

~~~
aristus
You might be surprised. I ran some benchmarks[0] and found a significant parse
time, and significant differences between browsers. tldr: a) parsing has a
measurable cost, b) the parser is different from the interpreter, and the
speed of one has little or no bearing on the other.

[0] A Hidden Cost of Javascript (2010)
[http://carlos.bueno.org/2010/02/measuring-javascript-
parse-a...](http://carlos.bueno.org/2010/02/measuring-javascript-parse-and-
load.html)

~~~
wingo
Lovely article!

I wonder though, how do you know that is parsing time? There are a number of
things happening when JS is loaded, and parsing is only one of them.

Also, an update on that article would probably be useful -- a number of things
have changed in the major browsers since you wrote it.

Happy hacking :)

~~~
aristus
I handwave it by calling it "parse and load" time. ;)

------
bialecki
The important bit is from the Safari guys:

"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."

Basically, it's not going to be a bigger saver compared to all the other parts
of the process (e.g. fetching the file over the network).

------
vaksel
what I don't understand, is why browsers don't just include the core stuff
like that in the actual build.

There are like a dozen javascript frameworks that people use...so why not keep
the latest copy of jquery and YUI for example on the user's harddrive? Surely
there is space for say, 2-3mb of different javascript libraries.

Then all you have to do is simply ignore the jquery/yui inclusion code when
you render the page, and just load it from the harddrive instead.

No sweat for you, but your users and developers might actually find that when
they use your browser they get a slightly faster experience.

~~~
whichdan
Someone in another thread (sorry, don't remember which) made a good point that
including several frameworks by default would discourage people from trying
new/novel/less popular frameworks.

I think linking to the library from Google's CDN is a nice compromise since it
greatly increases the chance that it'll already be cached.

~~~
vaksel
I don't see why that would affect anything.

You can always link to the framework, so at worst your user will find the site
a few seconds slower to load.

Then if there is adoption, you can always be included in the next build of the
browser. All these frameworks tend to be tiny(i.e. jquery is huge, but is
something like 30 kb), so nothing is stopping the browser from including all
the possible frameworks on the harddrive.

~~~
whichdan
I wonder whether enough developers would care about that extra few seconds on
the initial view to make a noticeable impact?

------
Jarred
If you want to remove the need to redownload global assets/parse them on every
page load, you can use pjax to do so. It'll only reload certain parts of the
page that you specify, meaning if, for example, you're using Rails 3.X and all
the code for the views require jquery and the jquery_ujs adapter, you'd stick
that into your application.js manifest.

In your views you'd have a javascript_include_tag (or just the src tag) to
that view's JS file. From there, between clicking on links within the same
domain, it'll only reload the parts you tell it to.

There's a gem that does this for Rails <https://github.com/nz/pjax-rails> and
if you're not using Rails there's a version dependent on jQuery
<https://github.com/defunkt/jquery-pjax>.

------
abarth
Chrome also caches the compiled JavaScript in the HTTP disk cache. The biggest
performance wins are for large scripts used by many web sites (such as
jQuery).

------
robocat
V8: "This stores compiled JavaScript using a hash of the source for up to 5
garbage collections."

Hmmmm - is that across sessions? Does that mean I can detect if a user has
visited other sites by timing how long it takes to eval a static script copied
from those sites?

------
tmeasday
I've been wondering the same thing about CSS recently. With the advent of SCSS
and other CSS preprocessors our CSS files are blowing out of late, and I am
starting to worry about parsing time.

Does anyone have any good sources on a) caching of CSS parse trees b) what the
latest thinking is on CSS file size, # of selectors, complexity of selectors
for page load times.

Thinking of writing something about this myself but I am wondering what's out
there.

------
nreece
JavaScript loading and parsing, both, have an impact on page performance.

I recently wrote a summary of our (related) analysis and experience with
jQuery Mobile and Sencha Touch - [http://blog.roveb.com/post/17259708005/our-
experience-with-j...](http://blog.roveb.com/post/17259708005/our-experience-
with-jquery-mobile-and-sencha-touch)

~~~
erichocean
JavaScript parsing speed is mostly a problem on mobile devices, not desktop
browsers.

~~~
nreece

      Google found that moving from a 10-result page loading in 
      0.4 seconds to a 30-result page loading in 0.9 seconds 
      decreased traffic and ad revenues by 20%. Tests at Amazon 
      revealed similar results: every 100ms increase in load time 
      of Amazon.com decreased sales by 1%.

