Documentation
¶
Overview ¶
Command deferscripts adds defer to the scripts that can take it.
deferscripts page.html <script src="/a.js" defer></script>
A classic script with a src blocks parsing until it has downloaded and run. defer moves it to after parsing while keeping the execution order the page wrote, which is the safe half of the async/defer pair: async reorders, defer does not.
What it will not touch, and why each one would break something:
An inline script - no src - runs where it stands, and defer is ignored on it. Adding the attribute would be noise that reads as though it did something.
A module. type=module is deferred already, and marking it does nothing.
A script with async. The page asked for unordered execution; turning that into ordered execution is a decision about the page's own behaviour, not a fix.
A script inside the body, unless -body is given. Deferring one changes when it runs relative to the markup around it, and a script placed late in the body was often placed there deliberately - the pattern predates defer.
"Inside the body" is not "after a <body> tag". That start tag is omissible and a minifier will have removed it, so the body is taken to begin at the first element that is not head content - see headContent below. A rewrite that waits for the tag defers the whole body of any page that leaves it out, which is the one thing this list says it will not do.
One cosmetic thing it cannot help. There is no way to write a bare attribute through this API, so the output says defer="" where the page's own scripts say defer. Any parser treats those as the same attribute, since presence is what a boolean attribute means, but a diff will show two styles.
A script with document.write in reach. This cannot be detected from a src attribute, which is the honest limit of the program: deferring a script that calls document.write after parsing has finished blanks the page. So the report says how many were changed, and the caller is the one who knows whether their scripts do that.
Source Files