def. It'll get better as we keep moving off paper-elements to lit/vanilla/refactor some of our stuff. TTL/PWA settings we disabled as we're in rapid test/deploy. Would modulepreload / preload help in breaking up serialization? expected dynamic import() to do that a bit on its own
-
-
Replying to @btopro
So the way the PRPL pattern dealt with this was to use H/2 push on a per-route basis to ensure you didn't see this sort of stridation. That worked because the SW was "catching" subsequent top-level navigations to avoid over-push and doing granular caching of assets.
2 replies 0 retweets 1 like -
Replying to @slightlylate @btopro
Not sure if you saw what
@dam and company did here:https://dev.to/begin/progressive-bundling-1gj2 …1 reply 0 retweets 1 like -
Replying to @slightlylate @dam
I saw this pop up the other day and dug in a bit but the http/2 parallel pipe I thought would "solve" this issue unless of course you get really big execution chains so I guess I'm resolving my own thought here as I type this. So not entirely bundle but groups of chains
1 reply 0 retweets 1 like -
I think what's happening here is something to do with the credential mode that's preventing re-use. Might be worth checking.
1 reply 0 retweets 1 like -
Replying to @slightlylate @dam
yeah def seen a lot of weird behavior in testing this stuff w/ crossorigin / anonymous settings vs having them. Hard also at times to decipher if that's on-campus settings bc we have a Cosign / web-token based authentication system that runs server side for on-prem boxes
1 reply 0 retweets 0 likes -
Thank you btw; very difficult finding resources this deep in the weeds beyond human ones
1 reply 0 retweets 0 likes -
The desktop trace is where I'd focus for the moment: https://www.webpagetest.org/video/compare.php?tests=200415_PZ_db05ad75560225474f64fc4c6ddc2a8c-r:1-c:0 …
1 reply 0 retweets 1 like -
Things jump around until the ~7.5s mark, which is a tough experience: https://www.webpagetest.org/video/view.php?id=200415_620a0f4c9d97df28e3321306ee5d98c01ab10394 …
1 reply 0 retweets 0 likes -
Presumably the loading screen would stay in place until things are *actually* settled.
2 replies 0 retweets 1 like
When you look at this waterfall, what you *mostly* see is dead air time: https://www.webpagetest.org/video/compare.php?tests=200415_PZ_db05ad75560225474f64fc4c6ddc2a8c-r%3A1-c%3A0&thumbSize=200&ival=100&end=full … Each reqeust happens relatively quickly, but the amount of time burned is long because of the serialisation. This is crying out for some light bundling.
-
-
Nearly every resource in this waterfall is a tiny script, but they all have ~400ms TTFBs. That's what's really slowing things down.
1 reply 0 retweets 0 likes -
Is this pulling *everything* from?: https://cdn.webcomponents.psu.edu/cdn/wc-registry.json …
1 reply 0 retweets 0 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.