Partial hydration causes Preact to be fetched twice
Siilwyn opened this issue · comments
Seems like when using partial hydration Preact is fetched twice, the hydration example is a good example that shows this issue. Pun intended ;)
Might be related to #106 ?
Ah, I see what's happening here. Skypack has two different ways to reference a package, Lookup URLs (preact@10.x.x) and Pinned URLs (/pin/preact@v10.x.x-hash).
I don't think Preact is actually being fetched twice, but the Lookup URL introduces another network request and unnecessary latency. I'll switch over to using Pinned URLs.
Ah I see, didn't look at the actual payload...
Thought I would make a PR for this, seems like these links need to be changed:
Currently the Preact URL resolves to:
https://cdn.skypack.dev/pin/preact@v10.5.5-PqUUDAM9QPWYYL2uxjUu/mode=imports,min/optimized/preact.js
However I think ideally this link would be generated in the build file, which does add complexity while I think going for a 'local' Preact version is a better solution. Shall I close this in favor of #106?
It shouldn't be too difficult to resolve the pinned url, there is an x-pinned-url header on the Skypack response. I'm going to try to tackle this tonight since I already took a pass at #106 and it's unfortunately quite involved.
To clarify, I want to support both options! Resolving the pinned URL seems easier to land for v1.1.0. #106 will probably be addressed in the next minor version.
I'm going to try to tackle this tonight since I already took a pass at #106 and it's unfortunately quite involved.
Once I come up for air on the final touches on the final launch task for my site (I’m aiming for tomorrow), this is something I’d like to try to work on with you if you’re interested. I know the internals pretty well but it’d help me make sense of where the various build events happen.
Also, it’s ambitious but I think tying this with #99 could help reduce the complexity on this one. I’ve already got two custom (future OSS) plugins that use the Snowpack optimize step to operate on the built staging files in situ and this could potentially be a way around the multiple instances of Preact constraint. A general final-phase plugin that allows post processing the first build phase from the same state with the same logic Microsite used for its second phase would also be an API improvement.
RE: the actual issue as reported, a big part of my motivation for #106 besides cache partitioning is that at least at present the Snowpack redirect causes a ~300ms waterfall on my connection, and their cache headers don’t help despite versioned URLs that could allow infinite caching for semver.
Probably something snowpack could improve both with headers and final resolution (hint to recent snowpack employees, subtle hint to recent snowpack employees who might be able to recruit if y’all want help improving the CDN)
Supporting both is fine, what are your thoughts on the default though? I really strongly think using the CDN should be opt-in behaviour.
@Siilwyn I agree with that! Local will always be better for performance.
- v1.1.0 will remain on Skypack, purely because there are too many unrelated fixes/features that have needed to go out for a while.
- v1.2.0 will load Preact from a local
vendorchunk by default. I can start on the architectural changes ASAP. Would love your help @eyelidlessness!
I'm about to push the pinned URL change and close this ticket. Followup can be handled in #106. As for the perf impact, switching to pinned URLs combined with link rel="modulepreload" cuts the initial waterfall significantly—consistently under 100ms in my testing versus the current 400-600ms.
That’s a major improvement!
Yes nice! 🥳