Do browsers parse javascript on every page load?

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.

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

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.

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.

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

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?

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.

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