The new Microsoft Developer Portal loads insanely fast | Hacker News Reader

The new Microsoft Developer Portal loads insanely fast

dev.modern.ie

36 pointsluuio22 comments

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.

I got 600-1170ms with the cache disabled, and 410-515ms with it enabled.

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 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.

1.5s here. It's not the total time, but the way it loads, 3 bunches of very quick accumulations. Pleasurable to witness.

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.

There are quite a few things going on in the backend, GitHub info, feeds, uservoice... Is not just a static html file :)

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]

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).

[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.

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.

[Disclaimer: I'm the PM and lead dev of this project] This is a node website running on an Azure Websites. Nothing weird on the backend :)

Great work. Loving the new avatar of Microsoft, please pass those along to your team.

Thanks for the reply. I had to re-read your response "node website" threw me for a second, best of luck with Edge :).

Great example of what to expect from the Edge browser. Well done!

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

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.

Looks impressive.

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.

Deleted comment

Hmm, I clock in at < 100ms on Chrome

http://i.imgur.com/pBvA8Li.png

That's with resources cached. HTTP Status 304 means the resource was not modified, and thus can be retrieved from the local cache.

that really is fast

Reply on news.ycombinator.com