I’m at Velocity China in Beijing as I write this article for the Performance Calendar. Since this is my second time to Beijing I was better prepared for the challenges of being behind the Great Firewall. I knew I couldn’t access popular US websites like Google, Facebook, and Twitter, but as I did my typical surfing I was surprised at how many other websites seemed to be blocked.

Business Insider

It didn’t take me long to realize the problem was frontend SPOF – when a frontend resource (script, stylesheet, or font file) causes a page to be unusable. Some pages were completely blank, such as Business Insider:

figure 1: The dreaded “blank white screen” due to a blocking Twitter script.

Firebug’s Net Panel shows that anywhere.js is taking a long time to download because it’s coming from platform.twitter.com – which is blocked by the firewall. Knowing that scripts block rendering of all subsequent DOM elements, we form the hypothesis that anywhere.js is being loaded in blocking mode in the HEAD. Looking at the HTML source we see that’s exactly what is happening:

<!-- Twitter Anywhere -->
<script src="https://platform.twitter.com/anywhere.js?id=ZV0...&v=1" 
<!-- / Twitter Anywhere -->

If anywhere.js had been loaded asynchronously this wouldn’t happen. Instead, since anywhere.js is loaded the old way with <SCRIPT SRC=..., it blocks all the DOM elements that follow which in this case is the entire BODY of the page. If we wait long enough the request for anywhere.js times out and the page begins to render. How long does it take for the request to timeout? Looking at the “after” screenshot of Business Insider we see it takes 1 minute and 15 seconds for the request to timeout. That’s 1 minute and 15 seconds that the user is left staring at a blank white screen waiting for the Twitter script!

figure 2: Business Insider finally renders after 1 minute 15 seconds.


CNET has a slightly different experience; the navigation header is displayed but the rest of the page is blocked from rendering:

figure 3: CNET rendering is blocked by ads from eyewonder.com.

Looking in Firebug we see that wrapper.js from cdn.eyewonder.com is “pending” – this must be another domain that’s blocked by the firewall. Based on where the rendering stops our guess is that the wrapper.js SCRIPT tag is immediately after the navigation header and is loaded in blocking mode thus preventing the rest of the page from rendering. The HTML confirms that this is indeed what’s happening:

<script src="http://cdn.eyewonder.com/100125/771933/1592365/wrapper.js"
<div id="rb_wrap">
<div id="rb_content"> <div id="contentMain">

O’Reilly Radar

Everyday I visit O’Reilly Radar to read Nat Torkington’s Four Short Links. Normally Nat’s is one of many stories on the Radar front page, but going there from Beijing shows a page with only one story:

figure 4: O’Reilly Radar rendering is blocked by Twitter widget.

At the bottom of this first story there’s supposed to be a Tweet button. This button is added by the widgets.js script fetched from platform.twitter.com which is blocked by the Great Firewall. This wouldn’t be an issue if widgets.js was fetched asynchronously, but sadly a peek at the HTML shows that’s not the case:

<a href="...">Comment</a>
<span class="social-counters">
<span class="retweet">
<a href="http://twitter.com/share" class="twitter-share-button" 
   data-text="Four short links: 6 December 2011" data-via="radar" 
<script src="http://platform.twitter.com/widgets.js" 

The cause of frontend SPOF

One possible takeaway from these examples might be that frontend SPOF is specific to Twitter and eyewonder and a few other 3rd party widgets. Sadly, frontend SPOF can be caused by any 3rd party widget, and even from the main website’s own scripts, stylesheets, or font files.

Another possible takeaway from these examples might be to avoid 3rd party widgets that are blocked by the Great Firewall. But the Great Firewall isn’t the only cause of frontend SPOF – it just makes it easier to reproduce. Any script, stylesheet, or font file that takes a long time to return has the potential to cause frontend SPOF. This typically happens when there’s an outage or some other type of failure, such as an overloaded server where the HTTP request languishes in the server’s queue for so long the browser times out.

The true cause of frontend SPOF is loading a script, stylesheet, or font file in a blocking manner. The table in my frontend SPOF blog post shows when this happens. It’s really the website owner who controls whether or not their site is vulnerable to frontend SPOF. So what’s a website owner to do?

Avoiding frontend SPOF

The best way to avoid frontend SPOF is to load scripts asynchronously. Many popular 3rd party widgets do this by default, such as Google Analytics, Facebook, and Meebo. Twitter also has an async snippet for the Tweet button that O’Reilly Radar should use. If the widgets you use don’t offer an async version you can try Stoyan’s Social button BFFs async pattern.

Another solution is to wrap your widgets in an iframe. This isn’t always possible, but in two of the examples above the widget is eventually served in an iframe. Putting them in an iframe from the start would have avoided the frontend SPOF problems.

For the sake of brevity I’ve focused on solutions for scripts. Solutions for font files can be found in my @font-face and performance blog post. I’m not aware of much research on loading stylesheets asynchronously. Causing too many reflows and FOUC are concerns that need to be addressed.

Call to action

Business Insider, CNET, and O’Reilly Radar all have visitors from China, and yet the way their pages are constructed delivers a bad user experience where most if not all of the page is blocked for more than a minute. This isn’t a P2 frontend JavaScript issue. This is an outage. If the backend servers for these websites took 1 minute to send back a response, you can bet the DevOps teams at Business Insider, CNET, and O’Reilly wouldn’t sleep until the problem was fixed. So why is there so little concern about frontend SPOF?

