You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
WPT doesn’t capture all the JavaScript processing time during page load. More concretely, WPT reports idle main time on the browser main thread, for any JavaScript processing triggered from a fetch response.
Steps to reproduce
This issue can be reproduced by running WPT on a Chrome desktop with the default setting against the following page: https://wpt-async-repro.pages.dev/
The HTML source code can be found in this gist. The HTML page contains a single <script> simulating JavaScript on the main thread.
The doWork function blocks the main thread for 500ms and adds performance markers at the beginning and the end of each chunk of work. This function is invoked in 4 different ways:
sync: synchronously during script evaluation
microtask: asynchronously in a microtask enqueued during script evaluation
timeout: asynchronously in a macro-task scheduled via a timeout
fetch: asynchronously in a microtask after the reception of a fetch request
Expected result
The WPT run should report ~2 seconds of JavaScript processing time. The JavaScript processing time should be reflected in:
Processing Breakdown table as “Scripting” time
Waterfall panel in the “CPU main thread” swimlane
Chrome Timeline view as JavaScript scripting
and, in Chrome Trace view
Recording a Performance timeline locally through the Chrome Devtools with JavaScript Sampling disabled correctly captures all the JavaSript processing time.
Actual result
The WPT run reports ~1.5 seconds of JavaScript processing time. The 500ms of JavaScript processing time associated with the fetch response is missing from the WPT run result.
Further Investigation
When digging further it is apparent that the Chrome Dev Tools captures the JavaScript execution associated with the fetch response thanks to the v8.execute Chrome tracing category. The list of tracing categories used by the Chrome Dev Tools used by the performance panel can be found here.
The text was updated successfully, but these errors were encountered:
Description
WPT doesn’t capture all the JavaScript processing time during page load. More concretely, WPT reports idle main time on the browser main thread, for any JavaScript processing triggered from a fetch response.
Steps to reproduce
This issue can be reproduced by running WPT on a Chrome desktop with the default setting against the following page: https://wpt-async-repro.pages.dev/
The result can be found here: https://www.webpagetest.org/result/240506_AiDcKB_5G1/
Description
The HTML source code can be found in this gist. The HTML page contains a single
<script>
simulating JavaScript on the main thread.The
doWork
function blocks the main thread for 500ms and adds performance markers at the beginning and the end of each chunk of work. This function is invoked in 4 different ways:sync
: synchronously during script evaluationmicrotask
: asynchronously in a microtask enqueued during script evaluationtimeout
: asynchronously in a macro-task scheduled via a timeoutfetch
: asynchronously in a microtask after the reception of a fetch requestExpected result
The WPT run should report ~2 seconds of JavaScript processing time. The JavaScript processing time should be reflected in:
Recording a Performance timeline locally through the Chrome Devtools with JavaScript Sampling disabled correctly captures all the JavaSript processing time.
Actual result
The WPT run reports ~1.5 seconds of JavaScript processing time. The 500ms of JavaScript processing time associated with the fetch response is missing from the WPT run result.
Further Investigation
When digging further it is apparent that the Chrome Dev Tools captures the JavaScript execution associated with the
fetch
response thanks to thev8.execute
Chrome tracing category. The list of tracing categories used by the Chrome Dev Tools used by the performance panel can be found here.The text was updated successfully, but these errors were encountered: