StyleList is the signature site in AOL’s Lifestyle group, with page views that can swing drastically based on current events. In the days following Kate Middleton’s pregnancy announcement, for example, site viewership skyrocketed. It’s a great site and we feel privileged to have the opportunity to power the technology behind it. The majority of the content on StyleList is higher-res photos of celebrities, clothing, makeup, and fashion products. The home page includes roughly 200 images — quite a burden to load, you may imagine — and even though we run the site in a four-node cluster with a dual-node Varnish cluster in front of it, and we’ve always made extensive use of a CDN for the images, we still noticed at times that our performance levels weren’t ideal. With AOL’s encouragement we recently conducted a special project to deeply investigate and optimize a number of site elements that were contributing to the occasional performance struggle. The following are steps that we’ve taken, and we imagine that other image-heavy content sites would benefit from taking similar steps:
We discovered that our content servers were under the most stress when StyleList’s editors were uploading new images. The CMS renders the same image in up to 15 different sizes and shapes, and image processing is particularly memory- and processor-intensive.
If an editor was uploading a new gallery of 20 images, each of them 1MB in size, the node’s load would increase and cause collisions with end users attempting to view other galleries. We made the decision to spin up a fifth CMS node and isolate all content creation there, meaning that the four-node cluster would only be used for downloading/viewing content. All content administration URLs were re-routed to the new content creation node, and the performance spikes immediately disappeared.
2. Developers can minify and deploy assets to the CDN from their local environments without breaking what’s currently in Production.
As mentioned above, StyleList’s home page includes over 200 images, all of which have been deemed important to the concept of the site. We realized that in spite of that large number, only the header images and the 8 carousel images are visible above the fold. We took on the task of lazy-loading all the other images on the page. We do so in two waves:
1. All visible images below the fold, including everything on the right rail, the full Inspiration Wall, and the first “page” of Featured List items, are lazy-loaded at the moment the window’s “load” event is fired.
2. Two seconds later, all non-visible images below the fold, including anywhere from 50-75 items on subsequent “pages” of the Featured List, are lazy-loaded.
Even though our CDN caches images for up to 24 hours, we noticed it wasn’t as apt to do so consistently unless we set Cache-Control headers before they’re stored in the first place. By caching images for up to 24 hours, we drastically reduce the amount of work the CMS has to do.
YES! On the server side we haven’t seen a performance spike in over a month. The editors are using the content creation node and it’s successfully able to handle all image processing without affecting the end users’ experience. On the front end, we’ve reduced the total page load time by a half — a major improvement for an already great site.