Lina Hansson on web.dev

How Swappie increased mobile revenue by 42% by focusing on Core Web Vitals

2021-09-15T00:00:00Z

Swappie is a successful start-up that sells refurbished phones. For a few years they prioritized adding new features over site performance, however when they noticed that business results on the mobile site were lagging behind the desktop version, a shift happened. They focused on optimizing performance and soon saw an uptick in mobile revenue.

42_%

Increase in revenue coming from mobile visitors

10_pp*

*percentage point Rel mCvR increase

Highlighting the opportunity #

Relative Mobile Conversion Rate (Rel mCvR) is calculated by dividing the Mobile Conversion Rate with the Desktop Conversion Rate. There are many opportunities for tracking speed metrics, but connecting them to business metrics can be quite tricky. Since the same campaigns and seasonalities reach both mobile and desktop, the Rel mCvR metric strips away the influence of these external parameters, and only shows if the mobile site is improving or not.

The average for the ten biggest e-commerce sites in the United States is a Rel mCvR of 50%, but Swappie was at 24%. This indicated that the mobile site had challenges and that the company was missing out on revenue, which led to launching the performance improvement project.

Measuring the impact of performance improvements #

Swappie used Google Analytics to set up daily tracking of Rel mCvR and Mobile Average Page Load Time, using this template spreadsheet. (Read the instructions for how to use the spreadsheet.) They also started tracking Core Web Vitals through Google Analytics and BigQuery. With tracking in place, the developers started working on site performance.

After only three months of work, the impact was clear–Rel mCvR went from 24% to 34% and mobile revenue had increased 42%!

23_%

Lower average page load time

55_%

Lower LCP

91_%

Lower CLS

90_%

Lower FID

Optimizations #

Optimizing for LCP and CLS #

Swappie's development team found that there was lots of room for improvement of small things that were overlooked for a long time. Studying the site on different viewports, and in different languages, highlighted issues with LCP and CLS that were easy to solve and had a big impact on overall performance. For example, rendering the LCP element on the server instead of the client when possible led to decreased LCP.

Detecting layout shifts was challenging, since they might vary a lot based on the viewport and connection. After getting CWV metrics from users to their analytics, they knew they were on the right track as CLS had decreased.

Images #

Images were optimised with preloading, lazy loading and proper sizing. They preload major images (for example LCP), while loading images outside of the viewport only when needed.

Fonts #

Swappie optimised fonts by switching providers. This made a big impact as they needed an optimal way to handle typefaces required by different languages.

Third-party scripts #

Swappie put a lot of effort into reviewing each third-party script and widget, where it was used, and the functionalities it provided. After discussions with all the stakeholders, they made plans to reduce the scripts' impact on the site, while keeping the functionalities. They removed what was unnecessary and optimized the rest, significantly decreasing the amount of third-party JavaScript on the site.

Removing unused code and optimizing bundling #

Optimising imports and removing unused JS and CSS contributed small improvements to Swappie's site performance, however those small improvements add up over time. They also optimised their bundling setup.

Creating a performance culture at Swappie #

The result Swappie achieved stems not only from the changes in the code, but also the changes in the organization and its priorities.

The engineering lead, Teemu Huovinen, explains:

You need to link site speed to business metrics to truly highlight the importance of it. It all comes down to prioritisation when you're short on time and resources, which is always the case. Prioritising customer value is the way to go, but it's all too easy to focus on new features and more direct conversion improvements if you see site speed as only improving the "feel" of the site. Linking site speed to business metrics is not always easy, and that's where the calculation with Rel mCvR helped us a lot.

Teemu Huovinen

Once the team of developers was given the opportunity to focus completely on site speed for a quarter, they were more motivated to dive deeper.

Combining our impact with our team's growth is what makes it even more impressive. Four of our seven developers had started within the month when we began working on performance. All credit to the team, it's truly amazing how we were able to rally around the topic and have such great impact.

Teemu Huovinen

Teemu also points out the importance of spending time at the start to make data-informed plans, learning how to use the DevTools Performance tab, and setting up user analytics before making any improvements. Graphs (especially the ones going in the right direction) are a great source of feedback and validation for your work! Looking at user CWV metrics alongside Lighthouse scores helped them focus on optimizing the right things that would affect the most people.

