{
\"width\": 600,
\"height\": 400,
\"timeline\": {
\t\"min\": 3375003509,
\t\"max\": 3375288.8310000002,
\t\"range\": 3375288.8310000002
},
\"searchEvent\": {
\t\"pid\": 34224,
\t\"tid\": 31544,
\t\"min\": 3375003509,
\t\"max\": 3375288831,
\t\"range\": 3375288831
}
}
The selected callframe is a Function call originating from a Next.js framework chunk. This function call is executed as a microtask, triggered by a user click event. It represents a significant portion of the work performed in response to the click.
Execution Context:
- Ancestors: This
Function callis part of a chain initiated by a userTaskwhich led to anEvent: click. The click event handler (v8.callFunction) then queued microtasks (Run microtasks), one of which is this selectedFunction call. - Descendants: The selected
Function callspawns two main branches. One branch involves a series of anonymous functions and calls related to styling (css,renderRule,_renderStyleToClassNames) and DOM property retrieval (getPropertyValue) which triggersRecalculate style. The other branch (oK->oQ-> ...) shows a highly repetitive pattern involvingremoveChildcalls, which also triggerRecalculate style. Both branches include calls that eventually lead tosetTimeout, suggesting deferred work, likely related to analytics or other asynchronous tasks.
Performance Quantification:
- The selected
Function calltook 148.9ms to execute, with 23.6ms spent directly within the function itself. - This callframe accounts for almost the entire duration of the
Run microtasksphase (148.9ms out of 149.9ms) and represents a substantial part of the totalEvent: clickduration (148.9ms out of 257.8ms). - Potential bottlenecks are evident in its descendants:
- A significant portion (50.4ms) is spent in a path involving CSS processing (
css,renderRule,_renderStyleToClassNames), with 30ms self time in_renderStyleToClassNames. - A highly repetitive sequence of calls (
oK->oQ-> ...) culminates in frequentremoveChildoperations and subsequentRecalculate styleevents. While each individualremoveChildorRecalculate styleis relatively short (around 2-4ms), their repeated execution contributes significantly to the overall time.
- A significant portion (50.4ms) is spent in a path involving CSS processing (
Suggestions for Improvement:
- Investigate the CSS processing path (
css,renderRule,_renderStyleToClassNames). If using a CSS-in-JS library, ensure styles are efficiently generated and applied, avoiding redundant work or excessive runtime style computation. - Analyze the code responsible for the repetitive
removeChildcalls. This pattern strongly suggests inefficient DOM manipulation. Look for loops or recursive functions that are repeatedly adding or removing elements. Batching DOM updates (e.g., building a fragment and appending it once) or using techniques that minimize DOM manipulation and style recalculations can drastically improve performance. - Review the analytics tracking implementation (indicated by the presence of multiple Google Tag Manager URLs). Ensure tracking calls are asynchronous and non-blocking where possible, especially within critical user interaction paths like click handlers. The repeated
setTimeoutcalls originating from these scripts suggest some work is deferred, but the initial synchronous execution is still costly.