Too Much External Coding Can Slow Your Site

I’m a fan of Shop Rite—literally. Not only have I become a regular shopper since the New Jersey-based grocer has come to my Connecticut neighborhood (it’s had a location near my office for a few years, too), but I “like” Shop Rite on Facebook and I use its Android app.

Shop Rite is doing the right things with its social media – both its Facebook and Twitter channels are used to engage and enlighten followers. Its mobile apps allow users to make their shopping lists portable, and comparison shop from other grocery stores.

But its drive to be as social as possible is hurting its ecommerce channel. The load times for its circular pages are slow because it added a Facebook “like” button to every item. The button appears up to 20 per page, and even though the code is not clogging Shop Rite’s servers, the grocer is pulling way too much data from Facebook.

Worse, you can’t click on the circular items to pull up a product page. This would allow a simple solution for Shop Rite. Not only would individual product pages help Shop Rite in the search engines, but the “like” button would only need to load once.

Script coming in from Facebook is not the only thing that can slow a site down, though it’s evident in this case when you load Shop Rite’s circular pages. Any time you add third-party coding, you have to deal with additional sets out outside servers.

And whether you realize it or not, all the Web 2.0 gizmos and gadgets designed to make your site user-friendly means you could have dozens of outbound coding flowing into your website. If it slows your site down, you could be losing customers.

The speed of your website is important: A survey conducted in September by Gomez, the web performance division of Internet technology provider Compuware, backs that up. According to the study, 32% of consumers will abandon a slow-loading website after five seconds or less of wait time. What’s more, sales conversions rise 74% when page load time improves from eight seconds to two seconds, according to Gomez behavioral data, based on 3 million page views.

Speaking last month at IRWD 2011, Andy Lloyd, general manager of ecommerce products at platform provider NetSuite, and Meir Tsinman, president of TheMedicalSupplyDepot.com, talked about how script from outside vendors slowed the online merchant’s site down, and the steps they took to fix it.

The biggest point Lloyd and Tsinman made: Less is more. If you put so many bells and whistles on your site, and the result is slow-loading pages, the customer is going to abandon.

Tsinman said during his presentation that he didn’t realize how slow his site had become until he went to access TheMedicalSupplyDepot.com from a computer that was not on his server. The banner came up, but there was a significant delay before the rest of the home page loaded. That’s because its home page alone made 80 requests for outbound data from 16 external servers.

“At that point, if I’m a consumer, I’m out,” Tsinman said. “I’m not even going to wait for the entire page to load. That’s why people were bouncing out at the first page.”

Tsinman stripped out a lot of external coding over a six-month period, but kept the coding for 52 different outbound requests. The strange thing was, he needed to get rid of some of the hip new Web 2.0 elements he’d added, like product comparisons, filtering, product reviews and quick view.

“These were all the things everyone was talking about and how important they were for customers,” Tsinman said. “We plan to bring them back if we can find a way to make them faster.”

Once Tsinman recoded TheMedicalSupplyDepot.com, its bounce rate dropped 40%, its conversion rate rose 50%, average page views went up 20% and users spent 50% more time on the site.