You’ve checked your own Core Web Vitals data, your competitors data and ended up drawing the conclusion you’re lacking behind. Heck, even your foreignly relaunched webshop could be having different Core Web Vitals data. Despite running on the same boilerplate.
Lacking behind on performance
Someone that noticed they were lacking behind from performance perspective, is Wordress. That was the conclusion of Wordpress contributors, with the same outcome: time for more focus on performance.
Wordpress knew by checking public data from the Technology Report, where Core Web Vitals data meets HTTP Archive data.
Focus on Core Web Vitals
There are some challenges though when comparing one webshop (or website) with the other.
Let’s start with an important disclaimer: be sure to not only look at the Lighthouse score of you and your competitor. Core Web Vitals might be the better KPI here for non-technical stakeholders.
Why your pagespeed comparison might not be fair
But even then, differences in Core Web Vitals data might get you spooked. For example because your competitor is passing all metrics, while your shop is only passing the FID metric.
If so, then the following is likely to impact your Core Web Vitals outcomes:
- you are doing fully client side rendering instead of server side rendering, causing a browser to detect resources later in time;
- your audience is located in countries with slower internet;
- your shops does A/B testing using a client side solution;
- your products are cheaper, attracting more visitors with low-end devices;
- or, your product pages are getting more unique pageviews then successive pageviews.
You could wonder why all of these could individually be impacting your Core Web Vitals data. Imagine a non-lazyloaded hero image of product detail image. It’s likely it will become the LCP. And an LCP experience could easily be 3 seconds during a unique pageview and with a low-end device. Or within any other combination from the above list.
A successive pageview or a situation with optimal connectivity and device conditions could result in a 2 second LCP experience.
Core Web Vitals differences explained using numbers
Let’s use some numbers to compare situations. For the sake of simplicity, let’s pretend these experiences in seconds are 75th percentile mobile experiences. Afterall, the 75th percentile is the one that Google uses as well.
The result under poor condition
Then, if 80% of your audience consists of users within a combination of the above situations, than that means 80 times 3 second and 20 times 2 seconds LCP experience. End result:
- 80 * 3 = 240
- 20 * 2 = 20
That makes 260 / 100 = a 2.6 second LCP. That’s just above the 2.5 second threshold, meaning this webpage would not pass Core Web Vitals.
The result under optimal conditions
Let’s say your competitor is using a server side rendering strategy, with no A/B testing and having an mainly having an audience in more wealthy countries. And maybe having more successive pageviews. Then there result could be:
- 20 * 3 = 60
- 80 * 2 = 160
That makes 220 / 100 = 2.2 second LCP. Being well below 2.5 seconds, this page would then pass the Core Web Vitals assessment if other metrics would be green as well.
Conclusion
So, don’t feel victimized by Google’s Core Web Vitals ranking update. When your shop is ending up in the first group (poor conditions), then that apparently is what your audience exists of. And those are the ones you would want to optimize for.
Instead, see it as an omen to start optimizing. Preferably yesterday instead of tomorrow, as it has already been impacting your revenue the last months, or maybe even years. But be sure to do it for your users’ happiness, conversion and retention.
