Shopify's 2024 Dashboard: Faster Stores, Web Performance Explained

Shopify rolled out the new Performance Dashboard at the start of 2024. Chances are, it might seem your store's performance got better on its own.

But wait. You did not update the code, or hire someone to make it faster. How did this happen? Has your website become better by itself? I don't think so.

Then, what's special about the new dashboard?

Let's find out with a real-life example. We compare the 'old' dashboard of a live store to the 2024 rollout.

I will explain why performance seems better. And if you need to take any action.

But first, we have to know what web performance is, and how we measure it.

This way you get the complete picture.

This is going to be a long, in-depth guide. But you will come out with profound knowledge. You will understand web performance. And how to apply it.

You don't have to be an e-commerce store owner to get value from this guide. If you want to learn the basics of web performance but find other guides complicated? This is for you, too.

We are going down the rabbit hole. Grab a cup of coffee or tea first, get a good seat, and settle down to read.

What you will learn about:

• The old Shopify Online Store Speed and how it was calculated.
• What makes up the 2024 Shopify Web Performance Dashboard.
• Why Shopify made the change.
• What matters when evaluating Web Performance and how to measure it.
• What performance metrics are. Lighthouse performance scores, Google Core Web Vitals, and the tooling for metrics. Analogies to help understand metrics in a simple way.
• How we collect metrics data, real user data vs lab data, the misalignment between the two.
• In-depth guide on Google Core Web Vitals and why they are superior.
• How does all this tie into the new dashboard.
• Why web performance scores seem better than online store speed.
• Do you need to do anything about your own store's performance data?
• What you can do to improve your web performance: data, analytics, tools, action steps.
• What to do if you don't have enough real user data.

That’s going to be a lot.

But this guide aims to be different. You are getting simple explanations for complex ideas. I give analogies to simplify tough concepts. I make it as vanilla as I can.

The examples here are from a real Shopify store, so you are getting practical knowledge.

Every store owner should understand basic web performance concepts. I make it simple.

Let's dig in!

Dashboards Comparison

The "Online Store Speed" dashboard before 2024

The old dashboard was deceptively simple. It showed a single Online Speed Score based on Google Lighthouse's "performance score". Lighthouse is a free tool from Google and it evaluates website speeds.

We get this score by submitting the store's Homepage, Collection page, and best-selling product page to Google Lighthouse.

[For the nerds, the exact formula Shopify used for the score is below. The page scores here are Lighthouse scores.]

Online Speed Score = 
[ (Product Page Score x 31) + (Collection Page Score x 33) + (Home Page Score * 13) ] / 77        

I will explain Google Lighthouse later in this guide. For now, let's take a brief look at the new dashboard.

The updated "Web Performance" 2024 dashboard

To provide a good comparison with the previous dashboard, we use the 2024 dashboard for the same store. It has the same theme, there are no new apps and no optimizations. The only change is the dashboard.

Observations:

• Immediately we see there are now 3 'scores' instead of a single 'Speed Score'
• The 3 'scores' are web performance metrics: Largest Contentful Paint, First Input Delay, and Visual Stability. More later.
• It seems there is an improvement because two metrics have a 'Good' rating and the other one has a 'Moderate' rating. The previous dashboard showed a poor score of 34 out of 100. The messaging emphasized it: "Slower than similar stores".
• But it's the same store, same theme, same apps, almost the same inventory count, and there is no other change. So why does the new dashboard show an improvement?

Let's take a deep dive into the world of web performance metrics to understand all this! Starting with Lighthouse.

Lighthouse

Lighthouse is a free tool from Google to measure and improve website performance. It will even audit for SEO, accessibility, and other best practices. I will only focus on its performance features in this article.

Performance has to do with the perceived load speed, visual stability, and responsiveness of a website. Give Lighthouse your website URL. It will run an audit and give you the performance results. It will provide diagnostics for why your scores are bad and give recommendations to improve them.

More information about lighthouse.

You can run Lighthouse on command line, DOS/terminal style. There are simpler ways too and I will show them later.

Sample report from a command line run:

You don't need to be scared of the jargon in here, this was just to show you what's behind the scenes. You don't need to know what all of them mean.

Lighthouse Performance Score and Metrics

You can think of Lighthouse scores as putting together different numbers to get a single value. Think averages in school Maths. We call these numbers as 'metrics'.

The Lighthouse score is a 'weighted average' of different metrics. As of Lighthouse v10, these are:

• First Contentful Paint, FCP (10% weight).
• Speed Index, SI (10% weight).
• Largest Contentful Paint, LCP (25% weight).
• Total Blocking Time, TBT (30% weight).
• Cumulative Layout Shift, CLS (25% weight).

Look at the graphic. You can see how metric values and their weights make up the overall score of 40 in this example.

Next, we define the parameters. I elaborate on the 3 most important Lighthouse metrics.

Largest Contentful Paint (LCP)

The following are two internal dialogs of a website user:

"Wow, that product page loaded so quickly! Impressive. I barely had to wait to see what they offer. This site really knows how to keep things fast and smooth. Makes me want to explore more!"

"Clicking on that product... Seriously, why is it taking forever to load? I just want to see what they offer. Ugh, this delay is annoying. If this keeps up, I might just look elsewhere. They really need to speed up their site!!!"

• This metric shows you how fast a web page loads. When you visit a web page for the first time, there is that part of the page which you can see without scrolling. We call this 'above-the-fold' content. This above-the-fold content is different on mobile and desktop. Mobile phones have smaller screens. In that space, before you scroll, you can have some images or only a large one. How slow or fast the largest image loads is a signal of load time. This load time is the Largest Contentful Paint time.
• LCP is a field metric. This means it must be gauged from real user data. But Lighthouse can also evaluate a 'lab' version based on strict Lighthouse parameters. More on lab and real user data later in this guide.
• We improve LCP in two ways. Tell the browser to load the largest above-the-fold image faster. And to load 'below the fold' images slower. This way the browser allocates more resources to reduce LCP time. The technique to load the largest image faster is 'fetch priority'. Reducing the priority of images means 'lazy loading' them. These loading speeds are relative, meaning you will probably not notice unless it is slow.

Side note about LCP: Shopify stores fail this metric the most

Many Shopify themes don't discriminate the lazy loading. Even the LCP image is 'lazy-loaded' and this degrades performance. Lazy-loaded LCP images can take more than 10s to load. An optimized, priority image must take no more than 2.5s. Chances are your store is not passing this metric.

To be fair, the enabling tech is recent, dating back to September-October 2023 only. There was no way to detect if a Shopify section was above the fold. In 2024, this feature is baked into most Shopify 2.0 themes. It will not 'lazy load' images above the fold.

Cumulative Layout Shift (CLS)

The following is the internal dialog of a website user:

"Okay, I was just about to add that trendy chic bag to my cart... and whoa, why did everything suddenly move? It's a bit annoying when things keep shifting around unexpectedly. Like it's trying to catch a butterfly! Just makes me wish it would stay still for a sec, you know?"

• CLS is a measure of visual stability.
• In the old web days, visual stability was chaotic with images. When an image finished loading, it moved all content down in an unpredictable manner. This was abrupt and not a result of user interaction. People waited until web pages finished loading completely to interact. We expected such layout shifts. Not so more today.
• This still happens today if we don't explicitly reserve space for images beforehand. Advertisement banners behave the same way. No reserved space means other elements move down 'randomly'. You lose track of where you are on the page.
• CLS is a field metric, but we can try to infer it in a lab setting with Lighthouse.

Total Blocking Time (TBT)

"Clicking on that chic bag, but it's taking a while to load. I'm eager to see it up close. Come on, website! I don't have all day to wait around."

• TBT is a measure of responsiveness, usually dependent on Javascript code optimisation. If code is not optimized, it causes something known as 'blocking the main thread'. A fancy way of saying 'tasks', or things, are taking too long. The code is executing some extra steps not required for a given situation. For example, when you click on 'Add to cart', the browser executes code to load the whole web page. Instead, it should only execute code to, well, add your item to the cart.
• Your browser has no other option than to wait it out. This means the website becomes unresponsive for a short while. Not good.
• A TBT score greater than 200 milliseconds is considered bad.
• TBT is called a lab metric. It is a proxy for the real-world metrics: First Input Delay (FID) and Interaction to Next Paint (INP).
• Lab metrics, real-world metrics, FID, and INP are discussed later.

Lighthouse Test Environment

The metrics we just discussed (LCP, CLS, TBT) are evaluated in a strict, lab-controlled environment by Lighthouse. No other variables can affect the scores. I mean that the same conditions are always used for each test, as far as possible.

Think of it like if you fail a high school test, you get to retake the exact same test with the exact same questions in the exact same order, etc... You get the idea.

This keeps variability to a minimum. But, there is a catch about minimizing variability. You'll see.

Before we get there, you don't need to install Lighthouse on your PC/MAC to test your store.

You can use the PageSpeedInsights online tool, which provides easy access to Lighthouse. Jedi skills not required.

Side note about LCP and CLS in Lighthouse

LCP and CLS are field metrics but they can also be evaluated in a controlled lab setting.

PageSpeedInsights

You can use the online tool PageSpeedInsights to perform a performance audit of your website. PageSpeedInsights is courtesy of Google. Access it here:

https://pagespeed.web.dev/

Just plug in your website URL and click the 'Analyze' button.

Caveat: PageSpeedInsights can only access public URLs. But there is a way around, for themes which are not live. This way you can make changes to a copy of your live theme without risk. You even can test a new theme in this way.

After PageSpeedInsights is done, it displays a long list of diagnostics and recommendations.

There are two important sections in the results:

• "Discover what your real users are experiencing"
• "Diagnose performance issues"

"Discover what your real users are experiencing"

This section shows real-world performance data. How come? And what does real-world data even mean?

How real-world data is collected

Most Google Chrome users sync Chrome to their Google account. And most also enable usage statistics reporting. This is the "Help improve Chrome's features and performance" in Chrome settings:

If you have these settings turned ON, Chrome will collect and aggregate your user experience data.

What does this mean? As you browse a website, Chrome will monitor your experience. It will deduce your Core Web Vitals metrics LCP, CLS, FID/INP automatically. More about Core Web Vitals later in this guide.

This whole process is called Real User Monitoring (RUM). Chrome aggregates the data of all opted-in users in the Chrome User Experience Report (CrUX). This data forms the basis of the "Discover what your real users are experiencing" section.

Other firms have custom implementations of RUM. Or they use the Google Web Performance Working Group APIs. Monitoring tools such as New Relic or Datadog are good examples of custom RUM.

If I'm not wrong, Shopify have a custom RUM implementation, too.

So here is a screenshot of the "Discover what your real users are experiencing":

We see "Core Web Vitals: Passed" mentioned here and two new metrics:

• First Input Delay - FID
• Interaction to Next Paint - INP

These are field metrics which make up Google Core Web Vitals. And we are exploring what these are, in a while.

A "Passed" score means that the website has "Good" ratings for all the metrics. This is the same data and criteria as in the Shopify 2024 Performance Dashboard. If you expand the view, you will notice the ratings thresholds and the similarities:

"Diagnose performance issues"

Here, we have Lighthouse scores for the URL. This is similar to the Lighthouse chapter earlier in this article. You can refer back to that chapter if needed.

Diagnostics are categorized by metric. So this helps to see which diagnostics are the result of which metric.

Nothing new to add here.

Let's revisit the old Shopify performance dashboard again with our new-found knowledge.

Old Shopify Dashboard Revisited

The dashboard description should make more sense now:

1. "Google Lighthouse tests your page load speed and assigns a score to it, from 1 to 100"

• So you now know how Lighthouse tests webpages, how scores are assigned, and what metrics are used.
• First Contentful Paint, Speed Index, Largest Contentful Paint, Cumulative Layout Shift, Total Blocking Time.
• You also know that LCP, CLS, and TBT have more weight.

2. "The score you see here is a weighted average of 3 pages: home page and top-visited product and collection pages"

• The top-visited product and collection pages can change. So, we take the product page and collection page with the highest traffic in the last seven days.
• You can think of this as inputting the URLs of these pages to PageSpeedInsights. Then recording the scores of the performance section.
• Shopify takes the lighthouse scores of these 3 pages, aggregated over several days. Then they come up with a unified, single score. They used the formula I shared at the start of this article. This is the "Online Store Speed".

This was valid up until the start of 2024. Shopify now use the Google Core Web Vitals to evaluate web performance. This is more accurate than Lighthouse scores.

So what are these Core Web Vitals? Why are they more accurate than Lighthouse scores? How are they related to the Shopify 2024 performance dashboard?

Let's find out!

Google Core Web Vitals

How do we define what a great user experience on the web should be like?

We intuitively know when we are having a great browsing experience or a poor one.

But our intuition is fleeting and inconsistent. We cannot rely on it for accuracy. It seems we need some hard parameters by which to define our browsing experience, then?

"What you cannot measure, you cannot improve." – Lord Kelvin.

Enter Google Core Web Vitals:

