Let’s face it, consumers expect your website to load quickly. There have been lots of stats appearing over the past year or so speaking to exactly that (my favorite is the one from Google researchers indicating that users will, over time, abandon a website if it is 250ms slower than the website of your competitor). The problem is that performance improvement for web experiences can be a monster. Where do you start?
First, you must understand how to measure performance.
We do it through a simple equation:
RTT x #RTs
That’s the round-trip-time (RTT) multiplied by the number of round-trips (RTs). If you can reduce either side of the equation, you can mitigate the amount of latency you are adding to the web experience. Consider the following—your return trip is 200ms and it takes 10 round trips to deliver your webpage. That’s adding two seconds of latency. Two seconds! That’s a lot, especially when users don’t want to wait more than five seconds for the entire webpage to load.
So what can you do to improve the results of this equation?
I’ve identified four "prongs" for building a better, faster web experience:
1. Tune the Origin. This first prong is all about making the web origin better. This means your web servers. Update to SSDs. Add more RAM. Improve the network interface card to gigabit speed. But it’s not just about hardware. It’s also about making the web server purpose built. You’d be surprised how many people combine software functionality onto a single box—web server, database server, application controller, and more. Don’t do that. Make your origin just a vanilla web server. Turn off all the functionality that you don’t need. Turn on persistent connections. Implement a cache.
2. Use a CDN. When you deliver your web experience, you are going through all three miles—first, middle, and last. You can control the first mile by increasing the amount of bandwidth to your origin server (as well as the link capacity of your routers and switches). But you can’t control the middle or last mile. The CDN enables you to offload delivery so that 1) you don’t have to deliver much through the first mile anymore and 2) you can "hand-off" delivery from the middle mile to the last mile much closer to the end user by storing content at the edge of the network in cache. Of course, dynamic content will always get served by your origin but leveraging a longer TTL (time-to-live) on your content in cache means that only the dynamic portion of your web pages is getting served by your origin and not all that extra stuff. By doing so, you can radically reduce the RTT component of that equation. And because the CDN utilizes persistent connections, you can actually reduce the number of RTs as well. In essence, the CDN enables a "short cut" for your web experience to the user by bypassing the congestion found on the public Internet. But before you run out and sign-up with a CDN, you should also consider where you are storing your static objects. What happens when there is a cache miss? The CDN has to take the user request all the way back to origin. If that’s happening several thousand times a day across multiple geographic regions, it can undermine the latency savings you are getting by using a CDN. You need to look for a CDN that can store objects as close to the end user as possible. In this scenario, when there’s a cache miss, it’s almost like a cache hit because the objects are stored at the edge as well.
3. Optimize the front-end. Part of the issue with building a better, faster web experience isn’t just improving RTT and reducing the number of RTs. It’s also about user perception. It’s about time-to-paint (how quickly the webpage starts to load so that the user can interact with something) and time-to-interact (how quickly interactive elements appear, like menu items and buttons and videos). The first thing to do is enable GZIP (all modern browsers support GZIP-compressed files) on text based objects like HTML, CSS, JS, XML, and more. Of course, don’t compress objects like images and PDFs that are already compressed as this can actually worsen latency by adding unnecessary compute cycles (first to compress and then to decompress). The next thing to do is to decrease the time-to-paint by ordering web page elements to load more efficiently. All browsers have different ways to order and load elements. A solution like FEA (Front-end Acceleration) can help dynamically re-order elements depending upon the browser. Third is to deliver device-specific content (more about this in the fourth prong). You can use device-detection scripts on the incoming request header to determine which browser is asking for content and deliver content that has been optimized for that device.
4. Address mobile. The last prong (yeah, I know, tridents really only have three prongs) is all about mobile. Unlike desktop browsers, mobile browsers have very limited cache (mobile Chrome only has 32MB for example). When you force those browsers to load more data than the cache can handle you actually make the device work harder which, in turn, can slow down the whole experience. This is especially true for images. When delivering a web experience to a mobile device you should send images that are specifically tailored to it. That means cropping and sizing images differently, preloading, and using progressive download technologies like LQIP. Of course, mobile delivery is a hard topic. You can code for it and CDNs can help by resizing on the fly, but ultimately you should research your options and the image formats available to you. But delivering a great mobile experience isn’t just about images. You should also make adjustments like TCP optimization (sizing your windows to reduce RTTs), and have a small object and large object delivery strategy. Remember that bursts of data can deliver smaller objects in fewer RTTs and mobile radios are optimized for bursty traffic, so you should try to maintain a constant stream of data during large object downloads.
Of course, there are lots of other ways to make your web experiences faster and better for your end users. My four prongs are by no means comprehensive. They are simply meant as a conversation starter to get you thinking about your strategy for improving the performance of your website. If you have some other techniques, I’d love to hear about them in the comments below.
This blog post was presented by Jason Thibeault, Senior Director of Marketing Strategy, at Limelight Networks.