Home > Blogging Toolchains, Mac OSX > Early thoughts on NewsGator Online Beta

Early thoughts on NewsGator Online Beta

February 28, 2007

My RSS newsreader of choice is NetNewsWire. I had purchased it a few months before Brent Simmons sold his company to NewsGator and as a result of that purchase, I was able to obtain a premium NewsGator Online subscription for 2 years which allowed for synchronization of my desktop Mac with the web-based reader.

The web-based reader NewsGator Online whilst functional was not known for its performance, an area touched upon by Michael Arrington of TechCrunch in a recent post which analysed market share of various online readers

Newsgator online, a feature fantastic service long plagued with deal-breaking performance problems, is trailing in third place with a mere %3 of views. The company’s desktop feed readers, NetNewsWire and FeedDemon, probably have a much larger percentage of views as they are older, more stable products.

After reading an editorial on ajaxian wrt newsgator perceived slowness, I wrote to a few newsgator employees and investors about some ideas I thought which might improve performance

I had discussed these in my community blog a while back

Brian Kellner (GM consumer) wrote back to me that they were going to launch an ajax version of their online reader which would reduce page refreshes and was optimized for client side caching. Today, I received instructions on how to access the beta site. The email from Brian indicated that it was okay to blog about it (yeah, no NDA unlike the Joost invite I got)

I fired up Fiddler and tried to analyse the network traffic. As someone who lives in a different continent to NewsGator servers in a city with tremendous local connectivity, web traffic analysis via a sniffer is a regular excercise

Some early disappointments

Looking at the traffic sent out by Newsgator Online beta via Fiddler , I see that there is a lot of request/response for content with type image/gif and image/jpeg coming from http://www.newsgator.com without any cache-friendly headers (Expires, Cache-Control)

Some Suggestions for performance improvement

Always send images with a Cache-Friendly header

Move the images to either a separate domain or a new sub-domain. Currently because the images are sent from newsgator.com, there is an unnecessary Cookie: header sent from the browser for all images. It should be easy for newsgator to buy a new domain and use that exclusively for image/static content serving.

An example of a request for http://www.newsgator.com/ngs/subscriber/reader/img/folderopen.gif generates a request of size 1025 bytes (dominated by the Cookie: header) for a response of 677 bytes which is further divided into an actual payload (image size) of 353 bytes and 324 bytes for the header. Remove the Cookie header and the request becomes only 334 bytes. One could tune the image server a bit and reduce the bytes used by the response header

Also, one would expect all html/javascript to be sent via Content-Encoding: gzip for all responses of those Content-type but there are quite a number of responses of those content type sent without being gzipped.

I can understand some reluctance with gzipping Javascript since there are quirks with IE (though if I remember correctly, IE6 SP2/IE 7 handles this correctly). Even use of jsmin would give around 25-30% reduction in size

On the bright side, page refreshes are reduced a lot in the beta.

Technorati Tags :

Advertisement
  1. February 28, 2007 at 7:22 am

    Hi Yusuf,

    First off thank you very, very much for the technical review. Your input as a customer is invaluable to us and

    is integral to our ‘customer.com’ development process. You bring up some great points!

    Specifically:

    1) Putting static images and in a domain other than ngs\subscriber and using more friendly cache headers is

    something we’ll experiment with, completely agreed!

    2) We do have gzip compression for JS coming from the end-point in our data JSON objects but we made a

    conscious decision not to do this for the JS framework for the initial Beta as the savings we observed in that

    area were not too dramatic. We are planning on doing this prior to production. In fact the JS Framework code will (in all likelihood) be a single compressed and obfuscated file.

    In addition to the performance gains we are looking for, the new architecture will allow us to add features quickly and the team is very eager to get on with those activities now that we have the new technology stack in place.

    Thank you for your valuable feedback, the team is really excited about delivering the best reader technology possible and we simply can not do that without this information.

    Sincerely,


    Tim Walker
    Director Online Applications, NewsGator

  1. No trackbacks yet.
Comments are closed.
%d bloggers like this: