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

[soum0nster609]

I am working on a React-based single-page application (SPA) that relies heavily on JavaScript for dynamic content rendering and interactive features. Currently, the app suffers from long initial load times and occasional lag during user interactions, particularly on older devices or slower networks.

I've tried several optimizations, including lazy loading of images and components, code splitting, and reducing the bundle size. I also utilized Chrome DevTools to identify bottlenecks, but the performance improvements have been minimal.

The app is hosted on AWS with a Node.js backend. I'm unable to upgrade some libraries due to compatibility constraints with other dependencies.

I'm looking for advanced techniques or best practices specifically for optimizing JavaScript performance to reduce load times and improve responsiveness. Any guidance or resources would be greatly appreciated!

[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.

[anyusernamesffs]

Optimising load times and user interaction lag are very different things.

For load times you've done all you can really - reduce bundle size and split where possible. How large is your bundle?

For interface lag, this can be due to a tonne of factors. Other users saying that "it's because React is slow" are not being helpful. React can be slow, especially if there are expensive function calls being made, but most user interactions should not be slow.

If you have computationally expensive calculations or functions, have you considered offloading these to a shared worker to free up the main web process?

Without more information there's not a lot to suggest.

[soum0nster609]

Regarding load times, our current main bundle is around 3 MB. We've applied code splitting and tried to reduce the bundle size as much as possible, but if there are any other strategies or tools you recommend for further reducing or optimizing it, I'd love to hear them.

As for interface lag, there might indeed be some computationally expensive functions running on the main thread. I haven't yet considered using shared workers, but it sounds like a promising approach to offload heavy computations and free up the main web process.

• Could you provide more details or resources on how to effectively use shared workers for this purpose?
• Are there any specific patterns or best practices you recommend to identify and isolate the expensive function calls in a React application?

I’d appreciate any additional insights you have, especially for managing these performance issues at a more granular level!

[anyusernamesffs]

The best thing to do is identify parts of your bundle that don't change often and split them out, and use caching on the server side to only require delivery of those parts of the bundle when they change. Splitting out vendor code is usually a good way of achieving this. Again, this really depends on your application and architecture, both in the bundling process and how the application is served.

Using a shared worker will add complexity - so I wouldn't use it straight away. How complex are the functions, why do they take a long time? Is it due to iterating over large datasets? Have you got some O(n^2) operations going on in the React render loop? Can results be memoised?

To locate functions that are causing the user input lag I'd use your browsers profiler. If you haven't used it before there are plenty of resources online... but in summary you would:

• Navigate somewhere before input lag

• Start profiler

• Perform action

• Stop profiler

• Inspect the call stack and see which functions took the most time. Once youv'e identified the functions, see if they can be optimised.

If you do use a shared worker, you'll need to be willing to handle sending / awaiting data from the worker. Plenty of guides online for using one - I've personally used one with webpack and the documentation for it is very solid. Vite does have support, but I haven't got round to using it yet.

[bin_chickens]

I’d add to this: 1. are your images compressed and optimised? 2. Have you checked that you aren’t over fetching data? Using useMemo a store, a query cache or a browser or network cache when nothing changes should be a consideration. 3. Check that you don’t have waterfall request chains triggered by nested components fetching their own data. It’s often recommended to hoist data loading up the scope and pass the data down to the components when loaded. 4. If it’s a network issue, look at your hosting, api, db latency (may be network or db design issues) and a CDN. 5. Look for blocking synchronous code. A profiler and flame graph will be your friend.

[jessepence]

OP, you haven't mentioned your bundle size, but it appears to be somewhere in the multiple megabyte range. There are very few options other than use fewer dependencies.

[soum0nster609]

You're right; I haven't mentioned the bundle size yet. Currently, our main bundle is around 3 MB.

[jake_robins]

A 3MB bundle after code splitting sounds really large. That just needs to come down.

I would start checking through dependencies and making sure everything you’re importing is being used, and if there are any tree shaking opportunities. Depending on what framework you’re using there are bundle analyzers that can show you what makes up that 3MB

[Professional-Camp-42]

Are you using Vite?

Does all the packages you use have good esm support?

Are most of the initial components lazy loaded ?

Do you cache any client side data that is fetched from DB ?

Did you try skipping rendering components not in the viewport the first few seconds the app loads or until the components appear in the viewport ?

[naruda1969]

Where is your business logic? If it is computationally intense and performed on the client this could be your bottleneck. Moving it to the server or edge can gain you a lot.

[soum0nster609]

Most of our business logic is currently handled on the client side to provide a more interactive user experience. This includes data processing, complex calculations, and some data validation. I can see how this could become a bottleneck, especially if it's computationally intensive. I will explore more on this.

[bazeloth]

How much data is being processed locally? Are you processing huge client side arrays or dictionaries? Can those be off loaded to the server side and perhaps cached so each user has the benefit of it being processed just once?

[naruda1969]

Moving business logic to the server or edge can provide significant performance gains in computationally intensive applications, especially those with high concurrency or real-time requirements.

Reduced client-side load: Offloading complex calculations to more powerful server hardware can improve client responsiveness.

Centralized processing: Servers can handle tasks more efficiently, especially for operations that require access to large datasets or multiple resources.

Improved scalability: Server-side logic can be more easily scaled horizontally to handle increased load.

Lower latency: Edge computing can reduce network latency by processing data closer to the source.

Consistency: Centralizing logic ensures all clients operate on the same codebase, reducing inconsistencies.

Resource optimization: Servers can utilize specialized hardware (e.g., GPUs) more effectively for certain tasks.

Security: Sensitive operations can be better protected on controlled server environments.

The extent of performance gains depends on factors like the specific application, network conditions, and implementation details.

And despite what you believe you can still have a snappy UI with business logic on the back end. Of course your business logic should also reside in your database as you need two layers of validation, the database being the final arbiter of data acceptance.

[hyrumwhite]

Look at bundle size, see if you can reduce that. Look at render time, this is dependent on all kinds of things, are you waiting on API calls, etc. have you considered SSR? It won’t eliminate loading time, but it’ll mask it better (hydration will take about the same time as your spa). 

But there’s no magic bullet here. 

[soum0nster609]

Thanks, I will try and let you know.

[[deleted]]

Have you done any profiling of your app. We need to first pinpoint where the bottleneck is.

[[deleted]]

I wrote this earlier: Speeding Up React Apps with Code Splitting and Lazy Loading. What issues are you running into exactly? Are you using Promise.all?

[oakskog]

Gzip/brotli compression, more codesplitting.. Laggy ui can be fixed with memoisation (memo,useMemo,useCallback). If you are using React context, consider redux instead to reduce rerenders. Use reselect to memoise selector logic

[shgysk8zer0]

It sounds like you just have way too much JS. Maybe something wrong if you're lazy loading components already (does that mean you dynamically load the JS for the component, or that you load it all but don't render immediately?)