• Web Vitals is a project by Google to help make websites better.
• It gives advice on what makes a website good for people to use. There are many metrics which describe web performance. Not all are equal. Google calls the most important measurements the "Core Web Vitals".
• Each Core Web Vital describes a different aspect of how people experience websites. How fast does a page load? How easy it is to interact with? How stable does it look?
• The Core Web Vitals can change with time. Defining and refining user experience on the web is an ever-changing endeavour. New research may show that we need to drop old ways of measuring performance. Right now Core Web Vitals focus on those three big buckets.

Government counter queue analogy

1. Loading Time: Think of this as how quickly people can get in line at a counter. We want the line to move fast so people don't have to wait too long to start their business.
2. Interactivity: This is like how quickly a counter is ready to serve people once they're in line. We want the counter staff to be ready to help as soon as people are in line, without any delays or waiting.
3. Visual Stability: This is similar to making sure everything stays in place while people are waiting in line. We don't want people to have to constantly shuffle around or adjust because the line keeps changing or shifting unexpectedly.

So, Core Web Vitals are like checking these three important elements to make sure using the web is as smooth and easy as possible. Just like waiting in line at a government counter.

Which metrics make up the current Core Web Vitals?

We have discussed some of them previously in this article:

• For Loading time: Largest Contentful Paint, LCP.
• For Interactivity: First Input Delay, FID. To be replaced by Interaction to Next Paint, INP, in March 2024.
• For Visual Stability: Cumulative Layout Shift, CLS

Let's take a look at the ones we didn't talk about: FID and INP.

First Input Delay - FID

The following are two internal dialogs of a website user:

"Tried clicking on the first sleek-looking running shoes, but it's like the website is stuck in slow motion. Come on, I'm ready to make a purchase here!"

"Ah, finally found a match! Clicking on those sleek grey shoes, they load immediately, showing me the available sizes without any delay. It's great to see such responsiveness."

• FID measures the waiting time from your first interaction on a website to the moment the browser can process it and respond.
• Think clicking on a button, on a link, or some other website User Interface (UI) element.
• Think of it as your first impression of a website's responsiveness.
• Only the first user interaction is recorded, the next interactions don't count.
• Other users may not click on the same first UI element as you. They will get different FID scores.
• Google will aggregate all the scores and report a single, unified score.
• The lower the score, the better. A good FID experience is an FID score of 100ms or less.
• Interaction to Next Paint INP will supersede FID in the Core Web Vitals. I mean the interactivity metric of interest will be Interaction to Next Paint as of March 2024. More on this later.

Interaction to Next Paint - INP

The following are two internal dialogs of a website user:

"Man! I've been browsing this shoe collection, and every time I click on a different model, there's this annoying delay before anything happens. It's really testing my patience to have to wait so much!"

"Wow, this is impressive! Each time I click on a shoe model, the website instantly refreshes, showing me the product details and color options without any hesitation. It's like the website is keeping up with my every move, making shopping a breeze.""

INP measures the time it takes a web page to respond to user interactions. This is from when the user starts the interaction until the moment the next frame is 'painted' on the screen. Or simply, until you see the result of your interaction on screen. Say you click on a button and something appears on the screen.

• A good INP experience is where the score is 200ms or less.

You say this is no different than First Input Delay? I hear you!

So how are these two different?

INP vs FID - In Layman's terms

• INP accounts for ALL interactions you have on a webpage. From the moment you land on the page to when you leave or switch to another browser tab.
• Think of all the buttons clicked, any links visited, and any UI element you interacted with. Anywhere on the page, at the top, in the middle, and at the bottom. At any time during your stay.
• The longest delay experienced with any one of the interactions gets reported as the INP value.
• The lower the value, the better. 200ms or less for that one 'bad' interaction is considered good.
• As the name suggests, FID accounts for only the FIRST interaction you will have on the page.
• FID only reports time delays from the moment you interact (click etc.) to when the browser is free and able to respond. This does not mean that it has displayed ('painted') something on screen yet. Only that it can now process your input.
• INP accounts for the extra rendering time.
• Remember the concept of 'tasks' and 'blocking the main thread'? FID accounts for only until the 'main thread' is freed. INP, until the job is done.

INP vs FID - Government counter analogy again

A good analogy to understand the difference between FID and INP is getting paperwork done at a government facility. Think, in the olden days before everything got automated.

So, you had to get in a few different queues to get all your paperwork done. There was no ticketing system. You had to stand in line, waiting for your turn.

