[vite-plugin-svelte] prebundle libraries / ssr compile stats show large numbers

dominikg commented 2 years ago

This is not a bug in carbon-components-svelte, posting here for visibility and as a heads-up for the maintainers and users.

In version 1.3.0 , vite-plugin-svelte is going to enable prebundling for svelte dependencies during dev by default. Alongside, it is going to log compile statistics so users can understand where time is spent.

For a sveltekit application with carbon-components-svelte and carbon-icons-svelte this can look like

1:54:40 PM [vite-plugin-svelte] prebundle libraries in progress ...
1:54:55 PM [vite-plugin-svelte] ssr compile in progress ...
1:55:05 PM [vite-plugin-svelte] prebundle libraries done.
package                         files     time     avg
carbon-icons-svelte              2002   11.30s   5.6ms
carbon-components-svelte          206    2.68s  13.0ms
1:55:05 PM [vite-plugin-svelte] ssr compile done.
package                                 files    time     avg
carbon-icons-svelte                      2002   2.92s   1.5ms
carbon-components-svelte                  206   0.60s   2.9ms
playground-big-component-library-kit        3   9.8ms   3.3ms

and delay initial page load of the dev-server by multiple seconds.

Using the optimizeImports preprocessor in combination with prebundling can make it a lot worse even.

For using carbon with vite-plugin-svelte 1.3+ it is recommended to either not use optimizeImports and stick to one import style or exclude carbon from optimizeDeps as described in the vite-plugin-svelte FAQ

benmccann commented 2 years ago

It may be worth thinking about how carbon-icons-svelte is setup. I've been using svelte-awesome for icons and it is very fast as it only has ~5 .svelte files. That could possibly be a better approach than generating lots of .svelte files

dominikg commented 2 years ago

carbon icons are also available via unplugin-icons, so if you can build a config for that that works out to a similar interface as the current carbon-icons-svelte package, carbon-icons-svelte would no longer be needed as a separate package and instead users projects would only compile/bundle the icons they actually use. Kind of like deep imports without the extra package.

// vite.config.js
import { defineConfig } from 'vite'
import { svelte } from '@sveltejs/vite-plugin-svelte' // or sveltekit
import Icons from 'unplugin-icons/vite'

export default defineConfig({
  plugins: [
    svelte(), // or sveltekit
    Icons({
      compiler: 'svelte',
      // TODO: add extra config here so compiled icon is similar to what carbon-icons-svelte has now
    }),
  ],
})

<script>
import IconAccessibility from '~icons/carbon/accessibility'
</script>
<IconAccessibility/>

benmccann commented 2 years ago

I'm not a big fan of the unplugin-icons approach as I'm not sure enterprise environments would let you download things on demand in their CI environments

dominikg commented 2 years ago

I'm not a big fan of the unplugin-icons approach as I'm not sure enterprise environments would let you download things on demand in their CI environments

you don't. you add a dependency on an iconify library, basically a json file with all svgs. it's just a bit clever glue to turn that json into a svelte component on demand

theetrain commented 1 year ago

I ran some somewhat-scientific tests and here is what I've uncovered:

carbon-components-svelte runs very slow with vite dev whenever SCSS is involved
using plain CSS, even the gigantic all.css (without using purgeCSS) is much more performant

This is concerning since Carbon v11's de facto styles involve SCSS exclusively. I haven't measured Carbon v11 React, so I'm unsure how things perform there.

Below are my test results. There were some inconsistencies:

After the 1m38s reloads, HMR wouldn't work until I refreshed the page for another 1m38s, which is why some HMR results are very long

Test project: https://stackblitz.com/edit/sveltejs-kit-template-default-upbce6?file=src%2Fapp.scss,src%2Froutes%2F%2Bpage.svelte

On Stackblitz

Test Run	Using SCSS	Using CSS	Index imports	Deep import	vite .optimizeDeps .exclude	Reported time by vite-plugin-svelte	Actual render time	First HMR	Second HMR
1	Yes	No	Yes	No	Yes	1.58s	1m48s
2	Yes	No	Yes	No	No	1.39s	1m44s	3m11s	< 1s

Locally on 2015 Macbook Pro, on battery

Test Run	Using SCSS	Using CSS	Index imports	Deep import	vite .optimizeDeps .exclude	Reported time by vite-plugin-svelte	Actual render time	First HMR	Second HMR
1	Yes	No	Yes	No	No	1.39s	1m36s	1m10s	< 1s
2	Yes	No	Yes	No	Yes	1.46s	1m29s	1m8s	< 1s
3	Yes	No	No	Yes	No	0.16s	1m38s	2m37s	1m17s
4	Yes	No	No	Yes	Yes	0.17s	1m34s	30s	< 1s
5	No	No	Yes	No	No	1.17s	14s	30s	< 1s
6 🎉	No	Yes	Yes	No	No	1.49s	5s	<1 s	< 1s

Is there a way for us to improve performance when SCSS is involved? Perhaps there's a more efficient usage of SCSS that I've overlooked in the test project linked above.

benmccann commented 1 year ago

@theetrain would it be possible for you to preprocess the library and distribute just CSS? That's what we typically recommend svelte libraries to do and I believe if you use svelte-kit package it will do it for you. Then you can still author components with SCSS, but users won't need to incur the cost of processing it

carbon-design-system / carbon-components-svelte

[vite-plugin-svelte] prebundle libraries / ssr compile stats show large numbers #1561

On Stackblitz

Locally on 2015 Macbook Pro, on battery