Interesting; someone found my prototype:https://www.chromestory.com/2018/10/google-is-testing-a-never-slow-mode-for-chrome/ …
-
-
-
Replying to @kpk
Currently breaks lots of stuff = ) Lots of pages (that continue to work) are faster/lighter. The connection limit alone is a godsend; it's an incidental ad and tracking script blocker.
2 replies 0 retweets 6 likes -
Replying to @slightlylate @kpk
Oof, those budgets are rough. Which of the 25 most popular sites DO work is the real question!?
1 reply 0 retweets 0 likes -
Replying to @ZackArgyle @kpk
They're per-interaction. User clicks/scrolls? You get more. I need to fix the image loading retry (last weekend's adventure was better logging for denied `doc.write()`).
2 replies 0 retweets 0 likes -
Other important caveats: no limits on script you load into workers, and content loaded from SW caches is "free".
1 reply 0 retweets 5 likes -
The goal is to keep the main thread responsive between interactions. You can do unbounded amounts of work and load unbounded amounts of script....just not badly.
1 reply 0 retweets 5 likes -
Replying to @slightlylate @kpk
This is really cool, Alex. I like the direction and interested to see where it goes. Would love a one-time max script size up to 100 for a vendor bundle.
1 reply 0 retweets 1 like
100KiB gzipped is a TON of script in one go; most of a MiB. Sure to make main thread unresponsive. Too much. Break it up.
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.