Run & review this pull request in StackBlitz Codeflow.

I really like this PR because I have done it manually. 😁

This PR transform URL will during at the CSS transform time, but as a user, my favorite thing to write is that different Vue SFCs refer to the same resource. Would it be better to replace them at the render CSS chunk time.

My use case like:

a1.vue

<style scoped>
.bg-1 {
  background: url('../1.png');
}
</style>

a2.vue

<style scoped>
.bg-1 {
  background: url('../1.png');
}
</style>

and use the two compoent in one compoent

<template>
<A1 />
<A2 />
</template>

I guess now will output like

:root{
  --base64-hash1: url(...)
}

.bg-1[filehash-1] {
  background: var(--base64-hash1);
}

:root{
  --base64-hash1: url(...)
}

.bg-1[filehash-2] {
  background: var(--base64-hash1);
}

I think better is

/* inject the css var map in renderChunk? */
:root{
  --base64-hash1: url(...)
}

.bg-1[filehash-1] {
  background: var(--base64-hash1);
}

.bg-1[filehash-2] {
  background: var(--base64-hash1);
}

This seems a good PR to bring attention to this one also: #4454

There is a lot of developers hoping Vite will implement an option to emit assets rather than base64-inlining everything.

It's worth noting that base64 inlining has many downsides, which includes:

• +30% size vs the native format of the jpeg, svg, font, etc. This increases payload size of js and css.
• Parse time is increased for css and js, as it has to decode the base64 each time
• Slower build times, as it needs base64 huge payloads into js and css
• This PR shows another problem: it's difficult to diagnose issues in the css output. It's possible that this PR may not be all that beneficial if assets have already been emitted externally and referenced by standard files, rather than css variables.

yes, svg it seems to can export data:image/svg+xml;charset=utf8, 👀

and other asset should provide config to config the asset is inline or single?

This PR transform URL will during at the CSS transform time, but as a user, my favorite thing to write is that different Vue SFCs refer to the same resource. Would it be better to replace them at the render CSS chunk time.

Good point. I think we can transform base64 to css-variable in transform time and emit a extra CSS file containing these variables in :root scope during renderChunk

There is a lot of developers hoping Vite will implement an option to emit assets rather than base64-inlining everything.

I think this is another issue. Let's focus on the minimization of base64 in this PR

This PR transform URL will during at the CSS transform time, but as a user, my favorite thing to write is that different Vue SFCs refer to the same resource. Would it be better to replace them at the render CSS chunk time.

Good point. I think we can transform base64 to css-variable in transform time and emit a extra CSS file containing these variables in :root scope during renderChunk

👍 make sure the logic is not run in the dev serve. I think renderChunk is not export in dev serve.

@poyoho cc

What is the bundle size impact when the assets are used only once?

I totally get the benefits when the asset is imported twice, but IMO most of the assets are not duplicated. Plus with gzip, the only downside should be parsing time.

Also does this is fine to have few kB in CSS vars? Maybe browser didn't expect this usage (and since I read this article I never trust my feelings on browser perf)

I totally get the benefits when the asset is imported twice, but IMO most of the assets are not duplicated. Plus with gzip, the only downside should be parsing time.

We might add an option called build.base64Minify, when the user needs it then turn it on.

Also does this is fine to have few kB in CSS vars? Maybe browser didn't expect this usage

I think it's fine, or do you have some articles that prove me wrong?

I didn't test anything and I think also this should be fine, but my point is that sometimes you can hit an unexpected performance issue