Load Facebook SDK synchronously (not async)

By

Facebook Page Tabs and Canvas Applications should load the Facebook JavaScript SDK at top of the page, not asynchronously. This post explains why.

The preferred method for serving Facebook Page Tabs today is via an iframe, rather than the legacy method of Facebook Markup Language (FBML). This is a good thing because it allows developers to use web standards like HTML and JavaScript in their Page Tabs, instead of Facebook proprietary languages like FBML and Facebook JavaScript (FBJS).

Unfortunately, working with iframes introduces several complications, one of which is that iframes do not dynamically resize to fit their content. The default behaviour for Page Tabs (and Canvas Apps) is to show scrollbars around the frame. In-page scrollbars provide a really poor user experience, so developers will usually disable this default and set their iframe to “Auto-resize”. Then once the Facebook JavaScript SDK has loaded, they call the FB.Canvas.setSize or FB.Canvas.setAutoResize methods to update the size of the iframe to fit its contents.

In-page scrollbars showing while the Facebook SDK loads

Facebook recommends that developers load the JavaScript SDK asynchronously. For most scripts that is a good idea. It is considered a best practice in web development to load scripts asynchronously so that they don’t block other, more important elements such as text content from loading first. However, I would argue that the Facebook JavaScript SDK should be loaded synchronously, at the top of the body element in your page.

If you load the Facebook SDK asynchronously, users will see in-page scrollbars until the SDK has loaded and FB.Canvas.setSize has been called. For a recent application we developed, in-page scrollbars weren’t being removed until 400 milliseconds after the page started loading. Users were seeing some real ugliness for potentially half a second. The small performance benefit we gain by asynchronously loading the Facebook SDK is not worth the pain of having your eyes gouged out by the flash of an in-page scroll bar.

Our tests for this particular application revealed that loading the Facebook SDK at the top of the page only delayed the presentation of the page by 160ms, even without a primed cache. We are talking about loading the Facebook SDK in a Facebook Page Tab, so in reality, it is very likely that the SDK will already be cached by another application. In that scenario, loading the SDK up front only delayed the page display by 116ms.

It is true that by using this approach we are delaying the loading of content and showing our users a blank page for a tenth of a second. However I think that is a worthwhile tradeoff for not having to see an in-page scrollbar while the SDK loads.

Following are the results from our tests. Tests were run 10 times in Firefox 4, profiled with Firebug, and averaged.

Loading the Facebook SDK asynchronously
Facebook SDK loaded¹: 397ms
Facebook SDK initialised²: 410ms
Document ready³: 204ms

Loading the Facebook SDK synchronously just after the opening body tag
Facebook SDK loaded⁴: 105ms
Facebook SDK initialised²: 116ms
Document ready³: 249ms

Loading the Facebook SDK asynchronously (without caching)
Facebook SDK loaded¹: 459ms
Facebook SDK initialised²: 473ms
Document ready³: 218ms

Loading the Facebook SDK synchronously just after the opening body tag (without caching)
Facebook SDK loaded⁴: 150ms
Facebook SDK initialised²: 160ms
Document ready³: 346ms

¹ Time until window.fbAsyncInit is called by the Facebook SDK.
² Time until FB.Canvas.setSize and FB.init have run.
³ Time until jQuery document ready event.
⁴ Time until Facebook SDK has loaded from <script> element.

This entry was tagged with Facebook, Javascript. Bookmark the permalink.

Comments

  1. Thanks for the tip!

    Some pieces of information I feel are missing from this post:

    1. What is your setting in the Developer App for "Canvas Width"
    2. What is your setting in the Developer App for "Canvas Height"
    3. Where in your document do you first call FB.Canvas.setAutoResize
    4. How things are different between "Facebook Canvas" and "Facebook Page Tab"

    Recently I've been working a lot with "Facebook Page Tab" applications. It seems "Canvas Width" and "Canvas Height" settings have no effect on "Page Tab" applications (they have fixed width:520px; height:800px;).

    I've run some basic tests and from what I can tell the best structure is the following:

    ==============

    BODY
    DIV#fb-root
    SCRIPT src=//connect.facebook.net/en_US/all.js

    ... your HTML markup

    SCRIPT
    FB.Canvas.setAutoGrow();
    /SCRIPT

    ... your other JS follows after this

    /BODY

    ==============

    Basically load the JS SDK syncronously after BODY, then have your HTML markup, then an inline script to call FB.Canvas.setAutoGrow(); followed by your other scripts before the closing BODY tag.

    Would love to hear your thoughts.

    p.s. I'm really loving not see scrollbars ^_^

Leave a Reply