FID would be the time you take in the first queue you get in.

Out of all the queues, which one takes the longest? That's your INP.

FID will only measure the delay from when you enter the first queue to when you reach the counter. This is the 'able to respond' part of FID's definition.

INP will account for the time you take to clear the counter. The 'painting the screen' part of INP's definition.

A good INP score means that all interactions were fast and consistent. Every queue you got in moved fast and you did not experience any delay in clearing each counter. This means you also got out of the facility in a breeze, with your paperwork done.

A good FID score would mean the first counter was fast. It will not consider the other queues. They could be slow.

Even from these simple explanations, you can see that INP is a superior metric.

Some things

• Earlier we said Core Web Vitals metrics can evolve as we discover better ways to measure experience. This is exactly the case with INP replacing FID. They both measure interactivity. FID looks at the first impressions only. INP is a more recent metric which tries to paint a better picture of the whole interaction. INP is thus superior.
• It seems Lighthouse and CWV use almost the same metrics? LCP and CLS are used in both. Only FID/INP vs Total Blocking Time are different. So, what separates CWV and Lighthouse?

We are getting closer to an answer to the question we started with.

What sets Core Web Vitals apart from Lighthouse?

If you have followed along, you have noticed that Core Web Vitals and Lighthouse are similar in two metrics (LCP and CLS). Only the third metric (FID/INP vs TBT) is not the same.

So there are similar metrics, but there are different data collection methods. Even for the same metrics.

• CWV focus on real-world data. Lighthouse works in a tight, controlled environment.
• Real user experience data is more valuable than lab data
• Lab data does not account for caching
• Core Web Vitals impact SEO

CWV focus on real-world data. Lighthouse works in a tight, controlled environment.

• Core Web Vitals collect and report what real users experience when they browse websites. They capture the variability of different user conditions. We call this field data.
• Lighthouse relies on standardized rules and automated tests with no real user. This produces consistent results, called lab data.
• Lab data cannot accurately replicate the variability of real user experiences.
• For example, display sizes and resolutions vary among mobile phones. This means different 'above-the-fold' contents and LCP images. So this can affect CWV but not Lighthouse scores.
• This shows that LCP scores in lab tests can differ from what real users experience.

Real user experience data is more valuable than lab data

There is great variability in real life when users are browsing a website:

• Network strength.
• Device variability (screen sizes, resolutions, device processing power...).
• Geographical locations.
• The different ways in which users interact with a website: scrolling, tapping on the screen, or selecting text, the random nature of user interactions... A user may choose to scroll down on the page and only interact with something near the bottom. This is not accounted for in lab settings. Metrics results will be different. (Note that scrolling is not counted as an interaction, as far as INP is concerned).

Lab metrics cannot accurately depict real user behaviour:

• I said earlier that Total Blocking Time can only be a proxy for First Input Delay and Interaction to Next Paint.
• TBT measures how long the main browser thread is blocked. The intended aim is to predict responsiveness when a user chooses to interact. This assumption can fall flat.

Responsiveness depends on how fast the browser downloads and processes script code. This correlates with TBT, FID, and INP.

There are stores with very high TBT, in the red zones. But FID is within range. We know that FID measures the responsiveness of the first user interaction.

What if the user is sufficiently patient to wait until all code scripts have loaded and processed?

Of course, this will be unintentional. There is no way someone is thinking: "Hey I'm just going to wait until everything has loaded perfectly". If they are patient enough, there is little chance they will experience unresponsiveness. FID will be very low, probably within acceptable ranges. Even if TBT is bonkers.

So, if we only optimize for lab data, it is more likely we are 'improving' the wrong things. This can hurt sales. Real user experience data is more valuable.

Lab data does not account for caching

Caching improves performance in the real world. Caching is like storing multiple versions of a website for speedy access.

This is done:

• In your browser. Your browser can store 'old' versions of a web page you visited. If you get on that webpage again, you will only need to download information which has changed since your last visit. If nothing has changed, nothing new gets downloaded. Loading is almost instantaneous. You can see how this improves performance.
• By storing your website on many disparate servers around the world. This means that your website is not on a single 'computer'. You may have copies of your website on 'computers' in the USA, in Europe, or in any other geographical location. The result is that a customer far away from you can have relatively fast access to your website. We call this concept Content Delivery Network, CDN. I only grazed the surface here. CDNs help with speed and caching in many more ways than this simple example.
• By other methods such as BFcache, Accelerated Mobile Pages (AMP)... etc.

