Scripts: Add support for static assets in build commands #28043
Conversation
gziolo
added
[Package] Scripts
gziolo
changed the title
|
Size Change: 0 B Total Size: 1.3 MB ℹ️ View Unchanged
|
| // smaller than specified limit in bytes as data URLs to avoid requests. | ||
| loader: require.resolve( 'url-loader' ), | ||
| options: { | ||
| limit: 5000, |
There was a problem hiding this comment.
We can either remove this limit and use files only, but we can also tweak this value.
There was a problem hiding this comment.
My experience when testing this was that no matter the limit, as long as the image was base64 encoded instead of being a file, the size increase of the css was always larger than the actual image file size.
I also think the browser needs to work more with painting the base64 encoded image then an image file. But that is mostly me guessing 😅
Thanks for looking into this. I never got the time to come up with this pr
There was a problem hiding this comment.
Gutenberg doesn't process static assets this way so I have no idea. That's why I'm waiting for feedback from folks that have some experience 😄
There was a problem hiding this comment.
@kimmenbert Due to how base64 encoding works the resultant inline image will be bigger than the original image file size, but the trade off is reducing the number total requests.
Keeping the limit to small (5kb) images or less is probably reasonable trade-off for increased CSS to outweigh the extra network call to an individual file.
There was a problem hiding this comment.
@aristath, you are working on similar explorations for CSS in core. What would you recommend here?
There was a problem hiding this comment.
@aristath, you are working on similar explorations for CSS in core. What would you recommend here?
I'm still catching up so I don't know if this has already been implemented somewhere, but ideally, we'd have path resolution in the theme.json file.
Then we'd be able to define the files as CSS-variables in there, and use the vars in our CSS.
In an HTTP/2 and beyond era it would be more efficient to load multiple smaller files than bundle images inside the main stylesheet.
base64-encoding is possible, but the result is always inefficient and resource-intensive both for network traffic and rendering since the end result is slightly larger in byte-size and the browser needs to decode it before rendering.
Inlining images in CSS would be something I'd only recommend for small SVG images. They don't need to be encoded and they are usually < 1kb (actually most times they're no more than a few bytes if we're talking about small background vectors).
There was a problem hiding this comment.
This config isn't targeting Gutenberg itself. It's for plugins and themes that want to use the same tools to build their products. I don't know if what you shared is relevant in this context but as I understand we should rather avoid inlining images into CSS. I will update code accordingly. We can always change that later, it's less important part of this proposal.
There was a problem hiding this comment.
efaa301 changes the loader to file-loader so it works the same way as for fonts. No more inlining for start.
There was a problem hiding this comment.
Note: to get it to work I needed to use:
npx @wordpress/create-block my-block --no-wp-scripts
cd my-block
npm install file-loader
And then I could run ../gutenberg/node_modules/.bin/wp-scripts build and it all worked as expected.
The file-loader module will get loaded once this gets published out, so I don't think it is any concern and everything else worked copying and referencing as expected. 👍
Great quick work @gziolo
gziolo
force-pushed
the
update/scripts-build-assets
branch
from
2eeaafd
to
efaa301
Compare
|
Will this work with SVG fonts, such as Font Awesome? |
|
There was svg support before. I don't know if it works with font awesome to be honest. We can do a follow up PR if it isn't working after we publish it in less than 2 weeks. |
|
My solution is basically the same solution as yours but with one major difference. It's just an example to illustrate the issue but I'm sure it's a pretty common use-case. |
|
@AlenRedek, can you open an issue that explains this use case in-depth so more folks could discover it and help resolve? I think @mkaz added an initial handling for SVG so he might have a better idea how to tweak it. |
Description
Fixes #27581.
Related to #27749.
As explained by @kimmenbert:
With this PR is possible to reference font (
woff,woff2,eot,ttfandotf) and image (bmp,png,jpg,jpegandgif) files from CSS that is controlled by webpack as explained in the previous section.Example:
How has this been tested?
You can create a test block with the following local command:
npx wp-create-block my-block --no-wp-scripts cd my-blockThen you can modify one of the CSS/SCSS files and add references to fonts and images.
To build with the modified version of
wp-scriptsyou need to run it as follows:and
Screenshots
Source file
Build file
Build folder
Types of changes
Checklist: