Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Load script with the defer attribute (#1437)
Load script with the defer attribute
- Loading branch information
b2fabf0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note. this will defer the parsing but not make the window onload faster. It will not release the spinning circle of the browser but let other scripts which is not deffer get "higher" priority to parse before.
At least my understanding of it @arunoda, agree?
b2fabf0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it is.
Having a different solution takes times and we should need to do it and test more.
See: #1436 (comment)
So, we took this for 2.0 release. It's a much better than the current case :)
b2fabf0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👌
b2fabf0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if you guys load a single
async
script on the initial render. This can/would only contain your critical core bits, along with alocation
parser that fetches the necessary chunk(s) for the current page.First paint would decreased, as well as payload size. I'm doing this is in a local app right now...
With the current
examples/using-preact
(addingcompression
andexpress
):DOMContentLoaded
in 85msWith a direct clone of that example (using my
async
suggestion, but not Next.js):DOMContentLoaded
in 34msIn my first go-round, I had 2 scripts too, both with
defer
and myDOMContentLoaded
hovered around 65ms. A singleasync
was the way to go, at least for me.b2fabf0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lukeed async might execute before the DOM render. So, we are tracking here about a much better options. See: #1436
I think providing a single script makes sense. I'll give it a try.
b2fabf0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arunoda > async might execute before the DOM render
Shouldn't matter here. The
__NEXT__
var is populated from the server, and there are nodocument.write
instances that I can recall. But just by addingasync
, we unblock the render and let the (supported) browsers continue. Whenever the script loads, control of the DOM elements is handed off seamlessly, while the user has no idea. Aka, no screen flashes or jitter.b2fabf0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lukeed yes. Anyway, we need to make find a way to merge our two files.
That's the first thing to do.
After that, we can do either way.
I think we should do this before 2.0
b2fabf0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lukeed implemented with: #1485