-
Notifications
You must be signed in to change notification settings - Fork 54
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
Lazy load components #1675
Lazy load components #1675
Conversation
751f89f
to
d80ef81
Compare
911966e
to
a3850a7
Compare
import NcActionButton from '@nextcloud/vue/dist/Components/NcActionButton.js' | ||
import NcActionLink from '@nextcloud/vue/dist/Components/NcActionLink.js' | ||
import NcModal from '@nextcloud/vue/dist/Components/NcModal.js' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not fond of lazy loading components that are always included. We don't gain anything but a bit more weight and network usage :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your call; I'd disagree though. The user preceivable performance is primarily due to JS (a) loading time and (b) parsing time. Splitting up the components bundle is faster on both counts. Since the bundle is prefetched and cached, the user can never know about the second request behind the scenes when the viewer is actually opened. In that sense, it's not really lazy loading, but just splitting up parsing and compilation of the critical and non-critical parts (since it all happens on the UI thread). Also the total size remains exactly the same as before, so no extra weight (note I'm looking at stat
size, not parsed
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the bundle is prefetched and cached, the user can never know about the second request behind the scenes when the viewer is actually opened.
That is not the case Webpack does not preload the js, it will load them on demand.
If you're on slow network, it can adds up quite a lot :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, you need to specify the webpackPrefetch
and/or webpackPreload
magic comment(s) to enable preloading. If that's not working then it's a bug maybe or prefetching is broken somehow.
https://webpack.js.org/guides/code-splitting/#prefetchingpreloading-modules
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to work for me. If you turn on
Disable Cache
in the JS console then it disables prefetching; could be related to that. The above is with a cold cache in incognito.
Nope even with cache disabled 🤔
Component, plyr or editor are loaded after the viewer is opened.
I'm also ok merging this, and we can always see later how it goes 🤷
But I kind of would like a more wider discussion on async components, so we can all decide to go the same direction?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you be up to create a thread on https://github.com/nextcloud/standards/issues with your already impressive graphs and data to show the benefits/disadvantages and how-to of this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope even with cache disabled 🤔
I meant it wont work with cache disabled 😅. But if it wasn't disabled earlier then definitely something is off 🤔
I'm also ok merging this, and we can always see later how it goes 🤷
But I kind of would like a more wider discussion on async components, so we can all decide to go the same direction?
Sounds good 👍🏻
Would you be up to create a thread on https://github.com/nextcloud/standards/issues with your already impressive graphs and data to show the benefits/disadvantages and how-to of this?
Will do. Never knew about this repo. I think most of the overhead is coming from nextcloud-vue
at this point; desperately need tree shaking in there. If that can be fixed then lazy loading components would be pointless to begin with (happy dance).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do. Never knew about this repo. I think most of the overhead is coming from
nextcloud-vue
at this point; desperately need tree shaking in there. If that can be fixed then lazy loading components would be pointless to begin with (happy dance).
This is on purpose, a bit more discrete to not become the place to discuss any thoughts. I think important topics like those should indeed be brought up there 👍
f229755
to
8ad8710
Compare
Signed-off-by: Varun Patil <[email protected]>
8ad8710
to
f9e9688
Compare
Filerobot bundles konva and react, and is absolutely massive. This is a very preliminary step, there's a lot more that could be cut down.
Related (but no dependency): nextcloud/server#38329