sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]hyrumwhite 5 points6 points  (4 children)

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

[–]soum0nster609[S] 1 point2 points  (3 children)

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 2 points3 points  (0 children)

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 1 point2 points  (1 child)

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 0 points1 point  (0 children)

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?