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 …
-
-
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 -
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.
-
-
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 - 7 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.