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: