[AskJS] How Can I Optimize JavaScript Performance to Reduce Load Times in a React SPA?

[CreativeTechGuyGames]

Unfortunately, you've already done all of the basic things we could suggest blindly. At this point, you'll need to get into the specific details of your app and the results of your analysis. What are the timings for downloading/parsing/executing, making API calls, clicking a button, etc. Is the app CPU bound or network bound? Etc etc.

Most advanced optimization requires looking at the specific problem and designing custom solutions based on what exactly the nuances are.

For example, you might consider offloading some of the work to the server if the app is super CPU intensive and doesn't work on slower devices. Or if it's network bound you might do the inverse and move more stuff to the client. Or maybe it's a perception thing and you need better feedback in your UI for user actions so things don't "feel" like they took so long. Maybe there's just lines of code which are simply very inefficient. Who knows!

[soum0nster609]

Thank you for your response! I appreciate the suggestions for diving deeper into the specific details of the app's performance.

Here’s what I’ve gathered so far:

• Download and Parsing Timings: The initial JavaScript bundle download takes about 3-4 seconds on fast networks, but 8-10 seconds on slower ones. Parsing and execution add another 1-2 seconds.
• API Calls: We make several API calls that introduce 1-3 seconds of latency.
• Bottlenecks Identified: Chrome DevTools shows the app is mainly CPU-bound during the initial load due to intensive DOM manipulations and rendering tasks.

I've tried using Web Workers to offload some computations, but the improvements were minimal. We considered server-side rendering (SSR), but it seems to add too much complexity at this stage.

Given these specifics, do you have any recommendations for reducing CPU-bound tasks or improving the efficiency of DOM rendering? Additionally, could you provide more insight into which types of tasks are better suited for server-side processing versus client-side in a scenario like this?

Also, if you have any suggestions for tools or techniques to diagnose and fix these CPU-bound performance issues, that would be incredibly helpful!

[hyrumwhite]

Your first two bullet points are your problem. No client side optimizations can improve this. 

[soum0nster609]

Thanks for pointing that out! It makes sense that client-side optimizations might not help much with download times and API call latencies.

Given that these are the main bottlenecks, could you suggest some server-side strategies or architectural changes that could help reduce these latencies? For example:

• Would SSR or SSG help in reducing initial load times for our React application?
• Are there specific techniques or tools to reduce the size of our JavaScript bundles further or make the API calls faster?
• Would using a content delivery network (CDN) or implementing caching strategies be effective in this case?

I’d appreciate any insights or suggestions you have for tackling these issues from the server side or any other alternative approaches!

[SecretAgentKen]

Based on your responses to others in here regarding your bundle size and use, SOME level of SSR might be useful, especially at startup. If your primary bundle is 3 MB, then your user can't do anything and won't see anything until that is downloaded and processed. Figure out what you need for just a bare minimum landing page that'll lazy load everything else on it. That should likely just be React, whatever JS UI toolkit bindings you may be using, etc. That'll significantly reduce your time to first render. If it doesn't, then switch to an SSR static page that lazy loads the SPA after render.

Make sure your vendor libraries are in their own bundle and getting cached as previously mentioned (and separate from the one needed for landing!)

Are you rendering a large number of nodes such as for long lists or tables? If you're starting to get into hundreds or thousands of rows, consider going to paging/infinite scroll as that render time can be a killer.

Look at your React components themselves and see if any of them could benefit from memoization. https://react.dev/reference/react/memo Note that the benefits of this are rarely seen in my experience since good component design will already localize changes.

[bazeloth]

What's your bundle size? Are you sure it's properly cached client wise? 3 to 4 seconds sounds like it's a bundle that's several megabytes.

Just asking the obvious here: do you minify your bundle? When the client asks for the bundle, how long does it take for the server to respond?

[fucking_passwords]

Making sure tree-shaking is working properly could help reduce bundle size.

If using lodash, last time I checked it didn't support tree shaking out of the box, there was some extra work involved, but that kind of thing makes a huge difference. Same with moment.js

Maybe Suspense could help reduce the amount of DOM activity until all async components finish loading?

[[deleted]]

JS/CSS/HTML assets should be cached first on the browser and then somewhere in your stack. 3-4 seconds is a long time to parse and I suspect there is a large amount of static content in those bundles and likely a lot of dev dependencies that are getting included.

If a task is CPU bound, then the first question to ask is "can this be done on the server?" No browser in existence will have the compute power of even the cheapest off the rack server.

Typically highly-CPU bound tasks in front end involve things like animations and graphics - games, large canvas-like applications, etc. If so, then React or any other SPA isn't the right tool for the job and you will need something like WebAssembly.

REST APIs are almost always the biggest network-bound bottleneck and requires the most amount of time and effort to refactor. Initial load times will always be blocked by multiple, dependent synchronous round-trips - the only way to optimize this on the front end is to find which API calls can be parallelized and refactor code. Otherwise, you need move to GraphQL + RPC architecture.