bundlephobia needs to add parse/execution time. download size is only part of the problem
-
-
Replying to @rossipedia @threepointone and
There is a lot of hidden cost to bundle size. Debugging, domain knowledge etc
1 reply 0 retweets 2 likes -
Replying to @richardiii @threepointone and
well, yeah... which is still only part of the problem. I wasn't trying to diminish its role, rather point out that parse/execution time are often overlooked and play as big a role in the end-user experience
2 replies 0 retweets 4 likes -
Replying to @rossipedia @richardiii and
Is there an easy way to get parse/execution time?
1 reply 0 retweets 0 likes -
Replying to @matthewcp @richardiii and
it's a bit complicated, as that depends quite a bit on what device it's running on. but a couple baselines numbers measured from popular devices would be helpful (iPhone, Galaxy, and possibly a lower end device as well)
1 reply 0 retweets 0 likes -
Replying to @rossipedia @richardiii and
Sorry, I was asking if you know of a way for a tool like bundlephobia to get this information (rather than rely on people to provide it for their own stuff)?
1 reply 0 retweets 0 likes -
-
Replying to @Rich_Harris @matthewcp and
Fyi parse/compile is pretty fast in V8 in many cases now. It's download + execution time dominating. Parse/compile can be measured via Lighthouse or Chrome DevTools Protocol. Look for the "scriptParseCompile" group. There are however some quirks with this today cc
@mathiaspic.twitter.com/bzWTRZNYUf
3 replies 0 retweets 22 likes -
Replying to @addyosmani @Rich_Harris and
Currently the only reliable way to get the main thread parse + compile cost is through chrome://tracing + RuntimeCallStats. Both Lighthouse and DevTools expose background thread time as well (which doesn’t matter, since it doesn’t block loading). We’re working to improve this!
1 reply 0 retweets 7 likes -
Replying to @mathias @addyosmani and
"doesn't block loading" is contingent. If you structure your app to depend on the script, it'll still "block" even of the work is on a different thread.
1 reply 0 retweets 0 likes
True. With ScriptStreamingOnPreload (which we hope to ship in Chrome 75), this becomes less likely though. In many cases we complete parse + compile by the time the HTML parser sees the starting <script> tag, and we can just start executing right away. @leszekswirski
-
-
Replying to @mathias @slightlylate and
Yes, and even if it's not ready, that's (mostly) due to network rather than parse. It's valuable to expose and to analyse, but as "download time" rather than "parse time" so that devs have a better idea of what to optimise (e.g. use brotli, invest in CDNs, etc.)
1 reply 0 retweets 1 like -
Replying to @leszekswirski @mathias and
Moving parse and compile out of the equation is truly awesome. Still, slow executing scripts can be blocking if that's how you built your app
1 reply 0 retweets 3 likes - 1 more reply
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.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.