MLSE - Toronto Maple Leafs Nation

Based in Toronto, Canada, MLSE is one of the leading sports and entertainment organizations in North America. It owns, among other teams (digital channels and sports facilities), the NHL’s Toronto Maple Leafs hockey team.

And it stands out as the company constantly looking to deliver both its teams’ fans and the participants to the various events organized in its sports facilities (e.g Air Canada Center) the best physical and digital experiences.

Taking a fan community website to a whole new level of performance with a fully reconfigured user system and integrated dedicated video section.

Maple Leaf Sports & Entertainment Ltd. (MLSE), based in Toronto, Canada, the company owning the Toronto Maple Leafs ice hockey team, dared us to create their new high-performance fan site: Leafs Nation. A site which would leverage Drupal’s user management capabilities and incorporate a Vimeo content dedicated section. And all this in the name of top performance!

Business challenge
“Best-in-class service experience for all fans” has been MLSE’s self-assumed mission. Digital experiences here included! With overall high performance and fast-loading video content as 2 major challenges to respond to.

Transformation
Drupal was chosen to “back up” all the Janrain-based user management processes while adding multiple layers of caching has been the accepted solution for boosting performance.

Results
The user management system has been completely reconfigured and the newly integrated video content section (Leafs Nation Network) optimized for performance via layered caching.

Business challenge story
Rich digital user experiences delivered at high speed

Implementing a new dedicated video section, fully reconfiguring the user management system and optimizing the site’s performance have been the main resolutions on our list. 

The Leafs Nation Network would serve Vimeo content (our client already had an account on Vimeo, where he was managing the site's video content) available to be embedded, via Vimeo API, to specific domains only (so, we were talking about private video content).

Moreover, the Janrain platform (with its multiple API calls, for every single user login/signup/edit info and all those long Janrain call queues) was the main “culprit” for the experienced delays in page load time.

And boosted site performance was about to become the ultimate goal driving all our future decisions, as well.

Transformation story
A new blazing fast fan community site incorporating a dedicated video section.

The project's particular needs and implementation “traps” that we predicted (or not) called for a whole lot of custom code writing, lots of custom-built modules and a few contributed modules, as well.

As previously mentioned, our client's fan community website was already running on Drupal 7 and they wanted to stick to Drupal. And specifically to this version of Drupal, since their users were already very familiarized with it.

Therefore, it's in Drupal 7 that they wished us to re-build it, from scratch, implementing the newly needed functionalities and making all the requested improvements.

And it sure was a transformation path paved with… challenges!

First of all, we strived to implement our Drupal solution (where Drupal would take over the data collected on users’ signing up via Janrain to create new Drupal accounts) for re-configuring the user system entirely.

Next, there was the Vimeo API rate limit (around 2500 calls per hour) and we were talking here about content being pulled exclusively from Vimeo.com, content that had to load at top speed on the future Leafs Nation Network. And this limitation called for a layer of caching.

The solution that we came up with was that of caching both Vimeo albums and videos (the first ones individually, by their album_id, while the latter by their video_id, on the Drupal site). Once we’ve resolved this issue, we applied the caching strategy on 2 other key sections of the fan site: “Gameday Coverage” and the “Fan Corner”. 

These 2 specific sections are in a different cache expire value and they can both be adjusted right from the admin menu, by the site admin himself/herself. This way, we managed to achieve some sort of compromise between a relatively low cache expire value and the certitude that the API rate limit wouldn't be reached.