Open babeard opened 3 years ago
thanks for tracking this down. I wonder if the better fix wouldn't be to wait to call start
on load instead instead in https://github.com/sveltejs/sapper-template/blob/master/src/client.js
Huh. What exactly needs to wait for what - and what needs to be fixed - now that Sapper is using <script defer>
? https://github.com/sveltejs/sapper/pull/1123
Defer or not doesn't seem to affect the hydration/duplication problem unfortunately. I'm not sure why because spec says that deferred scripts are fetched in parallel and evaluated when the page has finished parsing.
I'm not quite sure what else would be going on beside's Chrome not strictly adhering to spec. In Firefox, for example, this issue does not appear.
Why is the window load event preferred over moving scripts to the end of the body? Just curious.
Also, sorry for the poor "gitfu". I'm learning as I go. Any pointers are appreciated!
Why is the window load event preferred over moving scripts to the end of the body? Just curious.
The the script is encountered soon and can start being parsed sooner. Probably doesn't make much of a difference with the small document size, but it is better practice
I'm also questioning now whether the document not being loaded yet would result in the behavior being seen.
My original hypothesis may be totally incorrect, but the two fixes below do resolve the issue we're seeing. Now the question is why. Do you think Chrome's disk cache retrieval could be at play here? As in the cached resource not being deferred but being retrieved and evaluated before it needs to be?
%sapper.scripts% can be moved to the <head> section for slightly better performance
.%sapper.scripts%
to body
Fixes a problem where elements were being duplicated upon re-hydration on slower connections. See https://github.com/sveltejs/sapper/issues/1725