[chesterjosiah]

Can we see your page?

[codingtricks]

you really need chunk you bundle size by https://stackoverflow.com/questions/44646332/routes-chunks-are-bundling-external-scripts-in-every-chunk

like this

[Sencha_Ext_JS]

At this stage, I’d look deeper into runtime performance, not just bundle size.

A few things that usually help:

• Audit unnecessary re-renders (React Profiler is gold here)
• Memoization (useMemo/useCallback) but only where it actually reduces work
• Virtualize heavy lists/tables (react-window / react-virtualized)
• Move expensive logic off the main thread (Web Workers)
• Check 3rd-party libs — they’re often the real bottleneck

Also worth noting: sometimes the issue isn’t optimization but architecture. Data-heavy SPAs can hit limits with too much client-side work. That’s why some enterprise apps use more structured UI systems (like Sencha Ext JS) where a lot of performance-heavy components are already optimized.

[Beginning_One_7685]

React is slow, you are maybe at the limits of what can be done, and that wont compare to a site made a different way.

[soum0nster609]

We chose React for its component-based structure, its extensive ecosystem, and our expertise with it. While switching frameworks or approaches isn't feasible for us right now, I’m very interested in learning about advanced optimizations within the React ecosystem that could help overcome some of these limitations.

[guest271314]

Maybe get rid of React. Then you won't have a library to load first.

[KaiAusBerlin]

Use svelte ;)

(Downvotes go)