Fixing website speed cross-functionally

2020-02-28T00:00:00Z

One common myth connected to site speed is that it's only the development team's responsibility. The reality is that a fast site requires help from several departments. Developers can rarely solve the issues alone, no matter how talented they are. So how do you fix speed together with your colleagues? This article explains how you (as a web developer) can convince your company to prioritize site speed, get help from different departments while optimizing, and increase awareness of your optimization project's success.

Fix speed with the help of your business stakeholders #

Many companies are in the middle of a disruptive shift in consumer behavior, where the growth of people buying on digital platforms instead of physical stores tells the tale that companies need to adjust quickly or risk facing decreasing revenue. This will require both new organizational processes and mindsets, and a strong buy-in from the stakeholders in order to succeed.

The shared challenge #

The way companies organize themselves will most likely need to change within several levels. First of all, a speed project, with the potential uplift in revenue that it can create, will be difficult to perform without developers getting time to work on it. The resource allocation needs to be in place, and the collaboration with other departments such as marketing and web designers will often go smoother if stakeholders and executives show that it's a priority project.

Apart from this operational level, it's also important for stakeholders to understand that there are two shifts happening right now:

Even though a larger proportion of your sales might come from the physical stores, most customers will use a digital platform such as your site before the purchase in the stores. If the site doesn't give visitors a good user experience, then the revenue in physical stores risk suffering as well. Plus, studies show that it also affects customers' willingness to recommend your business and their loyalty to your business.
The growth of mobile visitors is stronger than desktop visitors, making mobile-first either a current or future state to prepare for. Also, there's a strong correlation between site speed and conversions on mobile, with one study from SOASTA showing that for every second delay in mobile page load, conversions can fall by up to 20%.

This means that companies that make executive decisions informed by the people who are experts on digital platforms will have an edge. One suggestion could thereby be to invite one developer to the meetings where business decisions are being made, to ensure that the site and its constraints are being considered from the start, and that way, secure increased sales.

Send a proposal to your stakeholders #

In general, around 10% of sales happen on digital platforms, but studies show that as much as 85% of the sales in physical stores are influenced digitally first. Having a site that performs well, especially on mobile (which is becoming the primary device), is thereby crucial for our business's revenue. We propose a speed project that will help the site increase conversions, and to set up streams of communication so that the insights in technical teams can be better put to use before decisions that will affect the site are made.

Prepare for meeting with your stakeholders #

Before meeting with stakeholders, make sure you're prepared with data for your website and your competitors' sites, and data that demonstrates high ROI for the changes you're suggesting. Gather data around the importance of speed. The best scenario is if it's connected to the company's revenue. Here are some ways to achieve this:

Calculate your relative mobile conversion rate. Work with your analytics team and perform the analysis described in The value of speed. If you historically have one period (at least 2-3 months) when the load times have been much higher than another period of equal length, then the slow site speed will usually have affected mobile conversions heavily. Through the analysis you can calculate how much revenue the company lost during the period of bad speed, proving the value of speed. If load times have stayed at about the same level, the analysis will be difficult to perform and the below alternatives can give more answers.
Estimate the value of speed from statistical models. With the help of Google's TestMySite you can run a test and then calculate the impact that a faster site can have on your business. All you need is data around average monthly visitors, conversion rate, and average order value, which your analytics team can help you with.
Provide best practice case studies. You can also use cases from other companies, who've made their site faster and seen the effect. How Page Load Time Affects Conversion Rates: 12 Case Studies provides some examples.
Show the importance of mobile. Ask the analytics team to provide data around what percentage of your traffic comes from mobile versus desktop.
Research how much it will cost. The above calculations are ways to show stakeholders the possible revenue uplift from speed, but in order for stakeholders to make decisions they need to know the ROI, so if you come prepared with an estimated cost then the executive decision can be reached faster. To do this, evaluate how long the initial focused speed project will take, and how much time you will need for maintenance afterwards. For instance, in Fast-forward thinking: TUI speed up their site by breaking down silos, the developers were given 20% of their time free from backlogs and campaigns, which they could devote to speed projects and other ways of making the site better.

Meet with your stakeholders #

