During the holiday season, which normally accounts for 20-40% of total sales annually, it's critical for e-retailers to provide their users with a smooth, responsive shopping experience. Recent research has shown that 40% of online shoppers will move to a competitor’s site if yours doesn't load in 3 seconds or less. In fact, about $3 billion in revenue is lost annually due to customers abandoning shopping carts on slow web sites. With that in mind, here are Fastly’s top 5 tips for optimizing and speeding up your site for the holidays.
A lot of content management systems and eCommerce solutions sidestep the problem of cache invalidation by simply forcing a no-cache policy through a combination of HTTP headers. These headers can either be removed in your application, or modified or deleted in Fastly by creating a new cache header.
There can be good reasons for caching-related HTTP headers, especially if you want to make sure that browsers are always showing the latest version of your page. When dealing with time-dependent sales or a rapidly changing inventory, this type of control is invaluable.
Fortunately, Fastly makes it easy to maximize your expiry times. You can make sure that Fastly caches your content by either forcing behavior in your configuration or by sending Surrogate-Control response headers from your application. Meanwhile, by sending no-cache headers to browsers you'll ensure that your users see the latest version of your pages whenever you send a purge. You can then crank up your expiry times safe in the knowledge that if your content does change, you'll still be able to get it in front of your customers immediately.
Obviously you could purge all of your content whenever you make a change, but this nuclear option may create load spikes on your origin servers. A more civilized option is to purge individual URLs one at a time. Keeping track of every URL an item appears on, however, is a pain. Additionally, issuing multiple purges on every update creates a performance bottleneck.Fastly has solved these problems by allowing you to group content together by Surrogate Key and then purge all objects in the same group at the same time. This is particularly useful if an item has, say, multiple images, or if you want to update every item in a particular category. For example, you can purge all items related to a specific sale or seasonal promotion at the same time.
No matter how much you reduce the number of purges, each cache miss can send a stampeding herd of users back to your application. Fastly makes sure that multiple requests for the same object on the same cache server are coalesced into one in order to reduce the load on your origin server as much as possible. However, we have multiple datacenters around the world and after a purge, all of them will be requesting pages from you.
The solution is to set up shielding, which nominates a Fastly POP to act as a gateway to the rest of the network. Instead of hitting your application on a cache miss, we’ll first check with your shield server when requesting content. If that server has the content, then the requested content will be returned. If the shield doesn’t have the content, then it will make the request (instead of all of our datacenter servers making the request), store the result, and then return it, saving your servers from any subsequent requests.
By their very nature, eCommerce sites have personalized content for logged-in customers, even if it’s limited to the shopping cart. While you can’t cache the logged-in pages, you can isolate the personalized, logged-in content. This can be achieved by using AJAX calls to insert uncached dynamic content into the page from the browser, then having Fastly caches insert the dynamic content at response time.
In the instance that the worst happens and you have an outage, there are ways to limit the extent of the damage.
If you have multiple datacenters, Fastly can be configured to switch to your secondary as soon as we notice your primary is down, even if your secondary center is merely a static copy of your site. Even without multiple datacenters, you can still configure Fastly to display any pages we happen to have in the cache. Although the content may be stale, slightly out-of-date content is better than displaying no content at all. If all else fails, Fastly can be configured to show your users an apology page directly from our edge servers rather than an obscure internal error from your app.
These is just the tip of the iceberg, but these tips will help ensure that you can handle traffic spikes and maintain speed and performance during the holiday rush.