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/ …
-
-
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
was doing h/2 push and read some Gdoc analysis that was it sending assets beyond what we'd need in a request. in this methodology the unbundling lets the dynamic / normal imports resolve the execution as needed. Specific in this app we could modulepreload the known common route.
1 reply 0 retweets 0 likes -
Replying to @btopro @slightlylate
we were caching the cdn hits in some earlier builds and while amazing (fully offline then obv) it was making testing nearly impossible. Still running into an issue of attempting to figure out when the assets are new via push / new build avail as weak point for this too
1 reply 0 retweets 0 likes -
Replying to @btopro @slightlylate
trying to balance 0 config build / implementation routine w/ apps that could further optimize for performance. Thank you for running through this though I really appreciate it. I've had trouble explaining it to ppl as to why it changes the DX dramatically for front-end newbees
1 reply 0 retweets 0 likes -
Replying to @btopro
So that's what PRPL did that most folks don't grok: it avoids overpushing by never re-requesting the top-level page that triggers pushes in the first place (because of the SW, which can rewrite top-level requests).
2 replies 0 retweets 1 like -
Replying to @slightlylate @btopro
The less aggressive version is some bundling variant, ala
@dam'shttps://dev.to/begin/progressive-bundling-1gj2 …1 reply 0 retweets 0 likes -
A few other things from this trace jump out: 1.) I'm seeing multiple H/2 connection setups to https://cdn.webcomponents.psu.edu/ . Seems like it could collapse to 1? 2.) https://oer.hax.psu.edu/bto108/sites/ist402/files/IMG_20190823_102434%202.jpg … is very big! On a slow link, starving other fetches.
2 replies 0 retweets 1 like
Running that image through http://squoosh.app gets me pretty quickly to a resource that's ~20K (down from ~100K).
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.