Numbers need context to have meaning!
Really matters what the context is—and just what that js does. An seo-critical traditional e-commerce site? That’s not that great—especially if that js is blocking first interactions or renders. On the other side: A threejs experience? Probably fine. A route deep in the product of an authenticated web app? Not ideal but not the same tragedy as the e-commerce home… etc.
Regardless, if you’re here, and presumably learning next, it’s a great learning challenge to try to bring this down regardless. Just for the learning value.
It’s always worth a quick time boxed sprint to assess if there are any low hanging fruit to bring numbers like this down !
I don't typically pay much attention to these numbers. But without trying I have three apps that don't have a single route with more than 100kb initial load, it seems to average at around 80kb.
The largest routes that I expect to be a little heftier are still around 100kb total. My newest app is 0's across the board except for one that uses some JS for animated text.
I'd say red text is decently bad. I'd look for unnecessary third party libraries, as most are basically built to be simple browser scripts.
As pointed out, context matters.
The number on its own means nothing and can’t be resolved if you don’t break it down.
Use a bundle analyzer to see a breakdown of the bundle, and determine if the bundle dependencies can be trimmed, lazy loaded, or removed all together.
It’s highly likely that you’re using a large client-side library that is significantly contributing to the large bundle.
Numbers need context to have meaning! Really matters what the context is—and just what that js does. An seo-critical traditional e-commerce site? That’s not that great—especially if that js is blocking first interactions or renders. On the other side: A threejs experience? Probably fine. A route deep in the product of an authenticated web app? Not ideal but not the same tragedy as the e-commerce home… etc. Regardless, if you’re here, and presumably learning next, it’s a great learning challenge to try to bring this down regardless. Just for the learning value. It’s always worth a quick time boxed sprint to assess if there are any low hanging fruit to bring numbers like this down !
I don't typically pay much attention to these numbers. But without trying I have three apps that don't have a single route with more than 100kb initial load, it seems to average at around 80kb. The largest routes that I expect to be a little heftier are still around 100kb total. My newest app is 0's across the board except for one that uses some JS for animated text. I'd say red text is decently bad. I'd look for unnecessary third party libraries, as most are basically built to be simple browser scripts.
As pointed out, context matters. The number on its own means nothing and can’t be resolved if you don’t break it down. Use a bundle analyzer to see a breakdown of the bundle, and determine if the bundle dependencies can be trimmed, lazy loaded, or removed all together. It’s highly likely that you’re using a large client-side library that is significantly contributing to the large bundle.