these are the issue in the initial 1 second of the website load

i have compiled this data using react scan
https://github.com/aidenybai/react-scan

the following these points are summarised by ai

1. I will provide you with a set of high level, and low level performance data about a large frame drop in a React App:

High level

• react component render time: 0ms
• how long it took to run everything else (other JavaScript, hooks like useEffect, style recalculations, layerization, paint & commit and everything else the browser might do to draw a new frame after javascript mutates the DOM): 100.30000007152557ms

Low level

We also have lower level information about react components, such as their render time, and which props/state/context changed when they re-rendered.

2. You will attempt to implement a performance improvement to a large slowdown in a react app

Your should split your goals into 2 parts:

• identifying the problem
• fixing the problem
  • it is okay to implement a fix even if you aren't 100% sure the fix solves the performance problem. When you aren't sure, you should tell the user to try repeating the interaction, and feeding the "Formatted Data" in the React Scan notifications optimize tab. This allows you to start a debugging flow with the user, where you attempt a fix, and observe the result. The user may make a mistake when they pass you the formatted data, so must make sure, given the data passed to you, that the associated data ties to the same interaction you were trying to debug.

Make sure to check if the user has the react compiler enabled (project dependent, configured through build tool), so you don't unnecessarily memoize components. If it is, you do not need to worry about memoizing user components

One challenge you may face is the performance problem lies in a node_module, not in user code. If you are confident the problem originates because of a node_module, there are multiple strategies, which are context dependent:

• you can try to work around the problem, knowing which module is slow
• you can determine if its possible to resolve the problem in the node_module by modifying non node_module code
• you can monkey patch the node_module to experiment and see if it's really the problem (you can modify a functions properties to hijack the call for example)
• you can determine if it's feasible to replace whatever node_module is causing the problem with a performant option (this is an extreme)

We have the high level time of how much react spent rendering, and what else the browser spent time on during this slowdown

• react component render time: 0ms
• other time: 301.10000002384186ms

We also have lower level information about react components, such as their render time, and which props/state/context changed when they re-rendered.

You may notice components have many renders, but much fewer props/state/context changes. This normally implies most of the components could of been memoized to avoid computation

It's also important to remember if a component had no props/state/context change, and it was memoized, it would not render. So the flow should be:

• find the most expensive components
• see what's causing them to render
• determine how you can make those state/props/context not change for a large set of the renders
• once there are no more changes left, you can memoize the component so it no longer unnecessarily re-renders.

An important thing to note is that if you see a lot of react renders (some components with very high render counts), but other time is much higher than render time, it is possible that the components with lots of renders run hooks like useEffect/useLayoutEffect, which run outside of what we profile (just react render time).

It's also good to note that react profiles hook times in development, and if many hooks are called (lets say 5,000 components all called a useEffect), it will have to profile every single one. And it may also be the case the comparison of the hooks dependency can be expensive, and that would not be tracked in render time.

If a node_module is the component with high renders, you can experiment to see if that component is the root issue (because of hooks). You should use the same instructions for node_module debugging mentioned previously.

If renders don't seem to be the problem, see if there are any expensive CSS properties being added/mutated, or any expensive DOM Element mutations/new elements being created that could cause this slowdown.

3. You will attempt to implement a performance improvement to a large slowdown in a react app

Your should split your goals into 2 parts:

• identifying the problem
• fixing the problem
  • it is okay to implement a fix even if you aren't 100% sure the fix solves the performance problem. When you aren't sure, you should tell the user to try repeating the interaction, and feeding the "Formatted Data" in the React Scan notifications optimize tab. This allows you to start a debugging flow with the user, where you attempt a fix, and observe the result. The user may make a mistake when they pass you the formatted data, so must make sure, given the data passed to you, that the associated data ties to the same interaction you were trying to debug.

Make sure to check if the user has the react compiler enabled (project dependent, configured through build tool), so you don't unnecessarily memoize components. If it is, you do not need to worry about memoizing user components

One challenge you may face is the performance problem lies in a node_module, not in user code. If you are confident the problem originates because of a node_module, there are multiple strategies, which are context dependent:

• you can try to work around the problem, knowing which module is slow
• you can determine if its possible to resolve the problem in the node_module by modifying non node_module code
• you can monkey patch the node_module to experiment and see if it's really the problem (you can modify a functions properties to hijack the call for example)
• you can determine if it's feasible to replace whatever node_module is causing the problem with a performant option (this is an extreme)

We have the high level time of how much react spent rendering, and what else the browser spent time on during this slowdown

• react component render time: 0ms
• other time: 110.89999997615814ms

We also have lower level information about react components, such as their render time, and which props/state/context changed when they re-rendered.

You may notice components have many renders, but much fewer props/state/context changes. This normally implies most of the components could of been memoized to avoid computation

It's also important to remember if a component had no props/state/context change, and it was memoized, it would not render. So the flow should be:

• find the most expensive components
• see what's causing them to render
• determine how you can make those state/props/context not change for a large set of the renders
• once there are no more changes left, you can memoize the component so it no longer unnecessarily re-renders.

An important thing to note is that if you see a lot of react renders (some components with very high render counts), but other time is much higher than render time, it is possible that the components with lots of renders run hooks like useEffect/useLayoutEffect, which run outside of what we profile (just react render time).

It's also good to note that react profiles hook times in development, and if many hooks are called (lets say 5,000 components all called a useEffect), it will have to profile every single one. And it may also be the case the comparison of the hooks dependency can be expensive, and that would not be tracked in render time.

If a node_module is the component with high renders, you can experiment to see if that component is the root issue (because of hooks). You should use the same instructions for node_module debugging mentioned previously.

If renders don't seem to be the problem, see if there are any expensive CSS properties being added/mutated, or any expensive DOM Element mutations/new elements being created that could cause this slowdown.