As you can see, hundreds of instances of node_modules/image-webpack-loader/index.js?{"gifsicle":{"interlaced":false},"optipng":{"optimizationLevel":7},"pngquant":{"quality":"50-70","speed":1},"mozjpeg":{"progressive":true,"quality":60}}! over and over and over again make it into the final production build. It’s actually taking up a significant portion of my codebase. While this gzips pretty efficiently with all the repetition, I’d rather it not be in the output as it doesn’t seem to be helping users.
The images themselves are optimized, minified, and spit out by srcset-loader just fine, but I’m wondering why all this makes it into my final bundle.
Versions:
This is my loader setup for image files, pairing srcset-loader with image-webpack-loader
This is what gets output in my minified, production bundle (truncated):
As you can see, hundreds of instances of
node_modules/image-webpack-loader/index.js?{"gifsicle":{"interlaced":false},"optipng":{"optimizationLevel":7},"pngquant":{"quality":"50-70","speed":1},"mozjpeg":{"progressive":true,"quality":60}}!
over and over and over again make it into the final production build. It’s actually taking up a significant portion of my codebase. While this gzips pretty efficiently with all the repetition, I’d rather it not be in the output as it doesn’t seem to be helping users.The images themselves are optimized, minified, and spit out by srcset-loader just fine, but I’m wondering why all this makes it into my final bundle.
Is there any way to avoid this behavior?