you may, for example, want to include some extra bytes so subsequent interactions don't trigger 1/
-
-
network fetches. those bytes will have a net positive impact on the early user experience 2/
1 reply 0 retweets 2 likes -
but the "bytes-over-wire" metric will tell you to force another XHR. 3/3
1 reply 0 retweets 2 likes -
Replying to @wycats
in my experience, this is a second optimization. cutting critical path bytes makes a bigger diff.
@samccone@tbreisacher@tdreyno1 reply 0 retweets 0 likes -
I have seen even critical-path bytes (which nobody really measures) really mislead people.
2 replies 0 retweets 0 likes -
more directly, if critical-path-bytes was the metric, why is everyone measuring the size of libs?
1 reply 0 retweets 1 like -
Replying to @wycats
because they're often on the critical path?
@samccone@tbreisacher@tdreyno2 replies 0 retweets 1 like -
part of what bothers me is that I've been part of a team for the last 18 months whose entire job 1/
1 reply 0 retweets 1 like -
was to reduce end-to-end time of time-to-interactivity. chasing "bytes-over-wire" was probably 2/
2 replies 0 retweets 1 like -
the #1 source of wasted time and outright regressions. focusing on eagerly evaluated code 3/
1 reply 0 retweets 1 like
got us closer, but looking closely at how the browser parallelizes work, restructuring payloads 4/
-
-
identifying and eliminating slowdowns in the initial evaluation (deopts, etc.) all had a big 5/
1 reply 0 retweets 1 like -
impact, but competed against efforts that were counterproductive. Just lived experience here 6/6
0 replies 0 retweets 1 like
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.