AddThis Can Cause Your Site To Not Load

Over the last few days, I have run across quite a few websites that seem to never finish loading. After waiting for 20 seconds or more, I give up, realizing that whatever content was on the site wasn’t worth it anymore for me to stare at a blank white browser until it loaded however much longer. Unfortunately for those websites, they are losing traffic that they will never get back.

There was one consistent aspect of each of these websites, though. Whoever developed the sites took a bit of a shortcut when it came to adding social sharing buttons to the site. Instead of adding only the social media support the site was active on and implementing this support locally on the site, they used a third-party social sharing provider, AddThis. AddThis does make an attractive set of sharing icons that seem to work well when they are loaded on the site.

However, when these sites implemented the code, the part they forgot to handle was the case when AddThis.com was unresponsive, which is what caused the issues I was seeing. When the web browser makes a request for a standard JavaScript file, all browser rendering and activity is stopped until the JavaScript file is returned. AddThis was responding somewhat in that it was not immediately returning an error, which would have allowed the website in question to continue loading, instead it was responding as if it were going to deliver the JavaScript file eventually, but never did.

When using third-party JavaScript to handle some aspect of your site, always make sure to use the async attribute on the <script /> tag where you include the JavaScript. This tag will ensure that the rendering of the page is not potentially blocked by a slow-loading resource, and will help visitors get access to your site more quickly in many scenarios.

Tags:

Related Posts

Jun 11, 2014
2 minutes

Defensive Development Failure

In the past, I have argued that devensive development is a useful tool to ensure unexpected exceptions are not introduced into a piece of software as well as ensuring that the error conditions are handled in an appropriate manner. Unfortunately, if defensive development is implemented poorly, it achieves none of its goals and can cause errors and exceptions to occur. One example that I found while reviewing some code recently is below:

#javascript #design-patterns
Read More
Mar 28, 2014
2 minutes

Launching a Redesign of a Website

Over the last few months, I have been working on a major redesign of an existing Magento website. One of the major goals of the redesign was to take a legacy desktop-only website and upgrade it to take full advantage of Responsive Web Design so that customers could equally utilize mobile and desktop devices to browse and purchase products.

For a site that had seen only minor updates over the last 5 years, this redesign represented a major change visually and navigationally from the previous site. Based on the history of the site, the development team was optimistic that the redesign would be well-received, but were suprised by a few things that came up in the feedback we saw.

#magento #responsive-web-design
Read More
Jul 3, 2014
2 minutes

== and === in JavaScript and HTML Input Elements

If you read any current information about best practices in JavaScript, you will typically find the following advice somewhere in the list of things to do.

Always use === and !== while avoiding == and !=

While I will never argue against this advice, there are a few things that a developer shoule realize when using === and !== instead of == and !=.

  1. === and !== first do a check of the data type of the two objects you are comparing. JavaScript never forces you to explicitly define the datatype for an object you are creating as it will automatically assign one based on the contents of the object and how it was created.
  2. The output of all of the Math functions produce integers or floats as the datatypes for the resultant numbers. For example, Math.floor(10.39438) will produce 10.
  3. When retrieving the value of any select or input or textarea is always return as a string. This means that even though the value of the string may be a perfectly good number, it will never match a number data type. For example "10" is not equal to 10 when using the ===.

You should always use === and !== instead of == and !=, but you should make sure you understand the datatypes you are dealing with so that your comparison works as expected without any surprises at runtime.

#jquery #responsive-web-design #javascript
Read More