figure 4. monitor the time required to parse and evaluate your Javascript.

<script> var start_checkpoint = new Date();

</script> <script> var parsed_checkpoint = new Date();

// more script here var eval_checkpoint = new Date(); var parse_time = parse_checkpoint - start_checkpoint; var eval_time = eval_checkpoint - parse_checkpoint; </script>

figure 5. Declaring a block of Javascript for deferred parsing.

You can compute the load time of the page with:

window.performance.responseEnd - window.performance.navigationStart

and document load time with:

window.performance.loadEventEnd - window.performance.responseEnd.

 

ond script tag begins. The second script is then loaded and parsed, and the time is recorded in the parse checkpoint (which technically includes a tiny bit of execution of the second script tag, but this is neglected and billed to the parser). The eval checkpoint is recorded only after your business logic has all been evaluated.

Chrome on Android now offers a much more powerful technique to debug startup time: using window.performance to read perfor-mance-related timestamps in the code. Figure 5 illustrates how to compute the load time of the page. Whether you are using JavaScript Date objects or the new window.performance timestamps, it is a good idea to record this number by making a request to your server side so that you can track page-load metrics as a basic performance indicator of your site—it is so easy to regress that without continuous monitoring, performance is almost sure to degrade over time.

It is highly instructive to look at these numbers to appreciate how bad parse time is, and then to apply tricks to avoid parse latency. The most powerful of these tricks is allowing the browser to load your JavaScript without recognizing it as script and defer parsing and initial evaluation to a time of your choosing.

There are two methods for accom-
plishing this. The older one is com-
menting out your JavaScript and using
another block of script to uncomment
the content of the tag only when it is
needed, as described in the Google
mobile blog post from 2009.3 More re-
cently, a cleaner technique has been
used for the same purpose. It involves
setting the type of the script to an un-
recognized type and changing it to
text/JavaScript later. In this approach,
you start with script blocks that look
like this:

<script type=”deferred” id=”module1”> var start_ checkpoint = new Date(); </script>

 

When you are ready to use the script, the JavaScript finds the script tag and modifies the type, which will cause the browser to parse and evaluate it at that time.

By putting your deferred script at the bottom and uncommenting it only when needed, you can very effectively amortize the cost of using JavaScript across the runtime of your application. If your modules are small enough, this technique is cheap enough to be applied at the moment the user first clicks a button or link that needs the script, which can be uncommented, parsed, evaluated, and executed with no noticeable latency.

Avoid Layout and Style Calculation.
One of the easiest ways of introducing
unexpected latency into a site is inad-
vertently causing the browser to lay out
the document. Seemingly innocuous
JavaScript can trigger style recomputa-
tion in the midst of execution, while a
rearrangement of the same code can
be much more efficient.