Penn State is starting to leverage this so ship WCs across multiple properties regardless of the underlying system they are deployed in. Access any property then seeds browser cache so future import() calls are free.
-
Show this thread
-
Replying to @btopro
Do you have a live example? This is really interesting, but implies a pretty long request chain: https://cdn.webcomponents.psu.edu/cdn/build.js
1 reply 1 retweet 1 like -
Replying to @slightlylate
https://oer.hax.psu.edu/bto108/sites/ist402/ … - this is using the CDN. https://stem-researchethics.psu.edu/ru002/node/3 - this is using local copies of the CDN assets and is an older app. Our tooling generates https://cdn.webcomponents.psu.edu/cdn/wc-registry.json … autoloader entryway --https://github.com/elmsln/lrnwebcomponents/blob/master/elements/wc-autoload/wc-autoload.js …
1 reply 0 retweets 1 like -
Replying to @btopro @slightlylate
request chains can def get long; as we move further off polymer to lit-element / vanilla they reduce each time. HTTP2 w/ our preference toward hitting multiple properties I believe will see us be more efficient over the long run (students take multiple courses as example)
1 reply 0 retweets 1 like -
Replying to @btopro @slightlylate
or we throw a psu-logo on there w/ 0 dependencies; every app at the university then no longer compiles that and leverages the CDN'ed definition. CMS can effectively seed the caches of a PWA of which we have 1,000s of both type properties.
1 reply 0 retweets 0 likes -
Replying to @btopro @slightlylate
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
1 reply 0 retweets 0 likes -
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
Not sure if you saw what @dam and company did here:https://dev.to/begin/progressive-bundling-1gj2 …
-
-
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 - 9 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.