Open bbbbaum opened 1 year ago
Is there a use case for these original size files that get converted even if they are not specified in the widths array?
This is a side effect of densities, where densities has the original image as a 1x density.
I'll have to think about how to handle this for widths, because the way the API is designed works perfectly for img
and densities, where you have one "main" image in src
and other variants in srcset
(or for the latter, all images in srcset
), but for picture and widths, it definitely does generate more images than it should, hmm
I'm not sure about the added .jpg, it seems like it's not an encoded image? Is it possible it's just the original assets? Those are currently copied in the bundle for various technical reasons (but don't slow down builds in any ways)
Is the proper file used for element's src attribute? Even if the idea is to use an original-sized image, is it possible to just copy the original file instead of encoding a new one?
You typically don't want this, because the processing will still result in a smaller image than the original.
I'll note that if your concern is build speed, in addition to having caching between builds, we're currently working on improving performance in the following PR https://github.com/withastro/astro/pull/8821
Those are currently copied in the bundle for various technical reasons (but don't slow down builds in any ways)
Need an option to disable this behavior and not copy the original images into the build. For example: I have original images sized 3840x2160 and about 10MB in size. In the project using , they are displayed at a resolution of 300 pixels (50KB). There are many such photos on my website. Not only generated images are included in the build, but also the originals. Instead of the usual 100MB, the site takes up 20GB, forcing me to pay for a more expensive hosting plan and causing inconvenience during copying.
The option to exclude the original or to set a maximum image size in bytes would be very welcome.
Hi, I am also facing this issue of having redundant original images in generated _astro
assets folder when using the <Picture/>
component.
If it is kept for potential later use as mentioned here if I understand correctly, it imho and experience consumes a lot of resources just for this case - disk space, build time processing, also when using available image optimizing astro integrations.
I agree with the idea that the safekeeping image should be the original image in src
folder, where I keep the to-be processed images anyway; at least for static websites - not sure about SSR, as I am focusing on SSG sites.
For now I guess this workaround should work for me, but I am all for removing the redundant images from the astro assets. I also experimented with the getImage
function a bit and I believe I had those redundant images also in server
assets (I noticed them initially there), not only client
assets, ie in hybrid mode - so that kind of even tripled the assets.
Astro Info
If this issue only occurs in one browser, which browser is a problem?
No response
Describe the Bug
Astro picture component with widths parameter does some additional image conversions that results in additional files that don't appear to be used in the resulting
<picture>
element.Example:
For the following Picture component:
Astro generates 19 images, across three formats:
6 avif images:
6 webp images:
7 jpeg images:
However, when inspecting the resulting
<picture>
element:we only reference 16 out of 19 files.
The files that do not get referenced:
Two questions:
<img>
element'ssrc
attribute? Even if the idea is to use an original-sized image, is it possible to just copy the original file instead of encoding a new one?A bit of context: I have a somewhat larger blog with plenty of images that I'm optimizing with an out of date Astro integration, but I'm investigating how Astro's new native Picture solution works and this behavior negatively impacts the build times for no apparent use.
Here's a repo with the code for the Minimal Reproducible Example: https://github.com/bbbbaum/srcset-behavior-investigation
What's the expected result?
Probably the ideal solution would result in 16 images: 15 resized according to the widths list + 1 original file copied from the assets folder.
Link to Minimal Reproducible Example
https://flourishing-souffle-008245.netlify.app/
Participation