we've been using a modified version of this in production for months but switched to this the other day which I think is a game change for adoption (a few gov agencies also moving to this methodology) so looking for compare / contrast cause I haven't seen a comparable methodology
-
-
Replying to @btopro
I'd be looking to see if there's a way to predict which modules will be needed based on route or some other hint from the client so you could start to push or bundle them. This is on a fast link: https://www.webpagetest.org/result/200415_PZ_db05ad75560225474f64fc4c6ddc2a8c/ …
1 reply 0 retweets 1 like -
Replying to @slightlylate @btopro
Here's the same on a lower device/network: https://www.webpagetest.org/result/200415_QM_aa8a7414b2f21babbdf4d0f945c831aa/ … It's a lot if script, but not enough to justify loading *that* slowly. The serialisation is what's really killing here.
1 reply 0 retweets 1 like -
Replying to @slightlylate
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
1 reply 0 retweets 0 likes -
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 …
-
-
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 - 4 more replies
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.