Caching improves performance metrics. Lab data cannot account for caching.

Sidenote about Shopify CDN

Shopify has its own CDN 'network', built on top of Cloudflare CDN. All your store assets (images, videos...) are hosted on Shopify CDN. So your customers are already getting the benefit of a CDN. You just need to make sure you are using the 'assets' folder.

Core Web Vitals impact SEO

• Great Core Web Vitals scores mean great user experience. Great user experience increases conversion rates and drives more sales.
• It is thus natural that sites with great user experience get favored more in rankings.

Takeaway

All this means we cannot trust Lighthouse scores for web performance. Lab data doesn't show real user experience well. So, we cannot the make user experience better through it.

The drawbacks of over-reliance on lab data - Why Shopify adopted CWV

We know that lab data doesn't show how real people use websites accurately.

Over-relying on lab data can even backfire:

• Lighthouse scores look good when websites have strict structures and content. If we design our websites to fit these lab conditions, that might not work out well in real life.
• Focusing too much on strict structures and content can make the user experience worse. Trying to boost Lighthouse scores artificially can even harm the website.
• One number cannot tell us everything about how fast a website is and how good it is for people. To truly understand how well a website is doing, we need to observe what real people do on it over time.
• Google's research shows that users care about how fast a page loads, how stable it looks, and how easy it is to use. A single 'Speed Score' from a lab cannot capture all of this.
• Core Web Vitals (LCP, CLS, FID -> INP) are how we get an accurate picture of web performance. And they are an ongoing research.

These are some reasons why Shopify dropped Lighthouse performance scores and adopted Core Web Vitals.

With all this knowledge under our belt, we are ready to answer our starting question.

Why the new Shopify "Web Performance" scores seem better than the old "Speed Scores"?

Quick store dashboard comparisons again, to refresh our memory:

The Web Performance Dashboard shows real-world data captured through Real User Monitoring. This data is depicted as the current Google Core Web Vitals metrics (LCP, CLS, FID/INP).

Why does it look like things got better without a clear reason?

It depends on where most of your store's visitors are coming from - your customer demographics

Shopify will get the RUM data from these users.

Suppose most of your customers come from geographical locations with fast internet speed. And suppose they have decent mobile devices. Factor in caching and CDNs etc... They will likely have a good web experience on your store. This is even if your store is not optimized to a T.

Interpretation:

• A store has bad Lighthouse scores, but its customer base is in the USA. It means they have fast internet and good devices. The store's Core Web Vitals will likely be good. Better than what Lighthouse may be projecting.
• Now, let's flip this on its head and assume the customer base is in another region with slower internet. Or the store is expanding to customers in such regions. Here, assuming the website did not change, CWV is definitely going to be worse.

Why our store's Core Web Vitals trump Lighthouse scores?

The store's primary location is in the EU. I dug through the store's analytics data. I found that most of its customers are in the USA. More or less everyone is on iPhones or similar spec devices.

Fast internet, good devices.

It's not a surprise then, that Core Web Vitals paint a different picture than Lighthouse.

To drive this point home, I will show you that a 'perfectly' optimized store can have bad lighthouse scores.

Core Web Vitals don't have to match up with Lighthouse (Web Performance vs. Speed Score)

I will use the example of Carpe Diem's Shopify store, mycarpe.com.

This store is a case study in making Shopify websites faster by the Shopify Performance team.

Think of them like the 'task force' working on making Shopify websites faster. They introduced a cool feature where images below the fold load only when you scroll down ("lazy-loading"). This means we don't need extra tools like the LazySizes JavaScript library to do this. Less extra stuff means faster performance.

Now, back to this store. The Shopify Performance team's work made Carpe's website load faster by 52% and look more stable by 41%. LCP and CLS. Because of this, more people visited the site (up by 10%), more people converted (up by 5%), and the store made more money (up by 15%). All by just making the Core Web Vitals better. You can read about it here.

This store should have stellar web speed scores! Let's boot up PageSpeedInsights for this store to verify:

Core Web Vitals

All Core Web Vital metrics are in the clear, as expected. The control parameters (1-6) demonstrate real-world, real-user variability.

Lighthouse Score

This is where it gets interesting. This "Performance" Score was so unexpected! Why does a well-optimized store have such poor Lighthouse results?

This is how Lighthouse's strict rules show their limits.

Let us compare CWV vs Lighthouse parameters, then.

Side-by-side parameters comparison - CWV vs Lighthouse