Present how much traffic you are getting from mobile versus desktop, and the growth you've had from mobile the last few years. This showcases the importance of creating a great mobile experience.
Present your findings on how speed influences the company's revenue.
Let the stakeholders know that the developers can help increase revenue from the mobile visitors if they are given time to work on speed continuously.
Suggest that one person from the development team should be invited to executive meetings where decisions around the site will be taken. Nowadays we sell on digital platforms. The winners will be the companies who start communicating with their digital experts. Modern companies will need to have communication streams set up between departments and between stakeholders and developers. A study by the Harvard Business Review showed that one in six IT projects has a cost overrun of 200%. One example was Kmart, which was losing its competitive position to Walmart and Target when it began its $1.4 billion IT modernization project in 2000. By setting up communication and maintenance early, silos can be broken down and knowledge sharing can become a competitive advantage.

Fix speed with the help of your marketing team #

The shared challenge #

Marketing teams need tools to handle ads and data in order to make informed decisions, but most tools slow down websites and are often implemented with render-blocking scripts which makes visitors who enter the site have to wait until they see anything on the screen. There is therefore a need for a balance; the marketing department needs data and tools, but for the site to get low bounce rates and high conversion rates it has to be fast, so that marketing gets a good return on their investments.

The balance is achieved by being careful with scripts:

Avoid duplicates that measure approximately the same thing.
Remove tools that are no longer used.
Don't measure "nice-to-have" things. Only measure business-critical things.

Since it's difficult for the developers to know what the marketing department is dependent on, and since the marketing department might not know which tools are especially heavy for the site, you need to collaborate.

Send a proposal to your marketing team #

Tools used for tracking and ads often block how quickly visitors see content when they enter the site. This reduces the value of marketing investments, since we pay for ads, people get interested, they click but then have to wait. This risks them getting annoyed and leaving. One study found that conversion rate decreased from around 50% to around 35% when the speed metric Time to Interactive increased from 0.15 s to 0.3 s. Can we work together on solving this to create a balance between the tools you need and site performance, making increased return on marketing investments a result?

Prepare for meeting with your marketing team #

Create a list of the scripts that are implemented on the site.
Send the list to marketing and ask them to take a look at it in advance and sort them into three buckets:
- Business-critical. These scripts must stay.
- Nice-to-have. Scripts that might be able to be used less or removed. For instance, sometimes companies collect heat maps or screen recordings, but the data might only be reviewed infrequently and not lead to action or increased conversions. In cases such as these it can be better to agree to only run the tools for (say) two weeks, collect the insights for analysis, then clean out the scripts until it's time for the next period of focused data collection.
- Not used or not owned. These should be removed.
Check how much each script slows down your site by comparing site speed with and without it. In WebPageTest this can be set up via the Block tab in Advanced Settings. Or you can block network requests in Chrome DevTools.

Meet with your marketing team #

Go through the list of scripts and give your view on each script. For instance, are any of the nice-to-have scripts very damaging to site performance? By receiving recommendations it's easier for the marketing team to prioritize, and by hearing about what is business-critical for them it's easier for you to understand their point of view.
Discuss the following topics:
- Are the benefits of the data collected leading to an uplift in conversions that exceeds the decrease caused by the site getting slower? Data can guide the decision.
- Has your company chosen a provider that has the fastest version of the tool on the market? The marketing department might need help from developers to work out whether business critical tools can be replaced by faster alternatives.
- Are there alternatives to any of the scripts on the site? For instance, instead of heatmaps it might be possible to start doing usability tests where you also hear about the "why" behind user behavior, often leading to deeper insights.

Agree on next steps #

Decide on a process moving forward. Should marketing always ask the developers to review new tools and their impact on speed before implementation? Or should marketing get a performance budget where they learn how to check speed and they themselves can prioritize which tools they want as long as they meet the speed target?

Fix speed with the help of your web design team #

One of the biggest challenges for web performance is that while connectivity might be getting faster in many regions, websites are becoming heavier and as a result actually getting slower. Developers need to collaborate with web designers in order to solve this.

The shared challenge #

In the end, all departments within a company are usually dependent on the site leading to conversions, whether that's for revenue generation or something else. And the harsh truth is that it doesn't matter how beautiful web pages are if they take such a long time to load that people don't stick around to see them.

But slim web pages are a shared responsibility. Developers can use various image optimization techniques to make images load faster. Web designers can create pages that help keep page weight below an agreed level.