Frontend SPOF doesn’t get much attention – it definitely doesn’t get the attention it deserves given how easily it can bring down a website. One reason is it’s hard to diagnose. There are a lot of monitors that will start going off if a server response time exceeds 60 seconds. And since all that activity is on the backend it’s easier to isolate the cause. Is it that pagers don’t go off when clientside page load times exceed 60 seconds? That’s hard to believe, but perhaps that’s the case.

Perhaps it’s the way page load times are tracked. If you’re looking at worldwide medians, or even averages, and China isn’t a major audience your page load time stats might not exceed alert levels when frontend SPOF happens. Or maybe page load times are mostly tracked using synthetic testing, and those user agents aren’t subjected to real world issues like the Great Firewall.

One thing website owners can do is ignore frontend SPOF until it’s triggered by some future outage. A quick calculation shows this is a scary choice. If a 3rd party widget has a 99.99% uptime and a website has five widgets that aren’t async, the probability of frontend SPOF is 0.05%. If we drop uptime to 99.9% the probability of frontend SPOF climbs to 0.5%. Five widgets might be high, but remember that “third party widget” includes ads and metrics. Also, the website’s own resources can cause frontend SPOF which brings the number even higher. The average website today contains 14 scripts any of which could cause frontend SPOF if they’re not loaded async.

Frontend SPOF is a real problem that needs more attention. Website owners should use async snippets and patterns, monitor real user page load times, and look beyond averages to 95th percentiles and standard deviations. Doing these things will mitigate the risk of subjecting users to the dreaded blank white page. A chain is only as strong as its weakest link. What’s your website’s weakest link? There’s a lot of focus on backend resiliency. I’ll wager your weakest link is on the frontend.


Steve works at Google on web performance and open source initiatives. He previously served as Chief Performance Yahoo!. Steve is the author of High Performance Web Sites and Even Faster Web Sites. He is the creator of YSlow, one of the top 25 Firefox add-ons. He's created many other performance tools and services including the HTTP Archive, Cuzillion, Jdrop, ControlJS, and Browserscope. He serves as co-chair of Velocity, the web performance and operations conference from O'Reilly, and is co-founder of the Firebug Working Group. He taught CS193H: High Performance Web Sites at Stanford University.

13 Responses to “Frontend SPOF in Beijing”

  1. Sripathi Krishnan

    Twitter’s anywhere.js recently came up under discussion on StackOverflow. See this thread – http://stackoverflow.com/questions/8276471/alternatives-to-twitter-anywhere-api/8389383

    Summary : Although twitter loads follow up resources asynchronously, the bootstrap js file is loaded synchronously and is a front end spoc. Also, per twitter, loading the bootstrap file asynchronously is NOT supported at the moment.

    Here is hoping Twitter fixes this issue soon https://dev.twitter.com/discussions/673

  2. Lennie

    Thank you Steve for pointing this out.

    Obviously anyone with some knowledge about the blocking nature of JavaScript and some common sense would have understood this if they had spend some time thinking ahead.

    But who does that ? ;-)

  3. Frontend SPOF in Beijing | High Performance Web Sites

    [...] past December I contributed an article called Frontend SPOF in Beijing to PerfPlanet’s Performance Calendar. I hope that everyone who reads my blog also read the [...]

  4. prevod v angleščino

    naturally like your web-site however you have to check the spelling on several of your posts. Several of them are rife with spelling problems and I to find it very bothersome to inform the reality nevertheless I’ll certainly come again again.

  5. clear current page UX | High Performance Web Sites

    [...] frontend SPOF. I’ve written (and spoken) extensively about how loading scripts synchronously can create a single point of failure in your web page. This new [...]

  6. visit this web page link

    He’s Getting Married. If those locations are not in your vicinity and you still insist on getting a Chanel handbag or purse at a discount, which can be accomplished with a legitimate purchase on e – Bay, then here are a few things you will need to be on the lookout for. She was ‘discovered’ when Condé Nast saved her from being run over in the street and offered her a job modeling for Vogue magazine.

    Review my web page: visit this web page link

  7. Speed geek’s guide to Facebook buttons / Stoyan's phpied.com

    [...] the JS SDK, it's absolutely mandatory that you make sure it's either loaded asynchronously to avoid SPOF, or even better – in an iframe to avoid blocking [...]

  8. bookkeeping

    Hey, its wonderful to be here. Really love to write on accounting topics and I happen
    to be bookkeeper in Talladale. Excellent blog on a field I’m just very experienced with.

    my weblog; bookkeeping

  9. webpage

    I love looking through a post that will make men and women think.
    Also, thank you for allowing for me to comment!

    Feel free to surf to my webpage: webpage

  10. Speed wealth system how to Profit In 7 days

    You are so interesting! I do not suppose I’ve truly read something like this before.
    So great to find someone with some original thoughts
    on this topic. Really.. thank you for starting this up.
    This site is something that is required on the web, someone with a bit of originality!

    my web-site – Speed wealth system how to Profit In 7 days

  11. Sablon Kaos Lamongan

    artikel yang menarik.
    info yang menambah pengetahuan

  12. reputation management Uk

    They may let you put ads of their forums. The offer might be somewhat like this:
    Be Cautious Of This Fraud (keyword).

    For a better informative review please check out this blog: reputation management Uk

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
And here's a tool to convert HTML entities