The 202204 dataset is live

[❄ Johannes Henkel]

Hi CrUX users,

This is your monthly announcement that the latest dataset has been published to BigQuery. Yes, it’s a few days early because Google I/O is next week. :-)

The 202204 (April 2022) dataset is now available and it covers 8,602,902 origins, an increase of 0.6% over last month. Here’s a look at origins' Core Web Vitals performance this month:

• 55.2% of origins had good LCP

• 94.9% of origins had good FID

• 71.6% of origins had good CLS

• 41.2% of origins had good LCP, FID, and CLS

With this release, we’re including experimental.interaction_to_next_paint (INP), a new version of the responsiveness metric. The main difference compared to the previously published experimental.responsiveness metric which we discussed at web.dev/responsiveness and web.dev/better-responsiveness-metric, is that INP no longer uses budgets for each interaction. More documentation will soon be available, and you may also be interested in this Google I/O talk.

We’re also releasing INP as experimental_interaction_to_next_paint in the CrUX API. The thresholds for differentiating between “good”, “needs improvement”, and “poor” are 200ms and 500ms. These differ from the First Input Delay (FID) thresholds of 100ms and 300ms because INP captures the total event duration, not just the delay.

This query shows how to get the good, needs improvement, and poor assessments for experimental.interaction_to_next_paint in BigQuery:

SELECT

 SUM(IF(inp.end <= 200, inp.density, 0)) AS good_inp,

 SUM(IF(inp.end > 200 AND inp.end <= 500, inp.density, 0)) AS ni_inp,

 SUM(IF(inp.end > 500, inp.density, 0)) AS poor_inp

FROM

 `chrome-ux-report.all.202204`,

 UNNEST(experimental.interaction_to_next_paint.histogram.bin) AS inp

WHERE

 origin = 'https://developers.google.com'

Last but not least, we’re releasing experimental_time_to_first_byte in the CrUX API; you already know this metric from BigQuery as experimental.time_to_first_byte; it’s useful as a diagnostic to differentiate server latency from client latency. The new thresholds in the API and on BigQuery are 800ms and 1800ms.

If you have any questions about CrUX, feel free to reach out to us on any of these channels:

• chrome-ux-report on Google Groups

• @ChromeUXReport on Twitter

• questions tagged with chrome-ux-report on StackOverflow

• GoogleChrome/CrUX on GitHub

Cheers,

Johannes.

[Rick Viscomi]

Hi Sean,

Both are valid approaches, but one advantage to using `end` for the threshold is that you can write it as "less than or equals" which is more consistent with the way thresholds are typically written for metrics in the Web Vitals program.

For example in web.dev/inp, the definition of good INP is described as: "an INP below or at 200 milliseconds means that your page has good responsiveness." And the corresponding implementation in the example query is SUM(IF(inp.end <= 200, inp.density, 0)) AS good_inp.

Rick

On Wed, Jun 22, 2022 at 1:57 AM sean martheze <sean.m...@digioutsource.com> wrote:

Hello,

Thank you for providing insights into the new interaction to next paint.

I have a question regarding the example query provided….

In all examples and in the queries on BigQuery they set the thresholds using bin.start, I see that this example provided is using end and not start is there a reason for this or is it a mistake?

Thanks,

Sean

--
You received this message because you are subscribed to the Google Groups "Chrome UX Report (Discussions)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-ux-repo...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chrome-ux-report/579dd1ec-fff8-4318-9f96-593cdad056aen%40chromium.org.