Web usage on tablets and smartphones is growing quickly and set to pass laptop and desktop usage. On our own site, Gogobot, we saw a 133% increase in mobile usage and a 300% increase in tablet usage over the last year. And by now more than 40% of our travel reviews and photos are coming from mobile. These new phones have huge screens and tablets have high-resolution displays (most notably, Apple’s Retina screens). Naturally, users now expect beautiful images on travel sites. This is part of a larger design shift online to greater reliance on images and lesser reliance on text-heavy pages to tell stories and tap into emotions.
The rise of the Social Web has unleashed a wave of personalization. This, in turn, requires new travel services like Gogobot to serve up dynamically generated pages with personal recommendations derived from individual preferences gleaned either from past behavior on a site, similar travelers or from a social graph. As a result, two users in Las Vegas may go to the same Las Vegas guide on Gogobot and get completely different results, with different food, hotel, and activity recommendations and different images.
These changes – from wired to wireless access, from small imagery to rich experiences, from static pages to dynamic personalization – have put tremendous stress on travel site publishers to maintain performance and load their Web applications very quickly. Mobile and wireless networks are more easily congested and unpredictable.
At Gogobot, we tackle all these challenges. Most of our pages include very large (by web standards) high-resolution images – stunning visuals that transport visitors to perfect island hideaways, luxe hotels or whatever exotic destination they dream about. In fact, we won the prestigious Crunchies award for our design and richness of the web experience. Every user’s page is unique and tailored to reflect both personal interests and recommendations from their social graph. We were the first travel service built entirely as a social recommendation engine and we hit a chord. In less than two years, we have gone from a few thousand to more than ten million people using Gogobot to plan their travels. This made us one of the fastest growing travel web sites in history.
A big part of why we were able to grow so quickly is because we kept our visitors happy by loading pages fast – as fast or faster than other travel sites. People hate to wait online. Milliseconds matter. The problem is multiplied when users are accessing sites over mobile and WiFi networks because it is much harder to know how fast the connection will be and whether the network will be congested. A fast website not only keeps customers happy, but it also can impact whether they find your site at all. Google has made changes to its SEO policies to include web site loading speed when determining its Page Rank – how high it shows up in search results, and soon Google will do so for mobile compatibility.
We rely on referral fees when users go from our site to partner sites where they book travel. That only occurs after visitors have gone deep into our site. So for us, speed directly impacts our bottom line even more than most e-commerce sites. To that end, we’ve gone to fairly extreme lengths to optimize our web pages and applications for fast page loads. Here are a few of the tricks we use to optimize Gogobot in general, and for mobile devices in particular.
Monitor Websites, Key Transaction Processes, and Infrastructure
In the last decade, as cloud computing has developed, a wide array of newer, more granular monitoring tools have reached the market that are great for startups but can also scale up easily. We use New Relic, one of the most popular SaaS performance management tools, to monitor our entire application infrastructure. This includes measuring server performance to monitoring website load times, api latency, mobile performance and page availability to giving us guidance on which lines of code are actually slowing down Gogobot. We use the service for live monitoring (servers and sites) and as a test-dev tool to help us optimize our Ruby-on-Rails application code. Because it is SaaS, we don’t have to manage any software. All that we need to do is load a small agent into each of our virtual servers that we want to monitor. Because it can give us a view of our entire application and infrastructure stack, it is invaluable for alerting us to trouble and helping us troubleshoot when things go wrong.
Almost all web sites include components that remain the same every time they get loaded. For example, every time you visit Amazon’s homepage the logo is at the top of the page. These components can be stored, or cached so that the data is saved close to the user or in their browser on their device. This means static images and content don’t need to be downloaded by a user every time they return to your site. As a bonus, caching static components can also reduce the bandwidth and hosting costs for your websites. We deploy over 200 gigabytes of cache in memory in the cloud to make sure that we have enough capacity and can push things as quickly as possible to the end users.
To take this a step further, we built a system that has multiple tiers of cache (Memcached, Redis, and more) ending with a third-party service that caches this information close to end users near major Internet access points around the globe. With this system, we can propagate changes to any cached category (images or HTML components) in seconds throughout our entire infrastructure. Some assets are cached for all users, some are cached for only specific groups of users or for a specific user – which leads to our next trick. To do this effectively, we also needed to map out everywhere on our site and applications’ cached components needed to be replaced or added when a cache validated and updated.
Back-End Personalization Engine
We use a NoSQL datastore (MongoDB) to cache and rapidly retrieve from memory personally relevant images and text information. This means when someone in your social graph uploads a new photo of a Chelsea hotel while you are looking at hotels in New York City, for example, we can put that picture into the personalization structure that is specific to your query set (New York City hotels) before you even leave the page. This is important because a significant percentage of our users are actually accessing our application while they are at a destination and using it for research and guidance. Understanding which information can be personalized, putting that information in the right place in our infrastructure, combined with our multi-tiered caching, is the secret sauce. Building a back-end personalization engine that functions seamlessly with a multi-layered cache infrastructure is a complex exercise, but well worth the time because this mapping and detail gives us a specific blueprint of not only how and when to replace obvious items (home page images) but also harder to recognize and personalize items deep in the site. And that gives us leg up over other travel sites in keeping low latency and fresh content for users.
Replace CDN and Legacy Caching with Web App Streaming
The increased prevalence of richer, high-resolution web experiences mean that the Internet is a radically different place than what it was a decade ago. Unfortunately, current Content Delivery Networks (CDNs) that are the key staple for web performance tuning haven’t kept up with the times. They were primarily designed to deal with static objects and for an era when delivery times were slowed primarily by weaknesses in the core of the Internet. We first used Amazon CloudFront and then Cotendo (acquired by Akamai), but we weren’t satisfied with the results. Our pages just weren’t loading fast enough. Fortunately, a new provider called Instart Logic has come along that attacks this problem differently. Instead of downloading an entire web page before allowing a user to interact with it, their Web Application Streaming Network breaks down images, HTML, and other Web page components into smaller pieces. It learns which ones the users tend to interact with first and sends the most important ones down first. This allows the user to begin to interact with our website much more quickly while the rest of the site downloads in the background. At Gogobot we’ve seen a 45 percent improvement in performance times using this technology.
Get Asynchronous With AJAX
Optimize All Images
We have millions of images loaded into our system, but we use a limited number of image sizes. Forcing an application server to cut or trim an image on the fly is a major performance drag. For this reason, we pre-cut all the different sizes of images before we load them into our cache. In doing so, we shift the burden of processing to away from when the user is accessing the site, and to the time period when we are loading the images into the site before a user even touches them. Doing so saves precious milliseconds and also makes it easier for us to scale our back-end infrastructure to match demand and usage requirements.
At Gogobot, implementing these five steps shaved crucial seconds off our page load times and increased the richness of our user experience. As a result, we have seen higher user retention, higher time spent on the site, and happier users. With the web shifting to mobile, any site publisher who doesn’t work extra-hard to speed up their web application delivery, particularly for mobile form factors, risks getting left behind.
Ori Zaltzman is founder and CTO of gogobot.com.