Comments (6)
I've looked at that map several times in the past, and removed some libs already, so it's getting harder to remove more.
The best I see is:
- We have several tooltip implementations, some rather heavy, we also have our first CSS-only one, if we could convert the other JS heavy ones we could drop
react-popper
, but this is quite a bit of work. - I'm not too familiar with the storypreview page that uses framer-motion, but framer-motion looks quite large to me and I wonder if we could tree-shake it.
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 framer-motion
if not tree-shakable also could majorly speed up the page by being behind dynamic import. react-popper
too come to think of it, tooltips don't show on load, but then like I said, it may be possible to drop that lib entirely instead.
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.
from frontend.
For some components yes, but for those which most frequently update I'm not sure.
If your page contains frequently updating data, and you donβt need to pre-render the data, you can fetch the data on the client side. An example of this is user-specific data:
- First, immediately show the page without data. Parts of the page can be pre-rendered using Static Generation. You can show loading states for missing data
- Then, fetch the data on the client side and display it when ready
This approach works well for user dashboard pages, for example. Because a dashboard is a private, user-specific page, SEO is not relevant and the page doesnβt need to be pre-rendered. The data is frequently updated, which requires request-time data fetching.
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 /src/pages/index.tsx
from frontend.
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 π .
from frontend.
@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.
from frontend.
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
from frontend.
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
from frontend.
Related Issues (20)
- gas streak leaderbord HOT 1
- Eth Supply Projection - Amount of Eth "in contracts" is wrong HOT 3
- Eth Supply Projection - Dynamic default values for sliders HOT 1
- Burn Leaderboard - Some contracts missing twitter info HOT 1
- Burn Categories - Categories undistinguishable in gauge HOT 1
- Validator Rewards - Dynamically estimate MEV Share HOT 1
- Gas Streak - Broken Logic / Incorrect Values HOT 1
- Base Fees - Extend Datapoint-Tooltip HOT 1
- Supply Equilibrium - Revisit slider limits HOT 1
- Design - Inconsistencies in Fonts etc. HOT 1
- low-hanging visual tweak to the supply equilibrium
- issuance breakdown wrong ordering
- some Twitter images are not loading
- continuously update tab title prices
- Twitter pfps not loading in ERC20 leaderboard
- New Feature - Layer 2 Section / Widget
- New Feature - Blob Data Burn HOT 2
- New Feature - Flippening Widget HOT 1
- New Feature - "Eth the internet bond" HOT 2
- NFT Leaderboard wrong data HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from frontend.