IT and Business Insights for SMB Solution Providers

How to Boost Speed on Slow Websites

Whether you are a site host, developer, or post-launch consultant, here are the underused ways to make your customers' sites respond quickly. By Ellen Muraskin By ChannelPro

Whether you are a site host, developer, or post-launch consultant, here are the underused ways to make your customers’ sites respond quickly.

By Ellen Muraskin

Do your customers ever complain about slow response times on their websites? Like long hold times on phone queues, slow-loading sites are business killers. They invite your clients’ prospects to go across the virtual street.

“No technical device and no amount of broadband are going to make people patient,” says Thomas Powell, founder and president of Pint Inc., a corporate site-development and strategy company in San Diego. Case in point: At O’Reilly’s Velocity conference in 2009, Hotmail reported that a six-second delay in load time caused a drop of 40 million ad impressions per month. In annual revenue terms, that’s a loss of $6 million. With all the attention being paid to a site’s look and feel or its search ranking, $6 million is a good reason not to overlook the element of speed.

There is plenty to find on this front. Widely accepted best coding practices, services, and products are available to help developers produce and run speedy sites. Powell, who also lectures on computer science and engineering at the University of California, San Diego, notes that it’s rarely CPU power that constrains Web application performance. The drag more often lies in database and disk I/O between browser and Web server. The main goal of site acceleration, then, is to minimize trips to that server, database, image, or other files, and lessen the payload of each trip.

“The best way to speed up pages is to think of being green: Conserve, reduce, and reuse,” says Zaki Usman, marketing lead/principal at Web marketing firm ShoutEx Inc., in Ottawa, Ontario. That means don’t send the same data over and over. Remove objects, reduce payload, and use cache control so the browser isn’t forced to keep fetching the same content for multiple pages, or fetch it the next time the visitor stops in.

And don’t load up large images just to resize them on the browser as thumbnails. “That’s a total waste of bandwidth as well as browser-side computing,” says Usman. Save raster images as jpegs to reduce file sizes. Even better, bunch many compressed images together into a “CSS sprite,” to reduce their retrieval from many to one. Precompress or “minify” html and CSS files on the server side by turning on Gzip. Similarly, bundle multiple JavaScript files and CSS style sheets together.

“It’s not so much the bytes you send as the number of requests,” says Powell. A site that requires 20 requests will run much slower than one that requests five, even if the five contain more bytes, simply because of the latency of round-trip requests.

It’s easy to prove this to yourself by testing your site on, which yields a wealth of instant data and waterfall charts of the website’s loading times and requests. Try this before and after Gzip compression or image aggregation and you’ll see the seconds saved.

Usman cautions developers to make sure all fetched files are present: “404 errors are server-side expensive as well as an eyesore,” he says, because the server expends time fruitlessly looking.

Reuse code by referencing JavaScript and CSS as external files in your pages, instead of having duplicate content loaded in-line for each page. “Storing them externally allows for browser caching,” says Usman. “And don’t forget server-side caching,” he says, a practice made easy through the use of the big three content management services (CMS) for building dynamic sites—Drupal, Joomla, or Wordpress. All have plug-ins for caching.

Another speeding technique is progressive loading, in which content is rendered as it is downloaded by the browser, instead of waiting for the contents of an entire page to start the display. To do this, Usman recommends placing style sheets at the top, inside the document head, so they can direct the browser as it loads the rest of the pages.

Powell divides acceleration products into software, appliance, and proxy-based categories and combinations thereof. His own company, Port80 Software Inc., in San Diego, makes a software acceleration tool for the Microsoft IIS Web server, httpZip.

On the appliance side, there’s EQ/OS 10 from San Jose, Calif.-based CoyotePoint Systems Inc., a smart load balancer that distributes traffic based on the capacity of back-end servers and entered rules, offloads SSL encryption, and performs compression. Similarly, BIG-IP WebAccelerator from Seattle-based F5 Networks Inc., NetScaler ADC from Citrix Systems Inc., based in Fort Lauderdale, Fla., and others can speed up traffic by enabling a single server to do a lot more. They’re expensive, though. Site Optimizer from Strangeloop Networks, based in Vancouver, British Columbia, is offered as an appliance or a cloud service.

CloudFlare, by San Francisco-based CloudFlare Inc., is a solution that proxies all of a website’s contents, meaning that all traffic to and from the site is routed via the company’s servers, which perform all the compression, “minification,” and caching for you. What’s more, CloudFlare pushes site content out of its 12-node CDN (content distribution network), fetching the static parts of pages from points much closer to users, thereby cutting page load time. Its base offering is also free.

Michael Kaiser-Nyman, CEO of San Francisco-based Impact Dialing Inc., a cloud-based predictive dialing solution for outbound call centers, says he wishes he’d known about CloudFlare before spending so much time optimizing his site himself. For $20 a month, CloudFlare Pro, the company’s midrange offering, automatically preloads resources to visitors based on their behavior during previous visits.

And while Kaiser-Nyman says CloudFlare provides security features and DOS attack prevention, Powell notes a downside: A third party is privy to your data. Also, since CloudFlare is a shared resource, your fellow proxied companies’ enemies and troubles become your own; one successful DOS attack or network outage sinks you all. Should that happen, though, says Kaiser-Nyman, CloudFlare “disconnects itself from the proxy routing and your own servers take over.”

Cambridge, Mass.-based Akamai Technologies Inc.’s Web performance solutions are best known but no longer lonely in the CDN field. See Cotendo, from Cotendo Inc., in Sunnyvale, Calif., and products from Level3 Communications Inc., in Broomfield, Colo., among others. They’re usually not cheap, says Powell, but they’re necessary to keep page loading time swift if your users grow in number and geography.

There is one “solution” that absolutely does not work, however. It’s widely believed that adding more Web servers automatically fixes the latency problem in page loading. Wrong, says Powell. The misconception arises from popular confusion between speed and scale.

“Adding a server is like opening another checkout line in the supermarket. It is not speeding up the transaction, however. These are two separate issues,” he says. Before they try to “gear their way out” by adding servers, developers should make sure they have covered the basics of efficient bundling, caching, and compression, as previously discussed.

To properly scale the site, determine how many people a given machine will serve at one time. “In the real world, we understand that capacity is limited,” Powell explains. “We know that to design a store that will handle so many people we need so many square feet of space, so many parking spots, so many checkout lines. But we almost never encounter people who realize that the same constraints apply to websites.”

Your clients’ prospects will realize that soon enough, however, if website response times are maddeningly slower than what’s available across the virtual street. For today’s increasingly impatient customers, there is a need for speed.

ELLEN MURASKIN is a freelance technology writer based in New Jersey.

About the Author