If you take a look at the "Interpretation" column, there is no question that Core Web Vitals are superior. This settles the score.

But what do you need to do about your own store's performance report? Let's find out.

Do you need to do anything about your store's Web Performance reports?

Your store may have an 'automatic' performance boost with the new dashboard. Even so, there may be room for improvement.

Your Web Performance dashboard will show you which metrics need your attention.

Your analytics data will give you insights about your real users.

Your Google Search Console dashboard will guide you on which store pages you need to act.

As a general rule, it is a good idea to work on your site's web performance. Better performance equals more sales. Pay more attention to real-world metrics (LCP, CLS, FID/INP) over lab scores. Understand your analytics data to understand your users better. Use Google Search Console to zero in on the pages which require improvement.

How the performance metrics are rated

The web performance metrics are rated 'Good', 'Moderate', and 'Poor'. Each metric has its own set of thresholds:

What should you do about your ratings?

If you have any metric rated "Moderate" or "Poor", you can work on them and could see your sales go up.

• If all 3 Core Web Vitals are "Good", congratulations! Your site has top-notch performance. Keep monitoring your scores over time. Dig into your analytics data to know about your user demographics and tech. These may change over time as your store grows. Your Web Performance could suffer.
• You have "Good" scores currently. But plan to expand your store reach in regions with weaker internet? Pay attention to your scores over time. Be on the lookout for drops in performance as more users from these regions enter the fray.
• If you have a local customer base with slow internet? And you're not planning to expand, for now? Like your local town or a small market like Mauritius? Focus on making your website easier to use first. Some local online stores have confusing layouts, missing images, broken links, etc... They lack an 'About us' page. There is no clear shipping information... Try to make your store seem trustworthy too. Customers can forgive slow performance if a store is simple to use and seems trustworthy. But good performance still makes for a better experience. So, once you fix any issues with how your website looks and works, work on making it faster too.
• If you don't have "Good" ratings on any metric? Start by fixing your homepage, collections page, and top-selling product page. Or, use Google Search Console to find out which pages have issues. Then, use Google PageSpeedInsights to get suggestions for them. If you're not sure how to do it, ask an expert for help. You can also reach out to me if you need assistance—I'm happy to help.
• If you had "Good" ratings but they start to plummet out of the blue? Look at the Web Performance time series graphs. Access them by clicking on the metric name. Try to pinpoint the exact moment (day, time) this started. Then try to see if you can match this to some sort of event. App installs, app uninstalls, theme updates, live theme changes... etc. The time series will even show some of these events. You will know the likely cause of the dip.

• If you think you don't have enough performance data, take a look at the "What if you don't have web performance data?" section.

How to use your analytics data to gain insights about your customers

But first, why do you need analytics data, from a web performance standpoint?

Analytics data will show you where your real users are from.

• Think geography demographics. Country, region, state, town...
• This will give you an idea about relative internet speeds. There is a direct correlation between performance issues and network speed.
• Slow networks can amplify performance woes. Good networks cushion the impact of an unoptimized website.

Analytics data tells you what devices and platforms your customers use. We call this "tech" data.

• Device categories (mobile vs desktop vs tablet), operating systems (IOS, Android, Windows), browsers, screen resolutions... You will get it all.

Why bother about tech data?

• Platform and device features can have an impact on web performance. A current trend is that more people are buying from their mobile devices than ever. Your analytics will definitely show this.

• You will be amazed that some store owners still miss this point. I spoke to an owner about performance some time back in 2023. Because he was managing his store on a laptop, he never paid attention to mobile performance. When I popped up his analytics data, he was astonished that mobile brought in more than 75% of total revenue. So you need to be more careful about performance on mobile devices, i.e. phones.
• Screen size and device resolutions can influence performance. The part of a webpage you see without scrolling is called 'above-the-fold' content. It looks different depending on the size and resolution of your device. What you see on a Full HD desktop is different from what you see on a tablet, a big phone, or a small phone. This could mean that the LCP image is different depending on these factors. Or the thing that moves around the page might not be seen right away on a smaller phone screen. Optimise accordingly.

With this little intro out of the way, let's see how to access the analytics data.

Google Analytics 4 demographics data for our sample store

To access these reports:

GA4 Home -> Reports -> User -> User Attributes -> Overview

GA4 Home -> Reports -> User -> User Attributes -> Demographic details

Google Analytics 4 tech data for our sample store.

To access these reports:

