Skip to content
This repository was archived by the owner on Mar 14, 2024. It is now read-only.

Adds INP content collection#9915

Merged
malchata merged 39 commits intomainfrom
inp-content-collection
May 9, 2023
Merged

Adds INP content collection#9915
malchata merged 39 commits intomainfrom
inp-content-collection

Conversation

@malchata
Copy link
Copy Markdown
Member

@malchata malchata commented Apr 17, 2023

Changes proposed in this pull request:

  • Adds the INP content collection.

@malchata malchata added P0 An urgent priority task. Drop everything and work on this! DO NOT MERGE Actively working on but experimental content Issues related to content content update for issues that do not require new content (only for updates to existing content) labels Apr 17, 2023
@malchata malchata self-assigned this Apr 17, 2023
@netlify
Copy link
Copy Markdown

netlify bot commented Apr 17, 2023

Deploy Preview for web-dev-staging ready!

Name Link
🔨 Latest commit 4161ab4
🔍 Latest deploy log https://app.netlify.com/sites/web-dev-staging/deploys/645a9d3467595b0008cc2a5e
😎 Deploy Preview https://deploy-preview-9915--web-dev-staging.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

@malchata malchata added vitals and removed vitals labels Apr 17, 2023

When a user interacts with the page, those interactions should be as fast as possible. The amount of time it takes for an interaction to complete—ending when the browser presents the next frame to show the results of the interaction—is known as _interaction latency_. This is an aspect of page performance that the [Interaction to Next Paint](/inp/) metric measures.

The amount of time it takes for the browser to present the next frame in response to a user interaction is known as the interaction's _presentation delay_. The goal of an interaction is to provide visual feedback in order to signal to the user that something has occurred, and visual updates can involve some amount of layout work in order to achieve that goal.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The amount of time it takes for the browser to present the next frame in response to a user interaction is known as the interaction's _presentation delay_. The goal of an interaction is to provide visual feedback in order to signal to the user that something has occurred, and visual updates can involve some amount of layout work in order to achieve that goal.
The amount of time it takes for the browser to present the next frame after processing a user interaction is known as the interaction's _presentation delay_. The goal of an interaction is to provide visual feedback in order to signal to the user that something has occurred, and visual updates can involve some amount of layout work in order to achieve that goal.

I initially read that as being the whole time so suggested a tweak to make it clearer.


Layout is almost always scoped to the entire document. If you have a lot of elements, it's going to take a long time to figure out the locations and dimensions of them all.

If it's not possible to avoid layout then the key is to once again use Chrome DevTools to see how long it's taking, and determine if layout is the cause of a bottleneck. Firstly, open DevTools, go to the Timeline tab, hit record and interact with your site. When you stop recording you'll see a breakdown of how your site performed:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You haven't explained how it is possible to avoid layout. Do you mean making changes that don't affect "geometric properties"? E.g. ensuring elements are sufficiently sized to take any updates?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A lot of this doc is left over from what Paul wrote, and what he wrote was a bit high-level. There's a ton of context we'll have to fill in after launch, I think.

@malchata malchata requested a review from tunetheweb May 7, 2023 17:46
@malchata malchata removed the DO NOT MERGE Actively working on but experimental label May 7, 2023
@malchata malchata requested a review from rachelandrew May 7, 2023 17:46
Comment on lines -71 to -72
"optimize-long-tasks",
"optimize-inp",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why remove these?

I think optimize-long-tasks is still good optimize JavaScript advice and there's no problems with this being in two collections.

Optimize INP should be moved to where the other Optimize guides are

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add them back in.

Co-authored-by: Barry Pollard <barrypollard@google.com>
malchata and others added 3 commits May 8, 2023 09:21
Copy link
Copy Markdown
Member

@tunetheweb tunetheweb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Think we're pretty much there so approving for you to merge when happy. Well done!

@malchata malchata merged commit 8345b9b into main May 9, 2023
@malchata malchata deleted the inp-content-collection branch May 9, 2023 19:27
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

content update for issues that do not require new content (only for updates to existing content) content Issues related to content P0 An urgent priority task. Drop everything and work on this!

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants