Blog Post

The Widespread Effects of Facebook’s Latest Outage

How Facebook's outage influenced user experience on many other websites that use Facebook API for their login tools or widgets for commenting systems.

Every day, hundreds of millions of users access Facebook, either through the site’s homepage, or through widgets and APIs on other sites. So when the social media giant experiences an outage in their service, the ripple effects spread far and wide.

That’s precisely what happened for roughly half an hour on Thursday, June 19 from 3:50 to 4:21 am EDT. This has been reported as their longest outage in four years, but as we uncovered back in 2012, there were two instances of even longer ones (each over two hours) within a 12-hour timeframe.

facebook.com Outage
facebook down

Many sites experience outages such as this, which usually only affect users who are trying to log in directly from their homepage. Yet because the Facebook footprint is so huge, it had a drastic effect on many other sites which use Facebook  APIs for their login tools or widgets for commenting systems, sharing platforms, etc. Thus, many of these sites’ user experience was impacted.

website impact of facebook.com Outage

As the chart shows, during the times when Facebook was down, the document complete took significantly longer for several sites, often over 30 seconds (represented by the red dots at the top).

If a site does not use an asynchronous tag of Facebook, the document complete on the page will be delayed until the Facebook request times out. And if the page was not coded correctly, certain interactions or content might not have worked properly, with the user being impacted by the dreaded pinwheel (or spinning hourglass).

For example, popular music streaming site Spotify, which uses a Facebook API to allow users to log in and share their playlists, saw a variety of performance issues. Obviously no one could use the FB Login API, but the site’s background images did not load as well.

spotify

Of course, Spotify was not the only affected site, because the practice of implementing asynchronous coding for third-party tags is not very widespread despite years of web performance experts advocating for its usage. Generally, adoption of such a policy requires that the vendor tags support it (which Facebook does offer), but also implementation on the part of the sites using it.

The lesson, therefore, is a poignant one: When utilizing any third-party tags, particularly ones that have such a big effect on your end users interaction with your site, it’s imperative that you make sure the code is asynchronous with your own to prevent it from affecting your entire site’s performance.

All website developers need to take note of this. In order to avoid similar problems in the future, ensuring that you’re using the proper third-party tags is essential.

News & Trends
Web Experience
API
DevOps
End User Services
Media and Entertainment

You might also like

Blog post

Five Reasons to Use Catchpoint for Measuring Core Web Vitals

Blog post

Work From Anywhere - How Much Bandwidth Do You Need?

Blog post

SRE Report 2021: The Highlights

Blog post

iSeatz – Resolving Performance Issues Faster with Catchpoint