Potential INP bug with external links

92 views
Skip to first unread message

Dave Smart

unread,
May 12, 2022, 6:06:15 AMMay 12
to web-vitals-feedback
This could well be a misunderstanding on my part

Links with target="_blank" seem to cause INP to be the time until you come back to that tab by either closing the new tab, or clicking back to the tab, when measured by the JavaScript example given on https://web.dev/inp/

Test case page here: https://testing.tamethebots.com/inpbug/ (I've added the JS to the page so you can see it on page, and in the console)

a random target like target="_GOOG"  seems to mostly behave as expected (I did spot a high INP sometimes) 

target="_new" or target="new" always seems to return as expected. From my understanding this should really be no different to target="_GOOG" so perhaps it's just that I didn't happen to spot the occasional high INP whilst testing?

But the _blank one seems consistently high, and doesn't seem to be measuring what I'd expect.

Tested in Canary Chrome on Windows 10, and canary chrome on Android.

But perhaps I'm misunderstanding something here? 


Michal Mocny

unread,
May 12, 2022, 7:25:50 AMMay 12
to Dave Smart, web-vitals-feedback
Thank you for taking interest and the excellent report!


It is only affecting the event timing API, so the web exposed value that the web-vitals.js and chrome extension and other RUM depend on... But it won't affect CrUX values.

I agree this is fairly unfortunate and we'll work to fix soon.

There are a few other edge case timing issues like this, if you find more, that's really valuable for us.

Best of luck!

-Michal 

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/220b3b04-8682-4106-a20e-e5f323f43480n%40googlegroups.com.

Dave Smart

unread,
May 12, 2022, 8:16:33 AMMay 12
to web-vitals-feedback
Hey Michal,

Thanks for the lightening fast reply, good to know it's known about and only the event timing API!

Will surely report anything odd I spot ongoing.

Really impresses with the metric overall though, it's already allowed me to spot and amend some less than stellar interactions on a couple of sites I've been collecting this metric for for the past few days, much more nuanced and truer (bug aside) to the actual experience a user has on a page.

Michal Mocny

unread,
May 12, 2022, 9:14:46 AMMay 12
to Dave Smart, web-vitals-feedback


On Thu., May 12, 2022, 08:16 Dave Smart, <dsmart...@gmail.com> wrote:
Hey Michal,

Thanks for the lightening fast reply, good to know it's known about and only the event timing API!

Will surely report anything odd I spot ongoing.

Really impresses with the metric overall though, it's already allowed me to spot and amend some less than stellar interactions on a couple of sites I've been collecting this metric for for the past few days, much more nuanced and truer (bug aside) to the actual experience a user has on a page.

Thank you for that! It's an exciting time for us and this type of feedback is very useful.  Glad you are finding it valuable.

Have you been using the CrUX field data (e.g. from page speed insights etc.) or just your own testing?


On Thursday, 12 May 2022 at 12:25:50 UTC+1 Michal Mocny wrote:
Thank you for taking interest and the excellent report!


It is only affecting the event timing API, so the web exposed value that the web-vitals.js and chrome extension and other RUM depend on... But it won't affect CrUX values.

I agree this is fairly unfortunate and we'll work to fix soon.

There are a few other edge case timing issues like this, if you find more, that's really valuable for us.

Best of luck!

-Michal 

On Thu., May 12, 2022, 06:06 Dave Smart, <dsmart...@gmail.com> wrote:
This could well be a misunderstanding on my part

Links with target="_blank" seem to cause INP to be the time until you come back to that tab by either closing the new tab, or clicking back to the tab, when measured by the JavaScript example given on https://web.dev/inp/

Test case page here: https://testing.tamethebots.com/inpbug/ (I've added the JS to the page so you can see it on page, and in the console)

a random target like target="_GOOG"  seems to mostly behave as expected (I did spot a high INP sometimes) 

target="_new" or target="new" always seems to return as expected. From my understanding this should really be no different to target="_GOOG" so perhaps it's just that I didn't happen to spot the occasional high INP whilst testing?

But the _blank one seems consistently high, and doesn't seem to be measuring what I'd expect.

Tested in Canary Chrome on Windows 10, and canary chrome on Android.

But perhaps I'm misunderstanding something here? 


--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/220b3b04-8682-4106-a20e-e5f323f43480n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.

Dave Smart

unread,
May 12, 2022, 10:25:39 AMMay 12
to web-vitals-feedback
Have you been using the CrUX field data (e.g. from page speed insights etc.) or just your own testing?

Self collected RUM data mostly, (I use the web-vitals.js library and had noticed INP had been added to @next) then local testing.

Also double checking CrUX, but these couple of projects have rather sparse coverage on there, certainly at the url level, so in this case perhaps of limited use.

Dave Smart

unread,
May 13, 2022, 2:23:25 PMMay 13
to web-vitals-feedback
Hey there!

Noticed another one, perhaps known about?


alert(); and confirm();   dialogs display large INP, basically seems the time between these being invoked, then dismissed.

I am aware the long term goal seems to be the depreciation of these, but I thought I'd raise it as there's bound to be quite a lot of sites still using these?

Michal Mocny

unread,
May 13, 2022, 3:03:10 PMMay 13
to Dave Smart, web-vitals-feedback
Hmm, will the short answer is this is not a big (per se) and this is working as intended.

The reason is those calls are explicitly synchronous and blocking the main. Animations in the background would stop, for example.

That said...I agree that users wouldn't exactly consider the site not responsive in the same sense. The problem is different.  We could consider a specific workaround for this, but I guess I hope the pattern isn't common enough to matter (and is already discouraged)


Typically I see those calls only used for local debugging.

Dave Smart

unread,
May 14, 2022, 6:49:59 AMMay 14
to web-vitals-feedback
Makes sense, I guess it's "technically" correct, but it doesn't seem to me to fit the pattern INP is trying to highlight either.

But indeed, it seems from chromestatus.com data that  it's usage is a lot lower than I'd have though, 0.33% of page loads for alert, less for confirm. https://chromestatus.com/metrics/feature/timeline/popularity/950

Perhaps a case of me being very old 😉 so remembering there being a lot more of these. I'm not sure if chromestatus covers all pages, unlike http archive's homepage only? I'm guessing not?

I do come across confirm() particularly being used in admin / dashboard web based panels, usually custom built things, fairly regularly. But I guess it's a more controlled enviroment where although perf. is important, a known issue like this is manageable and accountable for if measuring things.

Dave Smart

unread,
May 14, 2022, 6:51:10 AMMay 14
to web-vitals-feedback
I'm not sure if chromestatus covers all pages, unlike http archive's homepage only? I'm guessing not?

Sorry meant guessing is does cover all page loads, internal included.

Reply all
Reply to author
Forward
0 new messages