- 2019
- Speed & Performance
- Strategy, Leadership, UX
Upon joining Daniel Wellington, one of the first projects I undertook was to optimise the speed and performance of DanielWellington.com, through my team including both developers and UX designers. With a complete front-end rebuild of the site underway as we migrated to React, it was not only imperative we maintained our existing performance metrics but also took advantage of the opportunity to better them.
The hypothesis was simple. Through increasing the speed and performance of DanielWellington.com, we believed that we would provide a much faster, enjoyable experience for our customers, akin to a native application. We would know this to be true when we saw qualitative feedback stating so, and quantitative gains in load time, time to visually complete, speed index, time to interactive, bounce rate and conversion.
Why Focus on Speed and Performance?
In the non-smartphone era, the behaviour, technology, and environment of people accessing the internet were very different from that of today. Generally, people would jump on the internet a few times a day in their home or at work, on a desktop machine that had a large display, keyboard, and mouse, on a stable connection and for long periods at a time. As a brand, you had time to engage with your audience. Fast forward to the present day and accessing the internet isn’t as much of an occasion anymore, or predictable. We do so from anywhere at any time on a smart, mobile device, with unstable connections that can jump from 4G to nothing in no time, for short sporadic bursts up to 90 times a day, on smaller screens, and use our thumb to interact with what we see. Now, brands have mere seconds to engage with their audience.
All of this has not only changed our behaviour physically, in how we input information and navigate the web, but also our mental behaviour. Remember something loading on a 56k modem? We were happy to wait. Now if something doesn’t load in a few seconds or doesn’t respond instantly if we interact with it, we’re frustrated and stressed by it, gone, and unlikely to be seen again.
We have become incredibly impatient.
So, why focus on speed on performance? It’s the third pillar with good content and design, in providing a first-class mobile experience.
Importantly, not only does it provide a better experience for customers, but it also generates extra revenue. How? A reduced bounce rate through having a faster site allows more traffic to enter the conversion funnel. More people entering the funnel and sticking around enables more opportunity for conversion.
The Business Justification
In order to justify investing in speed and performance, we needed to be sure that our users would respond, as hoped, to a faster site. To understand this, we built a custom ‘drop off test’ that measured lost traffic (bounce rate) due to speed. Through this, we saw a strong correlation between speed and bounce rate. This data formed the basis of our justification, coupled with the expected outcomes of improved conversion.
Setting Our Targets
Following approval, the first step was to assess the lay of the land and benchmark the existing site, in order to set a baseline for our rebuild. We then looked to set our targets for the project and formulate how we were going to get there. This was also done with our users in mind. Research was undertaken to understand the most common low-end device type, browser, and connection accessing DanielWellington.com. This resulted in all our testing focusing on first-time users (un-cached traffic), on a fast 3G network, using a device with moderate CPU power.
As stated in the hypothesis, to drive the outcome we wanted to see, the core speed metrics targeted were load time, visually complete, speed index and time to interactive. Here’s how we looked at the start of the project and our vision for the future:
As you can see, we were some way off our targets set with a lot of work to do! Whilst they may seem ambitious, the team and I were confident in achieving them. That said, reaching these figures would only get more costly due to the increased complexity as we progressed. Once the obvious, low hanging fruit had been tackled, we planned to reassess any further direction based on our learnings and perceived opportunity.
Tackling the Low Hanging Fruit
In the first months, the team and I focused on tackling the low effort, high impact items, in order to show quick results back to the business. Images were currently not optimised, legacy scripts and fonts being loaded for no reason, and techniques such as lazy loading not employed. In addition to prioritising items that would see quick metric wins, we also weighted what we worked on towards increasing perceived speed. By making the site appear faster than it really is, we would maximise our gains. It is good to know that in many cases this is the best approach when optimising for speed and performance, over focusing on just the metrics themselves.
Whilst developers worked on the technical elements (which I’ll cover in the results section), designers focused on the loading experience. Together, the other challenge of creating a performant site was tackled, cultural change.
Creating a Speed & Performance Culture
Whilst the product team could certainly have a huge impact on increasing speed and performance, there are some external factors that would hinder results if not addressed. With marketing, content and brand teams able to take advantage of the flexibility the DanielWellington.com platform provides, they too would need to operate with speed and performance in mind.
Many companies operating within e-commerce are yet to catch up to designing for modern-day user behaviour when developing content. Regularly you will find autoplay video, desktop images on mobile, gifs, etc. all weighing down the performance of a site. All of these are served to a user without consideration for them and their environment. This is no surprise considering it’s usually created in an office, on a beautiful 27”+ display, with a fast stable connection. A lot of the time it can look very engaging, but if you know your customer and know they are bouncing off the page before it’s loaded because of the weight it adds, is it worth it?
In our case, this used to be common. The team and I went about changing this by educating departments on the impact of their decisions, and who our users are. Through undertaking this delicate and challenging task, we were successful in putting a stop to rich-media finding its way into the conversion funnel. This was a huge win as prior to this time, nearly all campaigns employed an element of this.
Through this education, we also communicated that in due course we would be setting performance budgets that everyone would be held accountable for. With revenue and customer impacting elements to what we were doing, everyone was on board.
The cultural change required for success was also needed within our development teams. Whilst our speed and performance focus was currently a project, for it to succeed, it needed to live beyond this and be a way of life. It needed weaving into the fabric of our product development. Working with my team, a training plan for all front-end developers within our e-commerce product team was put together and executed. The goal of this was to distribute knowledge and upskill everyone in the techniques and theory required to develop fast, performant products.
Automated Monitoring
Throughout the project, tools such as Webpagetest.org, Chrome DevTools, and Lighthouse had been used to monitor progress. Together they provided a good, thorough overview of the current state and where to next focus our efforts. However, these required a manual operation to run which in turn creates the potential to them being forgotten about. Having set our performance budgets, I needed something that would not only allow us to automate testing but to let us know when a budget had been breached.
To achieve this I made the case to purchase an off the shelf product, Speedcurve. Using this tool we were able to automate tests twice daily and have an alert sent out to our content and tech teams globally if a performance budget was breached. This enabled us to create a robust, lightweight process for what to do in the event of a breach and secure action is taken.
The tool also allowed for dashboards to be set up containing the key metrics we wanted to maintain and improve. By placing these on relevant screens within the product team area at our HQ, it ensured speed and performance remained front-of-mind long after the project was dissolved and absorbed into the development teams’ fabric.
The Result
Within 8 months, having tackled the low hanging fruits and subsequently moving on to a few of the trickier elements, some real progress had been made towards our targets. In our latest round of benchmarking some impressive numbers were recorded. Approximate reductions of 88% in speedindex, 64% in time to interactive, 72% in visually complete and 55% in load time were achieved.
Amongst many things, we achieved these figures by completing the following:
- Optimised our code to make our first impression fast and interactivity responsive.
- Shortened pages and removed what wasn’t core to the experience.
- Removed rich media across the conversion funnel.
- Optimised images using cropping, compression and webp formatting.
- Compressed fonts and implemented formats such as WOFF2.
- Optimised fonts through removing unnecessary characters and glyphs.
- Pre-cached elements of the next likely page a user is going to select.
- Prioritised content to be loaded to aid perceived speed.
- Utilised lazy loading so only content in view was loaded.
- Employed the ‘blur up’ image technique to aid perceived speed.
- Employed the ‘app shell’ model to prevent elements from jumping around the page as they load and cache core UI elements.
- Converted all UI imagery to SVG.
All of this resulted in some notable gains for the business. As page load decreased, mCVR increased. More importantly, however, for our customer’s experience, the difference was huge.
Our hypothesis was validated.
In covering our results, I also shared the value of our work through another benefit not often talked about when communicating the gains of improved speed and performance. This is the value-added to the marketing spend. If we are paying for traffic and an element of that traffic bounces before anything has loaded, we are essentially burning away money. If that traffic is now sticking around, we are adding value to that marketing spend. How much value in our case? An impressive 8.3%!
We still had work to do however in order for us to achieve our ambitious goals, especially around interactivity. For this to occur we submitted a further business justification that covered the validation of our previous, through the results seen so far, and a proposal to focus on some new technologies.
Where We’re Focusing Now: Javascript (JS), Accelerated Mobile Pages (AMP) and Progressive Web Apps (PWA)
In the updated business justification, the focus of continued work was weighted in three areas. Firstly we had a lot more work to do on our Javascript as evident from our results above. Our time to first interactive was too out of sync with our page appearing complete, and through remote user testing, it was apparent this was a problem. If a user sees something they want to interact with, it’s important that they can do so as ‘rage taps’ only lead to exits. Secondly, we wanted to explore two areas of interest in AMP and PWA. AMP due to the potential speed and SEO gains provided, and PWA due to the benefits beyond speed and performance.
It was early on that we decided to prioritise looking at PWA over AMP. With the selling point of PWA being a near-native app-like experience, the UX benefits this provides are incredibly intriguing. As covered earlier, with user behaviour having changed dramatically following the adoption of smartphones, PWA offers the ability to remove some of the friction built up in the transition. With that in mind, there’s a lot of excitement about what we might be able to do with the technology in the coming months ahead!
Final Words
The work in optimising DanielWellington.com had been an unquestionable success. A lot of this wouldn’t have been possible without a key member of my team, Patric Örgen. A huge thank you goes out to you!
I’ll be updating this page as more progress is made but if you have any questions in the meantime on anything contained, I’d be happy to answer them. Please reach out to me via email or Twitter.