Sep 10

The time it takes to render a landing page dramatically affects bounce rate. If it takes more than around 4 seconds for a visitor to start seeing your page they get bored and hit the back button.  We continually invest in engineering improvements to improve our page load times and constantly monitor key metrics, however as traffic patterns and server loads change, so do the rules of the game.

We have implemented nearly every performance enhancement possible and by far the most effective one for dynamic pages is page caching. What caching  does is store a copy of every page in the web server’s cache for a period of time. If someone requests the page during that period of time then the web server can serve it up immediately without having to make a request to the actual application.

For us this cuts a full second off of our page load time.  However, recently our page caching started becoming less effective and a greater percentage of landing pages where not in the cache, resulting in increased page load times and increased bounce rate.

The problem was that over the last six months the number of landing pages that the search engines were sending traffic to increased exponentially.  Every month Google sends visitors to over 100,000 different landing pages out of the 250,000 pages that it has indexed.

Caching 100,000 pages in itself is not problematic, however because we dynamically convert pricing on each landing page to the local currency of the visitor it meant we were in effect trying to cache a multiple of this number. At times this was as high as 60 different copies.

This caused our front cache to constantly flush the older pages resulting in decreased coverage of the landing pages.

We examined two possible solutions. The first one was adding more hardware.  This wasn’t a good idea because our problem was an exponential problem as both our landing page and countries that visitors were arriving from were increasing. We came to the realization that we had to stop caching a different page for each source country.

The problem was that we still wanted to have the performance improvements of page caching and to be able to localize into each visitor’s currency.

Our solution was to only cache a single master page for each landing page with the price in Euro. We then store the visitor’s currency and conversion rate in a cookie that we place in their browser. We use JavaScript in the browser to calculate and  display the currency.

This has allowed us to work with the boundaries of our existing hardware and implement a scaling strategy that has near linear requirements on hardware.

Tagged with:
preload preload preload