Fair point, although I'd say trivial is a bit of an exaggeration.
I'm currently building from this on an enterprise level application tying together several APIs and a CMS and using a cdn for static resources, currently still hitting 100s and plan on using lighthouse in CI to make sure people don't break it (it's normally accessibility that breaks).
The problem I guess I'd have with writing about that (when I can / if I'm allowed to) is that at that level projects have very unique characteristics so it's hard to write a one sized fits all. I'd suggest with NextJS and webpack common chunking the main decision is picking what to SSR and caching approaches to pages.
That's true, trivial was not the best word to use :D Also true that it's hard to write something that will suit all bigger-sized projects. But there are things that could be common to all of them and would not be so easy to fix:
For example:
loading images
loading critical css
reducing main-thread work
Additionally, when you're using Redux or other state-management libraries and have a massive store, it's also good to:
load reducers asynchronously
load sagas asynchronously
There are also many ways to optimize stuff thanks to NextJS support for dynamic component loading.
All those things can be very hard to do and I think that it would be nice to have an article which would show up how to handle this on some example.
Anyways, I didn't mean your article is bad or useless, it's a great write up! :) Sorry if it did sound like that!
Haha no offence taken I do see where you’re coming from. Agree with the points, and yeah next seems like the perfect start point to get so many optimisations.
Ok yeah so images should be behind a cdn, optimised for size and if you know dimensions in advance you can prevent the page jumping around.
Did you see much benefit in loading reducers/sagas async? The only benefit I could see is if some of those import other libs, e.g in one of my cases a socket library.
I’m quite interested in looking at github.com/dunglas/react-esi. Seems like you could do some crazy stuff for caching.
Actually there's not much benefit in loading reducers/sagas, so this suggestion might be just my overengineering :) Thanks for bringing up react-esi - I didn't know about this!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Fair point, although I'd say trivial is a bit of an exaggeration.
I'm currently building from this on an enterprise level application tying together several APIs and a CMS and using a cdn for static resources, currently still hitting 100s and plan on using lighthouse in CI to make sure people don't break it (it's normally accessibility that breaks).
The problem I guess I'd have with writing about that (when I can / if I'm allowed to) is that at that level projects have very unique characteristics so it's hard to write a one sized fits all. I'd suggest with NextJS and webpack common chunking the main decision is picking what to SSR and caching approaches to pages.
That's true,
trivial
was not the best word to use :D Also true that it's hard to write something that will suit all bigger-sized projects. But there are things that could be common to all of them and would not be so easy to fix:For example:
Additionally, when you're using Redux or other state-management libraries and have a massive store, it's also good to:
There are also many ways to optimize stuff thanks to NextJS support for dynamic component loading.
All those things can be very hard to do and I think that it would be nice to have an article which would show up how to handle this on some example.
Anyways, I didn't mean your article is bad or useless, it's a great write up! :) Sorry if it did sound like that!
Haha no offence taken I do see where you’re coming from. Agree with the points, and yeah next seems like the perfect start point to get so many optimisations.
Ok yeah so images should be behind a cdn, optimised for size and if you know dimensions in advance you can prevent the page jumping around.
Did you see much benefit in loading reducers/sagas async? The only benefit I could see is if some of those import other libs, e.g in one of my cases a socket library.
I’m quite interested in looking at github.com/dunglas/react-esi. Seems like you could do some crazy stuff for caching.
Actually there's not much benefit in loading reducers/sagas, so this suggestion might be just my overengineering :) Thanks for bringing up
react-esi
- I didn't know about this!