I spent some time tuning today, after my fixes we now are able to do an initial render in 3.5 seconds:
http://www.webpagetest.org/video/compare.php?tests=140708_QJ_AMX-r:1-c:0
My fixes included:
- Ensuring we compress all our dynamic and static content at a much higher level (10-15% network savings)
- Ensuring last modified date ships with all assets (avatars, letter avatars, cdn assets) - improves cdn perf
- Serving statically compressed assets where possible
This is pretty good considering we are
- Serving meta over HTTPS
- Our CDNs HTTPS performance is sub par
- We have no way of rendering anything before all the JS and CSS downloads.
The nature of the “JS application” beast is that rendering happens on the client side, this is a limitation of Ember.JS, it is possible that some time in the next few years we will be able to render the html server side. But … we would be talking a major architectural shift to support that.
Considering sites like Vanilla (a more traditionally designed non HTTPS site) take 2 seconds
http://www.webpagetest.org/video/compare.php?tests=140708_CW_ARE-r:1-c:0
And that IPBoards takes 2 seconds
http://www.webpagetest.org/result/140708_7H_AV4/
And that Discourse on non HTTPS without a CDN on digital ocean takes 3 seconds
So yeah, we are a second slower on initial render than the competition and about 1.5 seconds off from leaders in this area like say stackoverflow http://www.webpagetest.org/result/140708_VJ_AYX/
But… on the upside due to the fact we only need JSON to navigate around a site we perform significantly better once the site is loaded than traditional apps when dealing with constrained networks.
Its a balancing act, eventually I hope to have a server rendering story, but for the time being I think we are doing quite well.