Those are running through a single I/O thread, which means you can often see a pile of index reads delaying body reads. The delay is bonkers-slow.
-
-
Replying to @slightlylate @kevinmarks and
This used to be much, much worse on image-heavy pages. Randy Smith invested a lot of time on fixing, bit I think progress there is stalled because Reasons
1 reply 0 retweets 1 like -
Replying to @slightlylate @kevinmarks and
My hope here is that servicification can help. It'll eliminate the single thread at the center of the picture.
1 reply 0 retweets 0 likes -
Yay! For now I'll look into just building my own in-process cache for these assets using indexedDB and blob URLs. Maybe it'll perform better.
2 replies 0 retweets 1 like -
Blobs do OK when data is already read thanks to the adaptive backing Daniel put in. Not sure IDB will do much better (but excited to hear how it goes).
2 replies 0 retweets 1 like -
Replying to @slightlylate @antumbral and
For context, I put near-zero stock in servicification ("s18n") *except* in cases like this where the I/O thread is loaded and tough to schedule.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @antumbral and
We've already seen some big wins in SW startup for similar reasons.
1 reply 0 retweets 0 likes -
Replying to @slightlylate
Is there a page describing the s18n efforts if I want to read about them?
1 reply 0 retweets 0 likes -
Replying to @antumbral
Lemmie see what I can dig up quickly from this here airport lounge...
1 reply 0 retweets 0 likes -
Replying to @slightlylate @antumbral
Not sure how current the linked docs are, but the network service is the furthest along: https://www.chromium.org/servicification
1 reply 0 retweets 0 likes
/cc @dougturner
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.