3 ms·
ok, question. since i'm trying to shave some time off of load times on a new project. here's the network graph for the MS site [1], and i'm seeing the same thin
by leeoniya 12y ago
ok, question. since i'm trying to shave some time off of load times on a new project. here's the network graph for the MS site [1], and i'm seeing the same thing in my case.
why is the css download blocked until the entire markup is loaded when the css is in the head? it seems like the loading can start instantly, but instead you lose 200ms.
[1] http://i.imgur.com/sZJ3iAC.png http://i.imgur.com/sZJ3iAC.png
- evmar 12y agoHover your mouse over the the wide blue part on the right of the top line in the trace. You'll see that the time is spent in "Waiting (TTFB)" phase. TTFB = time to first byte, so it spends most of the time waiting for the document to begin. The complete transmission of the document once it begins is nearly instant. (I'm not clear on why there's a gap after that bar ends and before the CSS one begins, though.)
- leeoniya 12y agooh ok, i didn't realize blue was waiting. but then what on earth causes 100ms-200ms delay in serving a static css asset? i'm seeing this on my nginx setup as well with 0 traffic, static assets (fonts, css, js) "wait" anywhere from 80 to 200ms. is this a gzip delay? i imagine not. EDIT: nvm, i guess it's internet routing overhead. locally the "wait" 1-3ms. i suppose i can't get meaningfully below 250ms in real life.