-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Medium] Simplify down JS #219
Comments
Haha, well let me know when you figure out what to do here. Do keep in mind we have a bunch of timers, count downs, updating gas prices, those are all naturally "long main-thread tasks" in fact, they never finish. Still, any reduction in JS complexity is welcome 🤗 ! In fact, reducing complexity is one of the things devs should value most in my opinion 😄 . |
@alextes Do you see any easy fixes of fat libraries in this? https://ultrasound-bundle-sizes.vercel.app/august-20-2022.html In addition to replacing anything heavy here, it will likely be a LazyLoad wrapper which takes the performance through the roof so that this polling and charting JS does not run until the user scrolls down to it. |
I've looked at that map several times in the past, and removed some libs already, so it's getting harder to remove more.
Then we have the huge highcharts / highcharts-annotations libs, we need them for our charts, or at least I don't see a way to switch to a lighter library without major work replicating all the behavior we built, and carefully making sure any other lib supports future desired behavior. So that option is probably out. So then we should make sure they impact loading minimally. Lazy loading on observation is one way to do it. It may be a great way to make the heaviest components no longer drag down the rest. I'd slightly prefer us to load critical stuff first but that could come later. Where we make sure that the lightest stuff that is the most visible loads first, whilst not blocking the browser from loading the rest when it has CPU cycles / network bytes available. In that line, putting everything that loads highcharts behind a nextjs dynamic import might be a quick and easy win. I think Lastly, I think some of the biggest wins actually lie in changing our design and API endpoints. That way we can both "not load what the user isn't looking at" more without "starting loading only when they already are", which is the other extreme and also not great. |
I think a good approach for this would be server-side pre-fetching of this data with a cache. Next.js makes this easy with https://nextjs.org/docs/basic-features/data-fetching/get-static-props |
For some components yes, but for those which most frequently update I'm not sure.
So I'd say, identify which components rarely update their data, it's not many but there are a couple of heavy ones for which this could be great! For the ones that need to update their data every couple it's probably much more effective to cache that which doesn't change, and client-side fetch and update that which does. That way clients only fetch the new data, not the new rendered components. Which reminds me, hydration is turned off for the Dashboard page 😅 , there were hydration issues, I haven't been able to narrow down what's causing them, even with source maps turned on Sentry isn't much help. So everything is rendered on the client at the moment, huge performance cost, fix the hydration issue, enable more benefits from server side rendering. To turn hydration back on see |
OH, that's probably the biggest factor for improving perf. Let's get the broken components setup to client-side render but enable it app-wide. Testing now |
Monitor JS size over time here: https://ultrasound-bundle-sizes.vercel.app/
The text was updated successfully, but these errors were encountered: