Astroturfing is the practice of masking the sponsors of a message or organization to make it appear as though it originates from and is supported by grassroots participants. It is a practice intended to give the statements or organizations more credibility by withholding information about the source's financial connection. [0]
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.
Hover 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.)
oh 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.
1 HTML page (of course), 1 JS file (discounting analytics), 2 CSS, and some assets. As it should be! So many sites overdo it with frameworks. Good to see MS improving these days.
It looks like most of the images are .svg, and the majority of their assets are coming from the same URL which could help them pipeline the resources if the server is using SPDY or HTTP 2 (though it looks like HTTP 1.1 to me).
It's mostly a static website so I don't really know what's so fascinating about it loading fast. Nothing to see here, move along.
There is something amazing about it, this is a major site, and I'd say there are many web developers that can tell you how hard it is to fight business requirements that insist on bloating the payload. They need 6 analytics, 4 ad slots, 4 different stylesheets, 10 different domains.
It's got a vertical carousel that offers no navigation between the two states, gives no indication it's even there ... exactly what I've come to expect from MS's approach to the web.
http://dev.modern.ie/
Empty cache load 340kB in 2.92s for me on FF 37.0.1. [403kB in 2.70s on Chrome 42.0.2311.90]
Edit: What surprises me a little is that neither of these resources gets a brilliant PageSpeed score. developer.mozilla.org doesn't minify all its javascript; dev.modern.ie apparently isn't compressing all its SVG nor specifying image dimensions. Would be interesting to read the rationale for these decisions (I assume on such big site there is one).
[Disclaimer: I'm the PM and lead dev of this project]
Basically the rationale is that it is a beta website and we didn't had the time to do all the optimizations we want. More updates and sections should be coming in the next few weeks.
I think the fact that animations are occurring right away is what contributes to the illusion. Most sites with any kind of animation aren't using CSS for it yet, and on those sites the javascript (which usually begins execution late in the rendering) introduces extra time to load any kind of animation, leading to a perception of slowness that is actually occurring client side.
So is this IIS spitting out a highly optimized version of a standard none optimised ASP project? Or the work of a well versed front-end engineer producing a solid example of optimised web practices? Cause if its the first that would be nice.
27 comments
[ 2.4 ms ] story [ 53.9 ms ] threadhttp://i.imgur.com/pBvA8Li.png
[0] - http://en.wikipedia.org/wiki/Astroturfing
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
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.
It's mostly a static website so I don't really know what's so fascinating about it loading fast. Nothing to see here, move along.
http://dev.modern.ie/ Empty cache load 340kB in 2.92s for me on FF 37.0.1. [403kB in 2.70s on Chrome 42.0.2311.90]
https://developer.mozilla.org/en-US/?icn=tabz Empty cache load 630kB in 2.65s for me. [714kB in 3.56s on Chrome]
Nice tools though.
Edit: What surprises me a little is that neither of these resources gets a brilliant PageSpeed score. developer.mozilla.org doesn't minify all its javascript; dev.modern.ie apparently isn't compressing all its SVG nor specifying image dimensions. Would be interesting to read the rationale for these decisions (I assume on such big site there is one).
That's fine. I wouldn't call it "insanely fast" though (or even just fast... it's just ok).
Has the bar dropped this low that we now think 500ms is "insanely" fast?
I'm on a corporate network (not Microsoft) near Redmond, and I get everything in <400ms with cache disabled. This is similar to HN or 1/10th Facebook.