Send a proposal to your web design team #

Studies show that pages with fewer images and less elements create more conversions. For example, a study by Google and SOASTA found that sessions that converted users had 38% fewer images than sessions that didn't convert. Can we work together to reach speed targets and set up a joint collaboration that can increase conversions on the site? Examples of what we can achieve together include finding the right level of image compression with a balance between quality and speed, or reducing complex layouts or functionalities that often result in heavy, slow sites.

Prepare for a meeting with your web design team #

Track which pages on the site have the highest load time and highest page weight. For instance, if you're working with an e-commerce site, make sure you check not just the home page, but also any campaign pages, some of the biggest category pages, some of the product pages, and the checkout flow.
Prepare a performance budget proposal for the designers. One alternative is to start as simple as possible with page weight as the metric and set 1 MB as the target for all pages (or 1.5 MB if branding is very important for conversions).
Prepare a list of which pages end up above the target page weight level.

Meet with your web design team #

Commit to investigating how the development team can deliver images faster through various image optimization techniques, such as image compression, responsive images, image resizing, lazy loading, caching, and server optimization.
Create a test page where images are published in different image qualities and dimensions, and agree on a level that balances performance and quality on different screens. Remember that visitors on mobile often have short session length, with one study showing that more than half of mobile sessions are 30 seconds or shorter. These users might not study images in detail and might prefer the site to be fast.
Propose a performance budget where the web designers commit to making sure that all web pages have a page weight below 1 MB (or at maximum 1.5 MB).

Fix speed with the help of your analytics team #

Businesses need data to know what to focus on and to get a basis for decisions. But even though many talk about the importance of site speed and its connection to revenue and sales, there are still many companies that don't include speed in their weekly reports outside tech teams. This can be changed if developers start collaborating with analytics teams.

The shared challenge #

The reality is this: what's not reported will not be focused on. If site speed is not part of weekly or monthly reports to business stakeholders, it will easily be forgotten and you will have a hard time getting resources to focus on it. But since analytics teams often aren't experienced with tracking speed, they will need help from developers. And the developers will need help from the analytics team to calculate the effect on revenue when speed improvements are made. These departments are more dependent on each other than one might at first think.

Send a proposal to your analytics team #

Many case studies show the effect site speed has on revenue and bounce rate. Could we possibly collaborate to set up site speed tracking for our company, and perhaps get speed as a part of the reports going to stakeholders so that we get more buy-in?

Prepare for a meeting with your analytics team #

Track speed regularly. One recommendation is to use an API with a tool like Lighthouse CI, PageSpeed Insights, or WebPageTest, enabling you to collect stats regularly in a controlled lab setting for easy benchmarking across different time periods.
Forward The value of speed to the analytics team and ask if they can perform the analysis so that you have the chart ready to be analyzed during the meeting.

Meet with your analytics team #

Check the chart created from The value of speed. Relative mobile conversion rate is one way of tracking the impact of speed and how your site is improving. Ask the analytics team if they're open to start tracking this.
Decide if the load time metric in Google Analytics is good enough for simplified business reports. The value of speed uses this metric. As many developers know, this is only one of many important speed metrics, and since it's in Google Analytics it's also field data instead of lab data. But, is it good enough to be used for simplified business reports? Check the result you get from the analysis above, and see if it is possible to observe the relative mobile conversion rate going down when load times have been high for at least 2–3 months, and if the relative mobile conversion rate goes up when load times have been low for 2–3 months. If your load times have remained pretty stable, it will be difficult to know if the analysis is working for you until you've improved speed heavily. If so, go with the next alternative.
Show your charts for the speed metrics the developers use. Explain them to the analytics team and see if you discover correlations with the conversion rate or the relative mobile conversion rate.
Give the analytics team time to think about ways to use speed in calculations connected to revenue and how to report this to stakeholders. This is often a new topic for them. Then meet again and try out an approach that you agree upon. As always, you need to revise data collection until you find the right fit, but this is a way to start the collaboration.

Next steps #

Ask your analytics team to perform the analysis outlined in The value of speed after the speed project has led to big improvements. It will show the company how much more conversions and revenue it has gained, rewarding your team as well as all of the departments that collaborated with you. This can be included in a weekly report to stakeholders, so the project doesn't become a one-off effort but is continuously maintained.

The value of speed

2019-06-13T00:00:00Z

After a lot of hard work, you've done it. You've made your company's site noticeably faster. Now it's time for the fun part: showing stakeholders how much extra revenue your work has generated!

In this post we'll walk through how to do that by calculating the relative mobile conversion rate. This metric is useful because it quantifies the effects of site improvements while excluding external factors like marketing campaigns, which can obscure your findings. Let's get started!

Relative Mobile Conversion Rate (Rel mCvR) #

A site's conversion rate can be influenced by site characteristics— like speed and usability—and by external factors—like marketing campaigns, seasonal events, and the mix of marketing channels.

Since you're interested in how site speed affects conversions, the mobile site is most relevant— that's where you're most likely to see the benefits of speed improvements. Rather than looking at the mobile conversion rate alone, though, you'll be analyzing the relative mobile conversion rate (Rel mCvR), which is calculated by dividing the mobile conversion rate by the desktop conversion rate. This approach reduces the noise from external factors, which tend to affect both desktop and mobile, and makes it easier to see whether any increases in the mobile site's effectiveness were actually caused by the speed improvements.

Doing the analysis #

Make sure you have access to your site's Google Analytics, or collaborate with the analytics team. If you don't have a Google Analytics account, you can learn how to set one up at Get started with Analytics.

Step 1: Go to Google Analytics and click Admin. Under View, choose View Settings. There, copy the View ID.

Step 2: Go to this spreadsheet and click File, and Make a copy.

Step 3: Insert the View ID from Google Analytics into field B3, C3 and D3 in the spreadsheet. If your Google Analytics has goals instead of Ecommerce Conversion Rate, change field B6 and C6 so that you remove ga:transactionsPerSession and instead type in ga:goalConversionRateAll in the two fields.

Step 4: In the spreadsheet, click Add-ons, Google Analytics, and choose Run reports. Then go to the spreadsheet page Rel mCvR and see the results.

You should now have a chart that looks something like this:

Step 6: Using the chart, identify a period before the speed optimization (when load times were high) and a period after the speed optimization (when load times should be lower) that you want to analyze. In this example, you would compare eight weeks in Jan–Feb to eight weeks in Aug–Sept.

Step 7: In a new sheet, calculate the average load time and rel mCvR for the two periods. Then add the revenue coming from mobile visitors during the period after the speed optimization (Aug–Sept in the example). You can find revenue data in Google Analytics under the section Audience > Mobile > Overview.

Step 8: Now calculate what the revenue would have been if Rel mCvR had not improved. Do this by dividing the revenue (€1,835,962) by the current Rel mCvR (51%) and multiplying by the Rel mCvR for the period before the speed optimization (42%).

Step 9: Subtract the revenue that the company earned from what it would have earned if Rel mCvR had not improved.

In this example, the company earned an additional €323,993 in eight weeks thanks to Rel mCvR improving —that is, thanks to the mobile site becoming faster.

Things to consider when analyzing Rel mCvR #

As noted above, other changes to the site, such as UX improvements, can influence Rel mCvR.

Check that speed was the only big change to the site during the period you want to study. If there were other changes, Rel mCvR can tell you the effect of the changes as a group, but not of an individual change.
Watch out for any changes or events that affected the desktop site but not the mobile site —they can skew your results. If you discover any desktop-only changes, omit the affected period from your analysis.
You might wonder whether an increase in Rel mCvR is caused by a shift in conversions from desktop to mobile rather than an increase in conversions overall. While there is likely to be some change in the mix of desktop and mobile conversions due to speed improvements, keep in mind that Rel mCvR calculates the mobile conversion rate relative to the desktop conversion rate. So, you only see an increase in Rel mCvR when mCvR goes up more than dCvR. In other words, when doing this calculation you're already counting low, which means you have a safety margin that can compensate for any shifts in the channel mix.

Summing up #

While it has some limitations, Rel mCvR is a great low-cost way to estimate how much a speed optimization increased revenue without, for example, having to run server-side or slow-down tests. And quantifying the relationship between performance and revenue can help you demonstrate the value of development projects whose benefits might not be immediately clear to non-technical stakeholders.

Next steps #

Aircraft instrument panel image by Arie Wubben on Unsplash