Why Not doc.write()? – CSS Wizardry – Internet Efficiency Optimisation
Written by Harry Roberts on CSS Wizardry.
Desk of Contents
When you’ve ever run a Lighthouse take a look at earlier than, there’s a excessive probability you’ve seen
the audit Avoid
:
document.write()
For customers on sluggish connections, exterior scripts dynamically
injected through `doc.write()` can delay web page load by tens of
seconds.
You will have additionally seen that there’s little or no clarification as to why
doc.write() is so dangerous. Properly, the brief reply is:
From a purely performance-facing viewpoint, doc.write() itself
isn’t that particular or distinctive. In reality, all it does is surfaces potential
behaviours already current in any synchronous script—the one predominant distinction is
that doc.write() ensures that these unfavorable behaviours will manifest
themselves, whereas different synchronous scripts could make use of alternate
optimisations to sidestep them.
N.B. This audit and, accordingly, this text, solely offers with
script injection utilizing doc.write()—not its utilization typically. The MDN
entry for
document.write()
does an excellent job of discouraging its use.
What Makes Scripts Sluggish?
There are a selection of issues that may make common, synchronous scripts
sluggish:
- Synchronous JS can block DOM development whereas the file is downloading.
- The idea that
synchronous JS blocks DOM development
is barely true
in sure situations.
- The idea that
- Synchronous JS at all times blocks DOM development whereas the file is
executing.- It runs in-situ on the actual level it’s outlined, so something outlined after
the script has to attend.
- It runs in-situ on the actual level it’s outlined, so something outlined after
- Synchronous JS by no means blocks downloads of subsequent information.
- This has been true for almost 15 years
on the time of writing, but nonetheless stays a typical false impression amongst
builders. That is carefully associated to the primary level.
- This has been true for almost 15 years
The worst case situation is a script that falls into each (1) and (2), which is
extra more likely to have an effect on scripts outlined earlier in your HTML. doc.write(),
nonetheless, forces scripts into each (1) and (2) no matter once they’re
outlined.
The Preload Scanner
The explanation scripts by no means block subsequent downloads is due to one thing
known as the Preload Scanner. The Preload Scanner is a secondary, inert,
download-only parser that’s chargeable for working down the HTML and
asynchronously requesting any accessible subresources it’d discover, mainly
something contained in src or href attributes, together with photographs, scripts,
stylesheets, and so on. Because of this, information fetched through the Preload Scanner are
parallelised, and may be downloaded asynchronously alongside different (doubtlessly
synchronous) sources.
The Preload Scanner is decoupled from the first parser, which is accountable
for developing the DOM, the CSSOM, working scripts, and so on. Because of this
a big majority of information we fetch are completed so asynchronously and in
a non-blocking method, together with some synchronous scripts. Because of this not all
blocking scripts block throughout their obtain part—they might have been fetched by
the Preload Scanner earlier than they have been truly wanted, thus in a non-blocking
method.
The Preload Scanner and the first parser start processing the HTML at
more-or-less the identical time, so the Preload Scanner doesn’t actually get a lot of
a head begin. Because of this early scripts usually tend to block DOM
development throughout their obtain part than late scripts: the first parser
is extra more likely to encounter the related <script src> component whereas the file
is downloading if the <script src> component is early within the HTML. Late (e.g.
at-</physique>) synchronous <script src>s usually tend to be fetched by the
Preload Scanner whereas the first parser remains to be hung up doing work earlier in
the web page.
Put merely, scripts outlined earlier within the web page usually tend to block on
their obtain than later ones; later scripts usually tend to have been
fetched preemptively and asynchronously by the Preload Scanner.
doc.write() Hides Information From the Preload Scanner
As a result of the Preload Scanner offers with tokeniseable src and href attributes,
something buried in JavaScript is invisible to it:
<script>
doc.write('<script src=file.js></script>')
</script>
This isn’t a reference to a script; it is a string in JS. Because of this the
browser can’t request this file till it’s truly run the <script> block
that inserts it, which may be very a lot just-in-time (and too late).
doc.write() forces scripts to dam DOM development throughout their
obtain by hiding them from the Preload Scanner.
What About Async Snippets?
Async snippets such because the one beneath endure the identical destiny:
<script>
var script = doc.createElement('script');
script.src = 'file.js';
doc.head.appendChild(script);
</script>
Once more, file.js is just not a filepath—it’s a string! It’s not till the browser has
run this script that it places a src attribute into the DOM and might then request
it. The first distinction right here, although, is that scripts injected this manner are
asynchronous by default. Regardless of being hidden from the Preload Scanner, the
impression is negligible as a result of the file is implicitly asynchronous anyway.
That mentioned, async snippets are still an
anti-pattern—don’t use them.
doc.write() Executes Synchronously
doc.write() is sort of solely used to conditionally load
a synchronous script. When you simply want a blocking script, you’d use a easy
<script src> component:
<script src=file.js></script>
When you wanted to conditionally load an asynchronous script, you’d add
some if/else logic to your async snippet.
<script>
if (situation) {
var script = doc.createElement('script');
script.src = 'file.js';
doc.head.appendChild(script);
}
</script>
If that you must conditionally load a synchronous script, you’re kinda caught…
Scripts injected with, for instance, appendChild are, per the spec,
asynchronous. If that you must inject a synchronous file, one of many solely
simple choices is doc.write():
<script>
if (situation) {
doc.write('<script src=file.js></script>')
}
</script>
This ensures a synchronous execution, which is what we wish, but it surely additionally
ensures a synchronous fetch, as a result of that is hidden from the Preload Scanner,
which is what we don’t need.
doc.write() forces scripts to dam DOM development throughout their
execution by being synchronous by default.
Is It All Unhealthy?
The situation of the doc.write() in query makes an enormous distinction.
As a result of the Preload Scanner works most successfully when it’s coping with
subresources later within the web page, doc.write() earlier within the HTML is much less
dangerous.
Early doc.write()
<head>
...
<script>
doc.write('<script src=https://slowfil.es/file?sort=js&delay=1000></script>')
</script>
<hyperlink rel=stylesheet href=https://slowfil.es/file?sort=css&delay=1000>
...
</head>
When you put a doc.write() because the very very first thing in your <head>, it’s
going to behave the very same as a daily <script src>—the Preload Scanner
wouldn’t have had a lot of a head begin anyway, so we’ve already missed out on
the prospect of an asynchronous fetch:
doc.write() as the very first thing within the <head>. FCP is at 2.778s.Above, we see that the browser has managed to parallelise the requests: the
major parser ran and injected the doc.write(), whereas the Preload
Scanner fetched the CSS.
Owing to CSS’ Highest precedence, it is going to at all times be requested earlier than
Excessive precedence JS, no matter the place every is outlined.
If we substitute the doc.write() with a easy <script src>, we’d see the
very same behaviour, which means on this particular occasion, doc.write() is
no extra dangerous than a daily, synchronous script:
<head>
...
<script src=https://slowfil.es/file?sort=js&delay=1000></script>
<hyperlink rel=stylesheet href=https://slowfil.es/file?sort=css&delay=1000>
...
</head>
This yields an equivalent waterfall:
<script src> as a substitute of doc.write(). FCP is at 2.797s.As a result of the Preload Scanner was unlikely to search out both variant, we don’t
discover any actual degradation.
Late doc.write()
<head>
...
<hyperlink rel=stylesheet href=https://slowfil.es/file?sort=css&delay=1000>
<script>
doc.write('<script src=https://slowfil.es/file?sort=js&delay=1000></script>')
</script>
...
</head>
As a result of JS can write/learn to/from the CSSOM, all browsers will halt execution of
any synchronous JS if there’s any previous, pending CSS. In impact, CSS
blocks
JS,
and on this instance, serves to cover the doc.write() from the Preload
Scanner.
Thus, doc.write() later within the web page does turn out to be extra extreme. Hiding
a file from the Preload Scanner—and solely surfacing it to the browser the precise
second we’d like it—goes to make its total fetch a blocking motion. And,
as a result of the doc.write() file is now being fetched by the first parser
(i.e. the primary thread), the browser can’t full some other work whereas the file
is on its manner. Blocking on high of blocking.
As quickly as we cover the script file from the Preload Scanner, we discover
drastically completely different behaviour. By merely swapping the doc.write() and
the rel=stylesheet round, we get a a lot, a lot slower expertise:
doc.write() late within the <head>. FCP is at 4.073s.Now that we’ve hidden the script from the Preload Scanner, we lose all
parallelisation and incur a a lot bigger penalty.
It Will get Worse…
The entire motive I’m penning this put up is that I’ve a shopper in the intervening time who
is utilizing doc.write() late within the <head>. As we now know, this pushes
each the fetch and the execution on the primary thread. As a result of browsers are
single-threaded, because of this not solely are we incurring community delays
(due to a synchronous fetch), we’re additionally leaving the browser unable to work
on anything for all the period of the script’s obtain!
fetch. This doesn’t occur when information are fetched from the Preload Scanner.
Keep away from doc.write()
In addition to exhibiting unpredictable and buggy behaviour as keenly harassed in
the MDN and
Google articles,
doc.write() is sluggish. It ensures each a blocking fetch and a blocking
execution, which holds up the parser for a lot longer than mandatory. Whereas it
doesn’t introduce any new or distinctive efficiency points per se, it simply forces
the worst of all worlds.
Keep away from doc.write() (however not less than now you understand why).