GA4 Home -> Reports -> User -> Tech -> Overview

GA4 Home -> Reports -> User -> Tech -> Tech details [Filter: Device Model, Device Brand]

GA4 Home -> Reports -> User -> Tech -> Tech details [Filter: Device model, Screen resolution]

So now you know how to use your analytics data to get details relevant to web performance.

Next, let us see how we can use Google Search Console to know which store pages are lacking.

How to use Google Search Console to zero in on which store pages demand your attention

If your store has lots of different product templates or many pages, it can be hard to know why it's slow. Which specific pages should you optimise?

Fear not. Add your store to Google Search Console and find the URLs that are causing problems. It's easy. Give it enough time to collect data.

Search Console can also help if your store pages aren't showing up right on Google Search. Changed a product description but it hasn't updated on Google yet? Ask for it to be re-indexed in Search Console.

So here's how we get to the page issues

I put the details below each screenshot.

• Open your Search Console Dashboard, click on Core Web Vitals (1), then open the mobile Report (2).

• You will see a time series almost identical to the one in the Shopify dashboard. The difference is that Search Console will actually give you the bad URLs. And some explanations. Look at the bottom of this page.
• (Caveat: you must have sufficient traffic. Else Search Console will show a "No data available" screen. If so, check the last section of this article)

• Click the issue name in the "Issue" column to reveal the next page. Also, pay attention to the "Validation" column and "Not Started" value. We'll come back to these later.

• At the bottom here, you will find URL groups with the LCP issues, in this store's case. Notice here that we have collections and product pages.
• Click on each example URL to reveal specific URLS for each group. This is handy if you have a lot of alternate product pages.

• If you click the Example URLS, you will get a list of specific URLs with issues. For this store, we have many product page templates with sub-optimal performance.
• Now if you click the hamburger menu, you get even more!

• You have the possibility of even initiating a PageSpeedInsight request to see exactly where the page is failing! Neat isn't it?
• So you fix the page issues or get someone to do it. Then you can "Validate" the fix in Search Console:

• If Google finds that the issue is fixed, it will remove the URL/s from the "Why URLs aren't considered good" groups.

You can find more about the Google Search Console performance reports here.

So now you know where to find your troublesome pages. But what if you don't have enough data in Google Search Console?

What if you don't have web performance data? Try to increase traffic first

If you don't have enough traffic, Google Search Console will show a "No data available" screen. This can happen if your store is new.

Shopify's Web Performance dashboard will probably show blank streaks. You can try to group the data by week or month. This can help in some cases:

It is pointless to want to improve your store performance if you don't have enough traffic. If you don't have enough traffic, you don't have enough real users. If you don't have enough real users, you won't know what issues real users are facing. If you don't know which issues to fix, well, why bother, for now?

So get your marketing strategy and social media content game going. Engage with your audience on your socials. Fix your ads if you aren't getting good ROAS. Add a blog on your store and post it to your socials if you need to. Do anything to get more traffic. And don't forget to fix any glaring UI/UX issues on your store website. They could be hurting your conversions.

When you start getting at least 90-100 daily visits, it's finally time to dig into those intriguing web performance numbers.

Finally...

We've come to the end of this long guide! You have my thanks if you made it all the way through! You are a tough one!

I hope you got some value from this guide and will use it to improve your store.

A quick recap of what you learned:

• The old Shopify Online Store Speed and how it was calculated.
• What makes up the 2024 Shopify Web Performance Dashboard.
• Why Shopify made the change.
• What matters when evaluating Web Performance and how to measure it.
• What performance metrics are. Lighthouse performance scores, Google Core Web Vitals, and the tooling for metrics. Analogies to help understand metrics in a simple way.
• How we collect metrics data, real user data vs lab data, the misalignment between the two.
• In-depth guide on Google Core Web Vitals and why they are superior.
• How does all this tie into the new dashboard.
• Why web performance scores seem better than online store speed.
• Do you need to do anything about your own store's performance data?
• What you can do to improve your web performance: data, analytics, tools, action steps.
• What to do if you don't have enough real user data.

If you liked this article and want more stuff like this, give me a follow on LinkedIn.

If you know someone who might benefit from this article, share it with them.

If you want to share feedback with me or ask me a question? Just DM me.

Until next time!

Photo credits

Cover photo by Chris Liverani on Unsplash

* Photo by Alex Kondratiev on Unsplash

** The metrics threshold images are from Google web.dev. Edited for clarity.