This is part of the Semicolon&Sons Code Diary - consisting of lessons learned on the job. You're in the javascript category.
Last Updated: 2024-05-03
Often performance issues crop up first on mobile. To reproduce this, you can lower the CPU speed under settings in the performance tab.
Here's a description of each of four main result tabs in performance
A Long Task is JavaScript code that monopolizes the main thread for extended periods of time, causing the UI to "freeze". CPU-heavy Long Tasks occur due to complex work that takes longer than 50ms. Why 50ms? The RAIL model suggests you process user input events in 50ms to ensure a visible response within 100ms. If you don't, the connection between action and reaction is broken.
The main thread is considered "blocked" any time there's a Long Task" because the browser cannot interrupt a task that's in progress. So in the event that a user does interact with the page in the middle of a long task, the browser must wait for the task to finish before it can respond. If the task is long enough (e.g. anything above 50 ms), it's likely that the user will notice the delay and perceive the page as sluggish or janky.
In Chrome tools, these appears as long yellow blocks under "Main". They will also have a red flag in the top-right corner. If you click on them can look at "bottom-up" group-by-activity or URL you might get some ideas about the cause.
Measures the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI) where the main thread was blocked for long enough to prevent input responsiveness. Essentially it ensures the page is usable.
To provide a good user experience, sites should strive to have a Total Blocking Time of less than 200 milliseconds when tested on average mobile hardware.
90% of a user's time on a page is spent after it loads, Thus, careful measurement of responsiveness throughout the page lifecycle is important. This is what the INP metric assesses. Good responsiveness means that a page responds quickly to interactions made with it. When a page responds to an interaction, the result is visual feedback, which is presented by the browser in the next frame the browser presents. Visual feedback tells you if, for example, an item you add to an online shopping cart is indeed being added, whether a mobile navigation menu has opened, etc. Some interactions will naturally take longer than others, but for especially complex interactions, it's important to quickly present some initial visual feedback as a cue to the user that something is happening. The time until the next paint is the earliest opportunity to do this. Therefore, the intent of INP is not to measure all the eventual effects of the interaction (such as network fetches and UI updates from other asynchronous operations), but the time in which the next paint is being blocked. By delaying visual feedback, you may be giving users the impression that the page is not responding to their actions.
An "interaction" is a group of event handlers that fire during the same logical user gesture. For example, "tap" interactions on a touchscreen device include multiple events, such as pointerup, pointerdown, and click. An interaction can be driven by JavaScript, CSS, built-in browser controls (such as form elements), or a combination thereof.
An INP below or at 200 milliseconds means that your page has good responsiveness. (at 75th percentile -- the INP is a cumulative score for all interactions whenever the user leaves the page)
You can view the state of the page at different times in the process and quanity how many seconds of delay there is.
They have "performance"-specific reports on the best areas to work on optimizing
Be sure to run on both mobile and desktop -- the score can differ dramatically.