Earlier you had to choose, should you personalize or cache everything... we wanted to do both. -- Fredrik Ahlen (CTO)
The business decision had been made. Fredrik Ahlen (CTO) and Patrik Wallin (Lead Developer) of Health & Sports Nutrition Group (Gymgrossisten) were going to undergo a personalization overhaul to increase conversion rates. This meant personalizing nearly everything -- category pages, product pages, product recommendations and more. It was up to Fredrik and Patrik to make this happen on a site running on an e-commerce platform long past it's lifetime and offering poor website performance, poor stability, and limited personalization.
Step one was switching an e-commerce platform that allowed for much higher levels of personalization, but this only addressed part of the problem. Increased personalization put a higher demand on their web servers, resulting in poor web performance and only fair stability on their new platform. As Fredrik and Patrik saw it, they were at a crossroads. They could either:
- Give up and either a). deal with the performance repercussions of their personalization efforts, or b). revert to their old platform
- Innovate and find a solution
Obviously, Fredrik and Patrik wouldn't have spoken at the Akamai Edge Conference (and we wouldn't be writing this post) if they decided to give up. So what did they do?
First, they identified their issues, which were rather significant. Key challenges included:
- Uncacheable pages due to increased personalization
- Erratic web transaction response times
- Low request per minute (RPM) capacity per server
- High operating costs
- Complex infrastructure
- Increased lead time for changes
- Existing legacy from their previous platform
Fredrik and Patrik set a high bar for their project. In addition to overcoming the above, they sought to improve performance and get to the "magic" page load time of one second and offload servers to lower POP (point of presence) costs by 50 percent. To accomplish this, they needed to employ techniques and technologies (or create their own) so they could cache their dynamic content.
There is a prevailing thought that caching personalized content in e-commerce isn't feasible. While true for certain elements, the vast majority actually can be cached, it just requires an adjustment in thinking. The key is to re-imagine the way you view a web page. Rather than seeing web pages as the way they are viewed on a site, think of each page as a true app with multiple layers, each of which different tasks can be completed and prioritized. For example, if you remove all products from a homepage, you have a cacheable base page. All you have to do next is figure out how to get the products back into the page without sacrificing website performance.
- ESI is a markup language to define web page components for dynamic assembly and delivery of web apps at the edge of the Internet. Essentially, it means companies can develop web apps once and choose at deployment time where the app should be assembled.
- Ajax is a set of web development techniques that allows for web applications to send and retrieve data from a server asynchronously without interfering or delaying the behavior of the existing page.
The last piece of the solution had to be created by Patrik and team. They developed a single purpose app, codename: cosmic treadmill, whose responsibility is to manage which products will be shown and generating requests into each product box. That app is armed with logic that makes single ESI requests for each product box, which then delivers the content to the product box from cache. When combined with other optimizations, this made nearly all of the dynamic site content cacheable. They deployed cosmic treadmill on multiple pages, including shopping cards, product pages, product data, page headers, product listings, and more. (For specifics on how each section was addressed, watch the full video here.)
Now let's get to the fun part - results. To evaluate success, Fredrik and Patrik created a formula and ran the numbers before and after to identify end-user time the app saved. They saw incredible web performance benefits:
- Average time on server by request: 26% compared to 100% previously
- 75% faster average get request
- 74% reduced total load under pressure
- 400% increased capacity for requests per web server
- Faster Time To First Byte (TTFB)
- Homepage: 80% less user load time
- Category Pages: 88% less user load time
- Product Pages: 89% less user load time
- Search Autocomplete: 90% less user load time
These numbers are great, but how do they translate into business benefits for Health & Sports Nutrition Group? Faster delivery means increased conversion rates and improved brand perception. Increased RPM capacity results in low operating costs, minimal website infrastructure and easier updates. For companies evaluating ways they can increase personalization while improving performance and saving costs, Fredrik advised the following:
- If you don't cache... start caching!
- Invest in removing hindrances to caching
- Identify which site processes are moneymakers (like checkout pages) and focus on optimizing those to see real dollar values
- Outside of IT, there is only $$. While CTOs and developers love to work with the newest and most innovative technologies, building apps and employing optimization techniques are business decisions...it's all about money in the end. When pitching gains, always do so in dollar terms, not as new technology.