Monday, March 1st, 2010

New performance case studies… starting with the Digg widget

Category: Performance

<p>Would we all like Steve to sit down with us on our project and do a performance case study? Well, we may not get that, but we are getting to at least sit in on others.

Steve has kicked off his long awaited series that runs performance case studies on third party content. I have been talking to Steve about this for a couple of years, so it is great to see it. It is a sensitive topic as you never want to show up a team when you are just trying to help and educate.

First on the block? The Digg widget.

diggwidgetstats

Steve goes into detail and finds a lot of short comings. You could probably guess some of the bad actors. Mr. document.write() appears for example. We get the problems, and proposed solutions to the issue. Steve also tries to note what a user of third party content can do regardless of if the third party guys fix their issues (put in iframe!).

Here are the most important performance issues along with recommended solutions.

  1. 9 HTTP requests, 52 kB transferred over the wire, and 107 kB of JavaScript (uncompressed) is a lot of content for a single widget.

    Recommendations:

    • Concatenate these three scripts: JS_Libraries, widgetjsvars, and omnidiggthis. (eliminates 2 HTTP requests)
    • Run Page Speed’s “Defer loading JavaScript” feature and see how much of the JavaScript is not used. If it’s sizable, delete it. (This feature is currently broken in the latest version of Page Speed, but a fix is imminent.) (eliminates ?? kB)
    • Optimize the images – widget-logo.png and get-widget.png can both be reduced by ~3 kB. (eliminates ~6 kB)
    • Sprite widget-logo.png and shade-com.png. (eliminates 1 HTTP request)
  2. The widget’s scripts block the main page’s content from downloading. Looking at the waterfall chart, the main page includes the image “digg-waterfall.png” (row 10). Notice how this image doesn’t start downloading until after all the scripts for the Digg widget are received.
    Recommendations:

    • Instead of loading the scripts using document.write, load them without blocking other downloads. The scripts are already suffering from race condition behavior, as evidenced by this comment from widgetjsvars:
      1: if (!digg || !digg.$) setTimeout(function() { diggwb(obj); }, 200); //hack for IE not loading scripts that are included via document.write until it decides too

    So it probably isn’t too much work to avoid race conditions when making all the scripts load asynchronously.

  3. The widget’s stylesheet blocks the main page from rendering in IE.

    Recommendations:

    • Instead of loading the stylesheet using document.write, load it via JavaScript as described in 5d dynamic stylesheets.
  4. Four of the resources aren’t cached long enough.
    Recommendations:

    • Two scripts aren’t cacheable because they have an expiration date in the past. widgetjs is part of the snippet, so it can’t have a long expiration date, but something like an hour or a day would be better than a date in the past. widgetjsvars could have a far future expiration date since its URL is specified in widgetjs.
    • The three images are only cacheable for a day. They should have a far future expires header since the image filename can be change if it’s modified.
  5. There are approximately 30 inefficient CSS selectors. Because this stylesheet is part of the main page, the selectors will cause the overall page to render more slowly when these selectors are applied to the elements in the main page.
    Recommendations:

  6. Four of the resources have ETags which reduces their cacheability.

    Recommendations:

    • Configure the ETags for widget.css, widget-logo.png, get-widget.png, and shade-com.png.

This is just the first example. What else would you like to see Steve tackle?

Related Content:

Posted by Dion Almaer at 6:53 am
6 Comments

++++-
4.1 rating from 34 votes

6 Comments »

Comments feed TrackBack URI

Please run performance tests on the Facebook line of widgets. I’m seeing 5 and 6 second response times from individual images on the Facebook fan box widget.

Comment by cnharris — March 2, 2010

Great! Now continuing with Facebook Sharer!

Comment by stoimen — March 2, 2010

In answer to number 3 – using javascript to write the styles to the page.

I suppose you could use javascript to write everything, but that doesn’t particularly make the site easier to maintain, and it requires dependency on javascript for the design. Unless you want your site looking like text and sacrificing the design x-platform I would suggest against this.

Comment by inspiraller — March 2, 2010

inspiraller, i think you’re missing that they already use javascript (document.write is a javascript function).

Comment by Jaaap — March 2, 2010

Ah yes, I see the point now. Since the application requires javascript to run anyway, then it appends the styles using javascript, otherwise it doesn’t show the application at all.

Comment by inspiraller — March 3, 2010

Another cool widget that also uses javascript is Niuzer widget. With this one you can get a live news feed on you website. It is simple to use and you can make look exactly like your site. You can give it a try here: http://www.niuzer.com/widget.html

Comment by Ghita — February 3, 2011

Leave a comment

You must be logged in to post a comment.