Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

INP still says “waiting for user input” even after I clicked / typed #108

Closed
verlok opened this issue Oct 6, 2022 · 11 comments
Closed

Comments

@verlok
Copy link

verlok commented Oct 6, 2022

Describe the bug
After reading through all the INP documentation on web-dev and reading the recommendations to optimise INP, I wanted to try if using a skeleton pattern would help reducing INP.

So I tried and created this pen on Codepen, which displays gray boxes while the page is loading async content.

The problem is that, even opening the page in debug mode (so without the Codepen interface) like this, the web vitals extension still says “waiting for user input” even after I clicked on the “load async content” button or clicked / typed on the input.

To Reproduce

  1. Open my pen in debug mode or, if it doesn't work, download this pen locally and run on a local server.
  2. Interact with the page, enter numbers in the input, click on “load async content”
  3. Notice that INP in the extension is still on "waiting for user input" mode

Expected behavior
I expected the extension to show some values in INP after I clicked or interacted with the page.

Version:

  • MacOS 12.6
  • Google Chrome Version 105.0.5195.125 (Official Build) (x86_64)
    and Microsoft Edge Version 105.0.1343.53 (Official build) (x86_64)

Additional context, screenshots, screencasts

Screenshot
Screenshot 2022-10-06 at 11 40 41

@tunetheweb
Copy link
Member

Codepens are loaded in iframes and Web APIs cannot see into iframes - though it should be noted CrUX does as not limited by Web APIs.

You'll also see that if you turn on the extension's console logging, it registers an LCP but it's the outer page's title, even though the inner iframe's title is bigger.

So to replicate this you'll need to host this page outside of CodePen (I tried it in full screen mode, but it still does it via an iframe).

@verlok
Copy link
Author

verlok commented Oct 6, 2022

Thanks @tunetheweb for your reply.

The fact is there are no iframes involved if you open the pen in debug mode as I mentioned in my first message.

I also tried to download the pen and run it locally on my machine, again no iframes, but I still have the problem.

@tunetheweb
Copy link
Member

Apologies for that!

I figured it out. INP, like CLS is basically calculated at the end of page life cycle, not on every interaction. The Extension has some logic to broadcast the latest CLS, but the same doesn't exist for INP. So to get you INP, until that's added, you need to "leave" the page. The easiest way to do that is to switch tabs, and then switch back again.

Will chat to the team about adding a latestINP, similar to CLS.

@mmocny
Copy link
Member

mmocny commented Oct 6, 2022

INP is actually updated instantly every time there is a new measured interaction. But thats based on Event Timing, and Event Timing doesn't necessarily measure every single interaction.

At the moment, the web-vitals-extension uses the default durationThreshold that the web-vitals.js library ships with, which is 40ms. You can override this value, but the extension is not doing so, yet. See #103.

Besides this, the web-vitals.js has landed several improvements to vitals measurement and INP specifically-- so I think the first task is to roll the the latest web-vitals.js v3.0 here.

@philipwalton
Copy link
Member

Yeah, what @mmocy said. The web-vitals library now falls back to FID, so it should always get the first input. Updating it should solve this issue.

@verlok
Copy link
Author

verlok commented Oct 6, 2022

Thank you.
So what I did to try and use my page was to install the web-vitals library locally and use the following options

onINP(console.log, { reportAllChanges: true, durationThreshold: 1 });

With that, I get a report of my clicks on the checkbox and on the html element, but surprisingly I don't get the reports of other bigger paints like when the main content of the page is updated after the async call.

This is probably an issue to open in the web-vitals repo, isn't it?

@mmocny
Copy link
Member

mmocny commented Oct 6, 2022

That is working as intended (even if not as desired).

Specifically, INP only measures up to the single next paint (or, if there is no need for next paint, until the decision point).

If you have async work that updates main content, this will not get captured. I think you may want to use Element Timing for that, or, perhaps you are making the case for a "Interaction to next LCP" type metric... I would encourage filing an issue asking for that :)

@verlok
Copy link
Author

verlok commented Oct 6, 2022

Thanks @mmocny,

I must have completely misunderstood the meaning of "paint" while reading all of the explanation in the INP page.
Let's just ignore my latest comment then.

I think this issue still useful as a reminder to roll the the latest web-vitals.js v3.0.
If not, feel free to close this.

@tunetheweb
Copy link
Member

You're not the only one who misunderstood this @verlok ! I did too initially.

Some more info here: https://twitter.com/tunetheweb/status/1578065048752242698?s=20&t=FY7tdngVmmGiuXXpJJHW_g

@verlok
Copy link
Author

verlok commented Oct 6, 2022

Oooooooh. So it’s like Interaction to Next ability to Paint. Or Potential Paint.

Thank you for this explainer, Barry. I will save the link to your tweet in my bookmarks.

I wonder why this isn’t clear by reading the doc on web.dev/inp

@tunetheweb
Copy link
Member

Oh we tweaked that only recently to try to make that more clear: GoogleChrome/web.dev#8686

Open to suggestions on how to further clarify this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants