the times are still basically the same. I tested.
-
-
ok, i think we agree on this. but for js on the critical path,
@samccone is right, yeah?@tbreisacher@tdreyno -
JS off the critical path is super-common, and most likely target for pruning.
-
sure.
@samccone tweets *a lot* about code *on* the critical path. in that case, parse time is real, yeah?@tbreisacher@tdreyno -
yes, but the conclusion *literally everyone* draws from the chart is to go measure bytes over wire
-
and I think we're agreeing that bytes-over-wire is much less important than bytes-in-critical-path
-
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/
-
but the "bytes-over-wire" metric will tell you to force another XHR. 3/3
- 10 more replies
New conversation -
-
-
eliminating unused code from a payload may have little effect on end-to-end time, and further 4/
-
because people misunderstand lazy parse, it's common to accidentally cause unused code to be 5/
-
eagerly parsed (like optimizejs); a combination of changes that drastically reduces code size 6/
-
may significantly increase end-to-end time as a result, and I've seen it repeatedly. 7/7
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.