Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

INP discrepancy due to testing harness

Đang mở
  • Có gì không ổn?
#573 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
javascript, typescript
Lĩnh vực
performance, testing-qa

Hướng nghiên cứu

Start by reading the testing harness and its INP measurement flow, then compare traces for synchronous URL updates and deferred updates on headless Linux versus a full Chrome instance. The report is a hypothesis rather than a confirmed diagnosis, and names no files or tests. Done means identifying whether the harness causes the discrepancy and documenting or addressing a reproducible cause.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

discussion

I found a problem with the way INP (Event Timing, or "interaction breakdown"), i'm not 100% sure about it, and not sure how solvable it is.

Here is my understanding:

when Chrome is software-rendered (headless on Linux, and also headed on a virtual display), updating the URL on click makes the browser repaint its own UI (toolbar / URL bar), and the page's next frame is held until that browser-UI frame is ready. That wait gets counted in presentation delay. It penalizes any framework that pushes the URL synchronously on click (i.e. only tanstack in the current list, the others only update the URL once the route is ready). On my server it's about 2 - 3 ms added to tanstack's time.
I tried deferring the URL update by one task and the penalty is gone. And for comparison, I also tried forcing React Router to update the URL during the click and it also loses 2 - 3 ms.

Testing on a full chrome instance, on my macbook, this penalty doesn't exist.

I found this because I was trying to lower our INP score, and found that in tests I was capped, even removing almost everything, i couldn't get the number to go down beyond a point, and this is my best theory so far

🤖 Below is an explanation of this mechanism by an agent (it's talking about #8602 because that's the PR where I was working on link performance)

The frame cannot be shown before the browser's own toolbar frame is ready, and that takes about 12 ms from the click.

Where the 12 ms comes from

From the traces on Linux, for TanStack on #8602:

Step Time after the click
The native pushState runs about 3 ms
The browser process receives the navigation about 4 to 5 ms
It updates the toolbar, then lays out, paints and rasterizes its UI about 7 ms of work
The browser's UI frame is submitted about 10 ms
The display draws and presents about 3 ms more
Earliest possible presentation about 12.5 to 13 ms

That chain does not depend on when the next frame tick falls. The toolbar repaint is slow there because it is rasterized on the CPU.

The page's own frame is usually ready well before that, around 9 ms. The trace shows the display holding it with the message "More damage expected soon". My reading is that the display composes the page and the browser UI into one picture, and waits for a surface that has announced an update, up to a deadline. The wait itself is measured. The reason for it is my interpretation of that message.

Why that averages out to 2 to 3 ms

Without the pushState, latency depends on luck: where the click lands relative to the next frame tick.

  • A lucky click, just before a tick, finishes in about 7 ms.
  • An unlucky one, just after a tick, takes 17 ms or more.

With the push inside the click, the lucky cases are no longer possible. Every click that would have finished between 7 and 12 ms is pushed up to about 12.5 ms. The unlucky ones were already slower than that and are unaffected.

In the arms without the in-click push, about half the runs finished under 12 ms, averaging around 9 to 10 ms. Pushing those up to 12.5 costs about 3 ms each, on half the runs. That gives roughly 1.5 to 2 ms on the mean, which is the bulk of what we measured. The rest comes from runs slightly above the floor that also waited a little for the toolbar frame.

So the same mechanism gives both numbers:

What you look at What you see
The fastest runs a hard floor near 12.5 ms
The mean about 2 to 3 ms worse
The slowest runs no difference

It also shows in the spread. TanStack's latencies were bunched together, with a standard deviation of 2.6 ms, against 4 to 5 ms for the others. Its low tail is cut off and its high tail is not.

Why this explains #8602's small unthrottled gain

On main, the click handler took about 7 ms, so it was still running while the browser repainted its toolbar. The two overlapped, and the floor was hidden behind the processing time. #8602 cut processing by 4 ms, which exposed the floor. The handler now finishes at 3 ms and then waits for a frame that cannot arrive before 12.5.

Why it vanishes on the Mac

The toolbar chain takes just as long there, 6 to 13 ms. The difference is that the display does not wait for it. It presented the page's frame about 0.1 ms after the renderer submitted it, in every arm.

Ngôn ngữ chính
TypeScript
Star
42
Fork
16
Merge trung bình
13 giờ 56 phút
Pull request đã merge (30 ngày)
141

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của e18e/framework-tracker

Tất cả issue của e18e/framework-tracker

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.