How To Avoid a Facebook Fail: Asynchronous Scripts, Redundancy, and Best Practices

Facebook recently slowed the loading time of hundred of thousands of
websites to a crawl.

The culprit of the performance drop-off? Facebook’s ‘Like’ button.

When websites with the ‘Like’ button embedded tried to load, the ‘Like’
button was slow or unable to load. This caused web pages to lag, hang
and generally load like molasses. The user experience was slow.

But this issue could have been avoided by following a best practice
guideline – loading the script for the ‘Like’ button asynchronously.

(More on the differences between synchronous versus asynchronous
signalling.)

Seeing the ‘Like’ button slowing so many websites hit home here at
Mobify because we’re always thinking about performance.

For years, we’ve been implementing the Mobify script asynchronously
because our customers need world-class performance and reliability.
We’ve also been recommending that they follow best practices and
implement all their scripts asynchronously.

Why?

Because the performance of a website should not depend on a single point
of failure loading resources, like a script.

Performance is directly related to customer experience, satisfaction and
e-commerce revenues. We see it proven every day with a heightened
sensitivity on mobile.

So we thought we’d share some of the steps we’ve taken and our own best
practices on asynchronous scripts, redundancy and performance.

1. Redundant Domain Name System (DNS)

What is it?

The Domain Name System (DNS) translates domain names into IP addresses.

Why does it matter?

Humans like to use domain names like Google.com. Computers like to use
IP addresses like 74.125.224.72.

When you type “google.com” into your browser, a DNS server translates
that request into 74.125.224.72 where Google.com lives.

Try going to 74.125.224.72 in your browser and you’ll see it load
Google, while 74.125.224.72 appears in the URL bar.

Secure and reliable DNS is essential to any successful internet service
– a DNS outage is almost a worst case scenario.

When a DNS outage occurs, browsers can’t look up a DNS address and are
unable to match a URL to an IP address.  The browser will wait and keep
trying for a very long time leading to a terrible user experience.

If your DNS is down, you’re out of business on the Internet.

Best Practice for Redundant DNS

Mobify has DNS’s hosted in 9 different data centres across the world.
The closest of those 9 will respond to a request. If that data centre
takes too long to respond, the next-closest one will respond. Our goal
is to return DNS lookups within 30-50MS globally.

The result is that our customers have 9 different layers of redundancy
to ensure our DNS is fast and reliable.

2) Redundant Edge Nodes

What is it?

Edge nodes are distributed copies of websites built to deliver all the
website resources (images, scripts, videos, text, etc.) very fast.

Why does it matter?

It still matters how far traffic has to travel. The shorter and less
hops it has to do, the better.

We want to be able to serve visitors quickly whether they’re in Japan,
Brasil, New York or London.

We also want to have a lot of these scattered around the world, not only
for speed, but also for multiple layers of redundancy.

Best Practices for Edge Nodes

We have 19 edge locations around the world. Their locations are
reflective of our customers’ traffic with coverage in regions around the
world. We have at least one edge node on every continent except
Antarctica and add new nodes as traffic increases in geographic regions.

The nodes work together to deliver performance. If an edge node ever
takes too long to respond or fails, another node will take over the
request.

This is especially important as performance is tied directly to
financial success, where even 400MS lag – a literal blink of the eye –
affects user behaviour negatively.

3) Backup Content Delivery Network (CDN)

What is it?

A content delivery network (CDN) is a distributed network of servers
that work together to deliver content to users as quickly as possible.

Why does it matter?

A CDN is one more essential piece of the performance puzzle.

When people click on a link on a web page, hit a play button on a video
or choose to zoom in on a product image, they want their request to be
served as fast as possible.

A CDN makes serving these web requests faster and more reliable.

Best Practices for Redundant CDN

Even though it’s rare, it remains possible that an entire primary CDN
goes down and could take your website with it.

The key to manage this risk is to have a backup CDN standing by and
ready to go.

All the information on the backup CDN needs to be identical to the
primary CDN, meaning that it can be called into action in seconds and
fired up by changing DNS records.

Our backup CDN is equivalent to our primary CDN but hosted with a
different company with nodes in different locations.

We monitor our CDN performance constantly and will flip to our backup
CDN if content (that we know should be served by our primary CDN) is
missing, slow or unreliable.

We have a third level of redundancy as a final option: we will pass our
customers’ traffic directly to their desktop site.

Knock on wood, we’ve never had to use this option.

So there you have it, Mobify’s best practices to avoid a Facebook fail
and to ensure your mobile performance is world class.

If you’re happy working with code – JavaScript, CSS and HTML5 – you can
try out our Mobile Cloud platform as described above, right here:

Try Mobify for free