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.