: and both are exacerbated by size. CPU is biggest parse factor
-
-
There a standard scaling you're aware of? ie, for each unit of size, parsing _ fraction of download?
2 replies 0 retweets 0 likes -
Replying to @AdamRackis @_developit
:
@addyosmani did parse time work recently. Haven't seen a ratio. Might be interesting!3 replies 0 retweets 4 likes -
Replying to @slightlylate @AdamRackis and
Average SPA ships 420KB JS, spends 5s in startup (20-30% in parse), 10-15s to TTI. I wouldn't put a ratio on it (variance) but parse matters
3 replies 8 retweets 25 likes -
Replying to @addyosmani @slightlylate and
So it'd seem a very, very rough ballpark would be about 1s to parse 84K of JS?
1 reply 0 retweets 0 likes -
Replying to @AdamRackis @addyosmani and
Oh goodness, no, much, much less than that.
1 reply 0 retweets 0 likes -
Replying to @AdamRackis @addyosmani and
30% of 5 seconds is 1.5 - so mobile can parse 420K of JS in 1.5 seconds? That's ... great.
1 reply 0 retweets 0 likes -
Replying to @AdamRackis @slightlylate and
..and this gets increasingly depressing as we look at the difference in JS parse times on high-end vs low-end hardware (2x as slow s/times)
1 reply 2 retweets 5 likes -
original context here was what benefit
@_developit was scoring by squeezing kb's. It seems minimal :-|1 reply 0 retweets 0 likes -
Replying to @AdamRackis @addyosmani and
back of the envelope: seems *best case* cost savings of 40K would be .2s on worst hardware
2 replies 0 retweets 0 likes
: is that 40k pre or post gzip?
-
-
-
: I view this as a headroom question: how much is left in budget for app code?
1 reply 0 retweets 0 likes - 4 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.