Skip to content
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

Imports are not considered for page-based code splitting #1632

Closed
Bastian opened this issue Jun 3, 2021 · 5 comments
Closed

Imports are not considered for page-based code splitting #1632

Bastian opened this issue Jun 3, 2021 · 5 comments

Comments

@Bastian
Copy link

Bastian commented Jun 3, 2021

Describe the bug
When importing a library on a single page, it's bundled in the vendor-<hash>.js file and loaded on every page.
This has not been the case with Sapper.

To Reproduce

I've created two example projects, one with Sapper and one with Svelte-Kit.
They can be found here:

On both projects, I've imported the moment.js library, as it has a large and noticeable bundle size (~20kB gzipped) but every other library would show the same result. The library is imported on the About page and nowhere else. I've recorded a video that shows the Chrome dev tools when loading the page and then navigating to the About page:

Here's how it looks like in Sapper where the automatic code-splitting is working:

sapper-codesplitting.mp4

And here's Svelte Kit where the complete bundle is loaded immediately:

sveltekit-codesplitting.mp4

You can clearly see that in Sapper the ~20kB gzipped bundle is only loaded when navigating to the About page whereas in Svelte-Kit it's loaded immediately (included in the vendor-<hash>.js file).

Expected behavior

Automatic code splitting should make sure that the library is only loaded on pages that import it.

Severity

Not severe but an inconvenience with a non-neglectable impact on performance.

Additional context

You can enforce code-splitting by using dynamic imports. While this is a good temporary solution to mitigate the impact of larger libraries, doing this for every single imported library would be a major inconvenience and result in a lot of unwanted boilerplate code.

@benmccann
Copy link
Member

benmccann commented Jun 3, 2021

#1571 might solve this for you. Once that's checked in you should be able to disable the vendor chunk by setting Vite's build.rollupOptions.output.manualChunks to undefined

@Bastian
Copy link
Author

Bastian commented Jun 3, 2021

This indeed looks like what I want. Thank you for linking to the issue!

I'm curious though: Is there a reason why Vite opted to default to this behavior? To me this seems like a bad idea since you quickly accumulate a pretty large vendor file this way. Even in my fairly small project I have many dependencies that are only relevant for a single page and I guess that this becomes an even bigger issue for larger websites. This doesn't sound like something I would ever want except in a few edge cases. Am I missing something here?

@benmccann
Copy link
Member

I'd tend to agree it's not a good default and notice Rich suggested the same. Once #1571 is addressed you can play around with other values to determine if they work as desired and then it's probably worth an issue in the Vite repo to see if the default can be improved.

@benmccann
Copy link
Member

Here's a related Vite issue: vitejs/vite#3731

@Rich-Harris
Copy link
Member

Looks like this can be closed, since Vite's behaviour changed to not create vendor chunks by default

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants