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.
Nearly every resource in this waterfall is a tiny script, but they all have ~400ms TTFBs. That's what's really slowing things down.
-
-
Is this pulling *everything* from?: https://cdn.webcomponents.psu.edu/cdn/wc-registry.json …
-
all JS minus the initial https://oer.hax.psu.edu/bto108/sites/ist402/build.js?7k0k3JTfWDzJXNOLPzJLEf3nMagviTHEeQN6iS0P3Uo … which we can probably eliminate that gap by loading that off the cdn too since it's up there.
End of conversation
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.