Slow Performance: Sharethis/Addthis

Error message

The spam filter installed on this site is currently unavailable. Per site policy, we are unable to accept new submissions until that problem is resolved. Please try resubmitting the form in a couple of minutes.

In between sessions at Drupalcon DC I was asked if Trellon generally implements bookmarking tools such as, sharethis or addthis, for clients? I started to answer that we have no preference but stopped myself when I remembered a client situation with Sharethis. When the Sharethis component was installed it made page load times slow and it had some script caching issues. In this situation it resulted in page loads of over 20 secs and obviously lead to us having to seek an alternative solution. We then stopped using Sharethis on the clients site for a better option: the service_links module. After we configured the service_links module the performance was dramatically improved. This experience of sharing Drupal knowledge is an example of why Drupalcon's are so important.

The Sharethis/Addthis performance problem is it appends to every node and the caching strategies used by both providers is weak to say the least. Both are currently attempting to improve the leave of performance in this area so over time these issues should decline. The impact of these slow loading scripts is that the user is given feedback that the page is still loading and it reduces their web experience. Also, in certain cases it can result in additional jquery effects firing in a delayed manner. In the big picture Sharethis/Addthis and the service_links module seem to do the same thing but the main difference is service_links doesn't call out to a remote service. The service_links module simply generates links via the traditional hook_links, exposed by Drupal core. This means that all work is carried out on the webserver and all the benefits of Drupal's page cache can be realised for all anonymous users.

The down side of the service_links module is on the interface ... it doesn't do fancy ajax stuff. However, the key here is when you stay local you know you are going to get better performance, remote services may provide certain bells and whistles but you become beholden to potentially external factors. So only go remote if the client needs these features otherwise stay local.