Web vitals

Hi,

I have some issue to understand, the web vitals section.

This value are different from the one provide by Lighthouse, seems normal because of the configuration of the tests. But I don’t understand how WPT get these ones.

Can you explain the procedure ?

Thanks.

David :rolleyes:

For those of you interested in learning more about core web vitals, here’s a brief rundown.

First, core web vitals were introduced back in may with a Google update, and display on Google pagespeed, lighthouse, and the search console. They currently (In July 2020) don’t impact search rankings, but in a few months they will, so it’s important that you take them seriously.

The general purpose of core web vitals are this: Google wants to ensure that they only display websites that offer a good user experience. Core web vitals are a quantitative way to measure the user experience on a website. the better your core web vitals are, the more “delightful” the user experience will be on your website (or at least that’s what Google thinks).

A good way to get an understanding of your core web vitals is to generate a page speed report for your website. If available, it will populate with real world data, which is classified as good, needs improvement, or poor. (Green is good while red is poor). three of the four real world data metrics are core web vitals, meaning that you need to get them right.

Each real-world data point measures one aspect of the core web vitals. Let’s quickly run through them, if you want to learn more about them in depth, read this article: [url=https://isotropic.co/what-are-core-web-vitals/]https://isotropic.co/what-are-core-web-vitals/[/url]

Largest contentful paint
This measures how long it takes for the largest content element to render on your website. Typically, the largest content element is a featured image or headline.

First input delay
FID Measures how long it takes for the browser to become responsive to user input. This normally has to do with JavaScript, so go ahead and optimize that JavaScript.

cumulative layout shift
Cumulative layout shift is the summation of all individual layout shifts that are not triggered by user input. A layout shift is something that causes content on the page to move. For example, if you click on a button and a menu pushes content down the page, that’s a layout shift.

However, that layout shift is good because it was toggled by the user.
On the other hand, if something randomly pops up pushing content around, that’s a bad layout shift because it wasn’t triggered by user interaction, and it will count towards your cumulative layout shift score.

It’s definitely important to get these right, and some of them have to do with the speed of your site, while others have to do with the actual design.

Isotropic I tested your website WebPageTest - Running web page performance and optimization tests...

So what am I missing?

Googlers John, Martin and Gary podcast including the topics related to Speed and Core Web Vitals which became an important ranking factor, and also major for user experience!

Excellent source to get started. And to be specific, listen starting at 00:10:57 to 00:18:56 mins: Search Off the Record: Pop filters, nofollow, Core Web Vitals, and more!

To learn more about those 3 topics:

  1. LCP Largest Contentful Paint (LCP) (Important)

  2. FID First Input Delay (FID) (More important)

  3. CLS Cumulative Layout Shift (CLS) (Most important)

Here is an example on Chrome Emulated Nexus 5 - 3G Fast Device (1.6 Mbps / 768 Kbps 150 ms RTT):
Test Screenshot: Screenshot by Lightshot

Live test example: WebPageTest - Running web page performance and optimization tests...

Side note: Speed Index Metric is Obsolete or OUTDATED!

Classifying Good, Needs Improvement, Poor: PageSpeed Insights API について  |  Google Developers

I use webpagetest as it is one of the best speed tool around, but I also use https://speedcurve.com/ which is an amazing help with identifying issues very well.

Hi David,

As others have pointed out, Web Vitals is a set of metrics. This can be measured by the actual WPT Chrome agent itself or by submitting a test to Google LightHouse tool. When you enable this option, WPT actually runs both the tests.

Since the tests are different and run from different machines and network conditions, you should see minor difference in the numbers.

The only case where you would see a huge difference is when you run a multi-step test. In this case, WPT will simulate a browser going from page 1 to page 2. Due to the navigation, browser may have cached JS, CSS, fonts and images. So the metrics would show lower value indicating the behavior of a real user clicking on a link and going to second page. However, Google LightHouse does not have this capability. Each test would be single page test and this will give you a higher number.

Here’s an example. I am using the following script to test 2 pages on Atlassian.com. I have hidden measurements on first page.

logData	0
navigate	https://www.atlassian.com/
logData	1
navigate	https://www.atlassian.com/software/jira

Here’s the WPT link: WebPageTest Test - WebPageTest Details

Here’s Lighthouse report:
https://webpagetest.org/lighthouse.php?test=200727_D2_02ab4dcea7065ed4f9bc8498b5d72420&run=1

If you notice, there is a huge difference between the results. FCP is 1.312s vs 6.3s on Lighthouse. Similarly, LCP is 4.17s vs 17.4s on LightHouse.

Hope this helps address your question.

Regards,
Akshay