- What does Web Vitals provide?
Essential metrics for a healthy site
Google introduced Core Web Vitals to help you gain real life insight in how your users experience your website or webshop by:
- Loading time: how long do your users have to wait until they see something on your website;
- Interactivity: how long until your users can do something on your website;
- Visual stability: will the website they see be stable, or shift while loading.
- Better loading time
Improving Largest Contentful Paint
LCP reports the render time of the largest image or text block visible within the viewport of your webshop or site. This could be your main product image.
- A LCP lower then 2.5 seconds, means your website has a good loading score.
- A fast LCP helps reassure the user that the page is useful, thus lowering the bounce-rate.
- I help you and your team with a strategy that will lower your LCP.
- Faster Interactivity
First Input Delay
The FID metric measures your users first impression of the interactivity and responsiveness within your website or webshop.
- An optimal FID User Experience is lower then 100ms;
- More visual stability
Cumulative Layout Shift
Every unexpected layout shift that occurs while your user is interacting on your webshop page, is measured by the CLS metric.
- You should aim for your CLS to be lower then 10%;
- This will ensure that your users will not start reading - or worse clicking- something that will shift later;
- I will help you to prevent users getting frustrated and bounce due to layout-shifts and lead your e-commerce to increased conversion.
We found that when a site meets the above thresholds, users are 24% less likely to abandon page loadsGoogle / Chromium
- Erwin Hofman is happy to help
Start making your website faster
Are you interested in improving or passing Google's Core Web Vitals assessment as part of your pagespeed or CRO strategy? I know I am as on top of impacting conversion, Core Web Vitals will become a ranking factor in 2021.
Frequently asked questions
As real user experience data as saved within CrUX report, most data is for free. You could check out the Core Web Vitals section within your Google Search Console, you could use Core Web Vitals, the free CrUX setup or you could query BigQuery yourself.
Do note that you will only see data when your website or webshop has sufficient visitors. Ready to monitor and optimize? Get your CrUX report for free.
Compaired to Pingdom tools or GTmetrix, PageSpeed Insights is the better performance testing tool. On top of technical recommendations, PageSpeed Insights will also give you insights into the impact on user experience via their six metrics. See also Why you should use PageSpeed Insights, instead of GTmetrix or Pingdom.
The easiest way to determine of your site or shop is passing the Core Web Vitals is by using Google's PageSpeed Insights. In case of sufficient data, you will see one of the following statements about your specific page URL or origin on passing the Core Web Vitals metrics:
- field data shows that this page passes the Core Web Vitals assessment;
- field data shows that this page does not pass the Core Web Vitals assessment;
It will be a ranking factor in 2021. Obviously, it will already impact conversion based on Google researches.
At the same time, pages that are passing the Core Web Vitals assessment will also see their chances increase of become part of the Google Top Stories. Having AMP pages isn't the only requirement anymore, passing Core Web Vitals will do the job as well.
Chromium is always busy improving and catering to optimal user experience. They are experimenting with different types of fast page labelling. Passing the Core Web Vitals assessment might yield more benefits in the future as well. For example, reduced pay-per-click (PPC) costs.
The Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) are new, as we already had the First Contentful Paint (FCP) metric within previous PageSpeed Insights and thus Lighthouse versions.
Other metrics such as First Meaningful Paint (FMP) or Time to Interactive (TTI) didn't tell a story about the first and thus early user engagement. Moreover, third parties that would impact TTI could be loaded without massively impacting the user experience.
At the same time, the web kept growing, impacting UX even more, despite the existing metrics. This is where Cumulative Layout Shift (CLS) comes in, ranking the layout stability while visiting a webpage. First Meaningful Paint wasn't reliable metric as a test could not figure out which elements really were meaningful. This is why FMP got replaced by Largest Contentful Paint.
This is very much possible. It is already being sad that animation performance could become part of the Core Web Vitals, as bad animation performance which takes place on the CPU of your device, could impact user experience, depending on other (busy) tasks that are executed by the browser.
However, Google stated that no more than one metric per year will be replaced or introduced.
Chrome isn't being mysterious about the metrics which are part of the Web Vitals, nor about how they are measured and changed. You can find any changes of metrics as well as per metric via their Web Vitals Changelogs.
It is about "Field data". This means that:
- Core Web Vitals is about real users, out in the field;
- Chrome UX Report (CrUX) is forged from data collected via Chrome, directly from its users browsing the web;
- It is about performance data from your very own traffic, amongst Chrome users only.
Chromium users have their experiences tracked during a page visit. Once a visitor leaves the page, for example clicking to another page, Google will send the performance and UX metrics to their own servers. This is better known as the Chrome User Experience (CrUX) report.
All Chromium users (nowadays even Microsoft Edge users) have their data send to Google / CrUX. This means most real user experiences of Apple / iOS users might not be send to Google servers, as they often use Safari and Linux users might use FireFox.
Do note that users can opt-out from this setting and stop their browser from sending their experiences and thus UX and pagespeed metrics to Google servers.
Nobody knows. Tests I conducted in the past pointed out that a page needs around 1,000 visitors a day, per page. When a site doesn't have enough visitors, changes are you need to find other ways to rank higher. Do note: improved pagespeed will still impact conversion positively, no matter the amount of visitors or passing the Core Web Vitals assessment.
When doing a PageSpeed Insights test, you will always see "Lab data". "Field data", sitting on top of "Lab data", will be displayed as well. When you don't see any coloured bar charts, your webpage didn't have sufficient visitors (yet) to yield any data.
However, if your origin (domain) did have enough visitors to yield a summary, PageSpeed Insights might at least still show you an origin summary. When no "Field data" at all is being displayed, your website or webshop doesn't have enough visitors and you won't benefit from Core Web Vitals ranking factor. Do note though that improving your pagespeed, performance and UX will still impact conversion and might make you future proof in case the amount of visitors increase over time.
Hopefully, you’ll have enough traffic to get some data to see Field data within PageSpeed Insights, Google Search Console and CrUX.If not, you can still track the Core Web Vitals of your visitors and store it where ever you want. For example to Google Analytics or via Google Tag Manager. GoogleChrome published a library, including code examples on github.
For each metric, visitors should have an experience below the following boundaries:
- Largest Contentful Paint should be below 2.5 seconds;
- First Input Delay should be below 100 milliseconds;
- Cumulative Layout Shift should be below 10% (0.1).
To create the three buckets, being green for good experience, orange for needing improvement and red for poor experience, Google looked at their very own CrUX data as well as user experience researches to come up with a threshold or bucket distribution. They also analyzed what the percentage of different amount of (in case of the LCP) seconds was. See also Defining the Core Web Vitals on web.dev website.
Luckily: no. There might always be visitors under really poor circumstances, when it comes to device capabilities and internet connectivity. For example when having an international website or webshop, users may come from different regions, working with different budgets and thus different smartphone devices.
As a result, at least 75% of visitors should have an experience within the three metric boundaries to be able to pass the Core Web Vitals. To put it mathematically: the 75th percentile of the data of each metrics, should be within the green thresholds.
Although PageSpeed Insights was using the 50th percentile (being the median) when using Lighthouse v4, Google changed this to the the 75th percentile over time to make sure that pages work well for the majority of users. By focusing on 75th percentile values for our metrics, it is ensured that pages provide a good user experience under the most difficult device and network conditions and developers can understand the most frustrating user experiences on their site
Google did use a higher percentile (90th percentile) for a short amount of time for some metrics. However, as faster websites and webshops are likely to increasingly attract more users under more difficult conditions, this could skew the data too fast. As a result, the 75th percentile is being used so data will not be overly impacted by outliers.
Passing Web Vitals
The short answer is: no you don't. Well, at least not necessarily to pass the Core Web Vitals. This is because the Core Web Vitals will get their data from real user experiences. As a result, the circumstances of your visitors play an important role as well, while the overall PageSpeed score might give you a general impression of your performance and UX hygiene.
Although PageSpeed Insights might show you four metrics, these three are part of the Core Web Vitals:
- Largest Contentful Paint;
- First Input Delay;
- Cumulative Layout Shift.
To pass the Core Web Vitals assessment, users should have an optimal experience for each given metric.
The above means First Contentful Paint isn't part of the Core Web Vitals. Do note that an optimal First Contentful Paint will trigger early user engagement, so don't forget to optimize this metric as well.
Considering you do see data and charts in the Field data section when using PageSpeed Insights, it is just showing you a summary of the last 28 days. This means, optimizing today isn't enough to skew or impact the data of the other 27 days which might still take the bad experiences into account.
To get an optimal sense of the impact of your changes on the real user experience amongst your visitors, check again in 28 days since optimizing speed / UX.
The Field data and thus Core Web Vitals data of real user experience as shown within PageSpeed Insights, is covering data of the last 28 days. As technical optimizations might only become noticeable after 28 new days, chances are it will take at around 28 days.
When Core Web Vitals metrics are already close to the thresholds as set by Google, you might see your webpages or website passing the Core Web Vitals even earlier. Although at time of writing it isn't clear yet how long it takes for Google to impact the SERP's, chances are it will be quite instant, as soon as your webpages or website is passing the Core Web Vitals assessment.
It totally depends on your target audience and ambitions. Fast webpages with optimal UX on top of it will allow more users to find and digest your content, causing an increasement in visitors. As this could also allow more visitors under difficult device and network conditions, this could change your averages as well as percentiles.
Besides change in type of users, chances are your website or webshop will grow as well, serving more resources with new risks of impacting the Core Web Vitals metrics. In other words, keep monitoring.
Ranking also depends on the quality of your content, how your competitors are doing, et cetera. At the end, Core Web Vitals is just one of the many ranking factors of which Google won't tell us how it is used in their algorithms. Maybe your competitors are also doing a great job when it comes to pagespeed and UX, or they have better content quality.
CLS stands for Cumulative Layout Shift, meaning that shifts are happening during a pagevisit. Ads that are lazily loaded, might push other content down. This will impact user experience, as users have to reorient while reading. As Google knows this will impact UX and thus bounce, CLS has become a ranking factor.
To give an idea of CLS, the following could impact layout shifts:
- Images without dimensions or without a fixed parent;
- Ads, iframes that are being inserted or loaded;
- Dynamically inserting new elements and content on the fly (client side rendering);
- Web fonts, changing characteristics of the text in regards of line-height, letter-spacing and letter-width.
Google already tracked Largest Contentful Paint (LCP) data way before it became part of PageSpeed Insights or Core Web Vitals. The latter happened on May 27th, while LCP data of real users is already being tracked since at least september 2019.
In contrary to its predecessor, the First Meaningful Paint (FMP) metric, the LCP is telling a better story about the (possibly) most important element within the viewport. Possibly, as other content could still be more meaningful, but compaired to the FMP, it is clearer which element we are talking about when it comes to user engagement and tracking meaningful paints in general.
To give an idea of LCP, the following could impact the largest contentful paint:
- Bad hosting or a heavy CMS, for example with quite a few plugins, are more likely to result in a higher server response time and thus TTFB metric. As a results, the browser will receive the HTML later in time, and thus the LCP will be shifted back as well;
- Render as well as parse blocking resources will prevent the browser to parse and render the HTML containing the largest element late in time;
- Slow resources, such as resources responsible for the largest elements but served with quite some network latency, will start later in the process;
- Not serving responsive and thus smaller images, for example on product detail pages or hero images on article pages;
- Client side rendering when this is delaying the layout and composition of the largest element within the viewport.
The timedelay between the (first) moment of user interaction and the moment the browser was able to respond to the user interaction, is encapsulated in the First Input Delay (or FID) metric. Responses within 100ms are perceived as fast by the human eye. Slower response times on user interactions might be experiences as an unnatural delay, leading to distrust or user frustration.
To give an idea of FID, the following could impact the largest contentful paint:
Probably not in such way. Obviously you could create very lean pages for Google's PageSpeed Insights testing, resulting in optimal "Lab data". However, it is the "Field data" that counts towards Google ranking and you can't hack the devices and network conditions of your visitors. You could implement best practices though, helping your overall score as well as real users.
For example, you could choose to also serve lean pages to real visitors. This is more of a best practice than hacking though, as lean pages are good for real user experience, which eventually is the purpose of Core Web Vitals.
Some platforms need very specific knowledge and architecture, such as Magento. However, most hosting companies (especially within The Netherlands) are often doing a good job already. Due to CPU boundaries of smartphone devices, the frontend code as produced by platforms and developers play a bigger role. Moreover, Core Web Vitals really is about user experience instead of pagespeed, so it really is a matter of frontend coding.
Hosting might not be the number one bottleneck when not passing Core Web Vitals yet, but as the TTFB is the starting point of all, hosting shouldn't be overlooked.
When Chromium could collect sufficient visitor data for your website or webshop, you can consult the free CrUX reporting to view historical TTFB data and detect changes and patterns. For example, when LCP patterns are the same as TTFB patterns, chances are that TTFB is the main bottleneck, impacting the LCP as well.
It is quite likely that the platform your company is using as a webshop or website solution is making a difference. For example, some content management solution might request all hosted resources, even unused resources on specific pages. Other platforms might always insert resources in the head without any performance strategy in mind, creating render blocking resources.
As a result, some platforms will give your developers a harder time to pass the Core Web Vitals, but it is achievable, no matter the platform.
Although SaaS solutions are closed source and only allow for frontend changes using templates and other resources, it is still possible to optimize for Core Web Vitals. I once optimized a site where no server side changes could be made. In my case, this meant no HTTP/2 and no next-gen WebP images. Nevertheles, we scored a 95% on mobile and the website was passing the Core Web Vitals.
However, most agencies creating templates, often create them in the same way. As a result, same mistakes can be seen within the average SaaS webshop, such as Lightspeed, Shopify, BigCommerce. This is where the role of in-depth developers or consultants such as myself are playing an important role.
Some of your performance and UX issues could be fixed using plugins. This might introduce new anti-patterns though. For example:
- most plugins for inlining critical CSS often only include partial CSS, resulting in increased layout shifts;
Moreover, with every new plugin chances are that you are unwillingly and unwittingly increasing the server response time and thus TTFB, pushing back the LCP metric even further. So, when you do choose to fix issues with plugins, keep a close eye on the impact on real user experience and metrics.
As frontend architecture and thus HTML, CSS and JS are responsible for the work a browser has to do, this very same frontend code will have its influence on the metrics. As a result, your developers are the ones that will have to do the coding, where CRO or SEO specialist are often the ones pushing for optimization work.
Obviously, one platform will allow more room for improvements than other platforms, but your developers should still be capable of optimizing for improved Core Web Vitals and conversion.
Rather have the full insights? Read about PWA and its technical implications.