It won’t surprise you that one of our key efforts is reducing the workload that the platform puts on your and our machines. The introduction of OpenSocial applications increased the challenge – the applications are hosted on different machines (with their own performance issues), and we integrated them via iFrames, on the front page, on the profile page and in what we call the canvas view.

So, at the moment, you might have several iFrames on your start page. An elegant solution, except for the heavy load they put on your browser – the extreme case, Internet Explorer, requires up to 8 Megabyte of RAM for each rendered iFrame. Furthermore, as the front and profile page often extends vertically way beyond the viewport. But still we have to render the content in iFrames you might not even see.

Wait. Do we have to do that?

The answer is obviously no. This was one of the things that seriously bugged me, and I really wanted to come up with a solution. So, in the weekly four hours that each developer has for his own independent (of course: XING-related) research, I tried to develop a mechanism that:

(1)    Detects whether an application is in the viewport

(2)    Only renders and loads the iFrame if an empty place-holding element is visible

(3)    Performs the check (1) regularly to detect whether rendering is necessary now

My first solution was to initially render the iFrame and only set its “src” attribute when the element is visible.
Well, that caused problems in a particular browser – hint: Youtube will soon be phasing out support for it – who throws a mixed content warning on SSL encrypted pages if the “src” attribute is empty, “about:blank” or simply missing.
Besides that the iFrame is the most expensive html tag across all browsers in terms of rendering speed.

Therefore I decided to initially put an empty html element (eg. <div>) into the page, which gets replaced by the application iFrame as soon as it appears in the user’s viewport.

The last step was not that high on the challenge scale again:  The script checks whether the iFrame is visible every 200ms, and also on resizing the window and scrolling within it. Easy stuff.

The really yummy part: Not only do our customers and we profit enormously from this – we reduced the OpenSocial-induced traffic by 50%, but also for coders using the JavaScript framework Prototype. We’ve released the function as a plugin for Prototype on GitHub for you to download and embed in your projects. It adds a custom event, named “within:viewport”, which can be used like this:

loadIframe = function() {
  var placeholder, iframe;
 
  placeholder = this;
  iframe = new Element("iframe", {
    width: 315,
    height: 315,
    src: "http://iframe-url"
  });
  placeholder.replace(iframe);
};
 
// This is where the magic happens...
$("placeholder").observe("within:viewport", loadIframe);

The plugin can also be used for other expensive operations like for instance to load large graphics only when they are visible to the user.

Happy Hacking!


3
Comments
Leave a comment
Dirk on 27.07.2009 at 20:14h CET

Good blog post, and I really appreciate your way of handling these technical things so openly. Wish more companies would do that.

Tobias on 28.07.2009 at 17:29h CET

THX!
@Dirk I totally agree!

Tim Moore on 25.08.2009 at 20:01h CET

Brilliant technique. Thanks for sharing this!

RSS-Feeds RSS feed for comments on this post.

Leave a comment

If you have a Word Press Account, please sign in