Optimizing StyleList

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:

Isolate content creation from content consumption

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.

Move Javascript and CSS assets to the CDN

It’s one thing to keep images in the CDN, as they generally never change, but it’s another thing entirely to keep Javascript and CSS assets in a cache-heavy environment. We developed a process in which we deploy assets to the CDN at minification time, and we store them in a timestamped directory. The name of the directory is then stored within our application and is used by the content templates to determine which version of the assets to pull in. This gives us two distinct benefits:

1. The ability to cache-break whenever we change the Javascript or CSS files. Since the timestamped directory name changes after we minify, the old assets are no longer called for.

2. Developers can minify and deploy assets to the CDN from their local environments without breaking what’s currently in Production.

Lazy-load images

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.

Set cache headers on all images

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.

Has it worked?

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.

Heath Beckett

Heath Beckett is Ashe Avenue's Lead Front-end Developer. @heathclifff

blog comments powered by Disqus
LinkedIn Made in NY


109 S 5th #400
Brooklyn, NY 11249

Chapel Hill

1506 E Franklin St.
Suite 300
Chapel Hill, NC 27514