Maui Jim is a sunglass manufacturer founded in Hawaii and based in Peoria, IL. Their website runs on SAP Hybris, an e-commerce software suite. They recently needed to upgrade Hybris and also wanted to expand their international presence. On top of that, they realized the upgrade would be a good opportunity for a redesign.
A major software upgrade, expanding their international presence, and a redesign. All at the same time. That's an ambitious list, especially without an internal web design or development team. Fortunately they were already working with talented partners: a design agency, a Hybris firm, and many others. But they were still missing an element. They had ambitious performance goals and needed expert front-end development to achieve them. That's when Chromatic entered the frame.
Fast forward to today. The upgrade is complete and the redesign has launched globally. Maui Jim is now selling their products in more countries than ever. The front end is now powered with modern components built by Chromatic and the pages now load almost 4 times faster than before! We are proud of our contributions to that success and of what we were able to accomplish alongside Maui Jim’s other partners. The rest of this post will explore those contributions in more detail.
Building a component library and overseeing implementation
Prior to the redesign, Maui Jim's website was a good example of why component-based design and development has become so important. There was a wide variety of different designs for common elements like buttons and icons. Larger elements and entire pages were equally erratic. This leads to an inconsistent user experience which, on an e-commerce site, often means lost sales.
To solve this, Chromatic separated the redesigned pages into independent and reusable components. We then built a component library that houses the code for each individual component. This library also provides a user interface that gets used as a reference by many different teams on the project. Most important, it guides the implementation of the components on any digital property. That's right: creating a platform-agnostic library allows any property of the brand to easily use the components - not just Hybris.
Building a platform-agnostic library for such a large brand wasn't simple. How could we build components so that they would work within any page's layout? How could we silo the code for individual components, yet have them occasionally communicate with each other? How would we represent dynamic data and actions without back-end integration (such as product data and shopping carts)? We'll save the answers for another time, but needless to say, this approach does introduce unique challenges. Was it worth it? No question.
The end result is exactly as advertised. Sites built on both Hybris and WordPress have already implemented the library's code. They've used the templates as a reference and pull the component CSS and JavaScript straight from the library. This allows new pages to be prototyped and built extremely fast. Siloing component code has also reduced the number of bugs that often result from the otherwise global nature of HTML, CSS, and JS.
Changes or additions to any component code continue to happen in the library first. Any new enhancement or bug fix will then immediately be available to anything built from those components. Most important: the brand's user experience is now consistent across all web properties. The library will ensure that this continues far into the future.
Improving the user experience by improving performance
The other motivation for tapping Chromatic’s expertise was to improve performance. Lean components are certainly going to improve performance, but that wouldn’t be enough. Likewise, their website was already sitting behind Akamai. Akamai is an amazing product, but it’s not going to fix fundamental problems on its own. We needed to step back and look at the entire performance picture, and we did so through the lens of perceived performance.
Perceived performance measures how fast a website or application feels to a user. Traditional metrics like Load Time are still helpful, but they can be deceiving. It isn’t uncommon for code to continue loading long after a page is usable. It also isn’t uncommon for a page to report as loaded far before it is actually usable. Instead we want to know when the website appears to be loaded and is usable. Users don’t care if the bottom of the page or third party JavaScript is still loading if they’re already able to accomplish their goals.
Speed Index is the most common metric used to measure perceived performance. It’s calculated by programatically observing a filmstrip of images taken as the page is loading. We also measured the Time To First Byte, Start Render, Loaded, and Fully Loaded times. We used WebPagetest, a common and easy to use tool, to measure them against a 3G connection (5 Mbps).
With our metrics and tools in hand, we had Maui Jim identify five important pages to measure. We also had them identify three companies they considered direct competitors. We then measured those pages on the existing production Maui Jim website, as well as the equivalent pages of their competition. We also tested indirect competitors in the same industry and measured the three fastest that we found. We then used the fastest results as our benchmarks and created aggressive goals for the new website.
As the new site was built, we ran weekly tests against the staging environment and compared the results with our goals. We discussed the results with Maui Jim and their other partners, tracking what caused any differences we saw from the week prior. These results also influenced our suggestions on what we should prioritize next to continue towards those goals. We ended up with about 16 weeks of data that show our progress leading up to launch.
The results are astounding. The average Speed Index went from 5695 to 1445. This means that the website is now usable in less than 1.5 seconds on a 3G connection! That’s a 4x improvement! All Time To First Bytes now measure close to .2 seconds, as opposed to the previous average of .577s (it’s believed that Google may ding sites with a TTFB above .4s). The rest of the metrics, Start Render and load times, were essentially cut in half. Maui Jim’s new website launched with speeds faster than any we found across the industry.
Not only did these tests help us improve performance for launch, but they’ll help us keep the site fast far into the future. They’ve put real numbers on the effect that things like modal windows and third party JavaScript have on the user experience. In a world where one additional second of page load time can quickly lose 10% of revenue, those numbers are extremely important and useful.
We are happy to have helped Maui Jim treat performance as a first class citizen and we have no doubt that the results will show in their bottom line.
