| Re: [orion-dev] LotD: "Improving performance on twitter.com" |
Wow, it sounds like they could be talking about us!
On the topic of client vs server rendering, there is an experimental shift in banner rendering in the navigator page on the next build that gets deployed. I mentioned this at yesterday's meeting.
About a year ago we talked about templating the common page elements and how to achieve it. We literally had copied common page elements in the HTML, which was livable when there were about 2 Orion pages, but we were dying once we had more pages to maintain. We didn't want to server side include and have to round trip for common elements, so I consolidated the HTML includes on the client (I called this poor man's client-side templating [1]). This "stop gap solution" is still in place.
The experiment in the soon to be deployed build was to literally copy the banner elements back into the navigator HTML and eliminate the "white page until content" styling/code. It's not very interesting, except that on the navigator, you do see a little bit of the banner and some "Loading" feedback immediately.
My question to everyone is whether the effect on navigator is improved enough to keep experimenting. We'd have to include a build step that generated the common HTML fragments into the pages. On self hosted (non-built) sites, we'd still be running the old client side generation. We could also look at how to improve the shape of that instant page, perhaps with styling/positioning code that puts the basic shape in and tells you what's going to fill in in the empty holes.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=334907
susan
Mike Wilson ---06/01/2012 05:21:34 AM---http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html McQ.
From: Mike Wilson <Mike_Wilson@xxxxxxxxxx>
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date: 06/01/2012 05:21 AM
Subject: [orion-dev] LotD: "Improving performance on twitter.com"
Sent by: orion-dev-bounces@xxxxxxxxxxx
