Repository navigation
Disable inline images for images that are less than 10,000 bytes #3437
Description
Thanks for this awesome project.
I recently get a warning during build telling me:
The bundle size is significantly larger than recommended.
Consider reducing it with code splitting: https://goo.gl/9VhYWB
You can also analyze the project dependencies: https://goo.gl/LeUzfb
Analyzing the project dependencies, I discovered that the easiest and most significant improvement would be to get rid of these small images under 10,000 bytes that are imported as Data URI by webpack (it's 25% of the size of my app).
I don't see an option to disable the feature. Does it exists? If no I have currently 2 options that are:
- moving the images in the public folder
- ejecting the app
Both options are a big loss so an option to change the current behaviour would be nice.
Thanks for your help
Activity
nicgirault commentedon Nov 10, 2017
I propose to do a pull request to add an environment variable that would be used here: https://github.com/facebookincubator/create-react-app/blob/36cd35d684f6f0eda971b30c789010758fc61ceb/packages/react-scripts/config/webpack.config.prod.js#L166 and here https://github.com/facebookincubator/create-react-app/blob/70e0c08ef7de8845b1a4c6700822e27e45b481a8/packages/react-scripts/config/webpack.config.dev.js#L159 and would fallback to 10000.
Timer commentedon Nov 10, 2017
Intriguing use case.
Even if this shaves off 25%, that means your bundle is still huge. If you split the application, the inlined images should also be split and distributed across the bundles.
Let's see what others have to say, but the third option is what I just mentioned.
edit: this option currently cannot be modified or disabled
edmorley commentedon Mar 15, 2018
Another point to consider when using url-loader's inlining: small changes in either CRA's chosen threshold, or asset sizes in an app can mean a previously working Content-Security-Policy ends up blocking newly-inlined assets due to lack of
data:in theimg-srcCSP policy directive.For sites that have correct long-lived cache control headers (especially those remembering to use the
immutabledirective), and aren't as concerned about the initial cold cache case, IMO never inlining is preferable.peterbe commentedon Dec 18, 2018
Here's another attempt to solve this: #6060
It's similar to the idea of
INLINE_RUNTIME_CHUNK. Now, runningIMAGE_INLINE_SIZE_LIMIT=0 yarn run buildwill mean that every image in (src/*.(bmp|gif|jp?eg|png)) will be considered too big and not base64 into the JS.mzvast commentedon Jan 10, 2019
Any progress on this proposal?
peterbe commentedon Jan 10, 2019
My PR is conflicting now but I'm not sure how to ping/pester it for review.
environment variable to disable inlining images
andyfurniss4 commentedon Mar 14, 2019
Adding my name to this because I don't want my images inlined!
Rogdham commentedon Mar 15, 2019
Websites dealing with CSP will likely add
data:in the CSP header because of the inline images (something likeimg-src 'self' data:;). MDN states that this is not recommanded and can be insecure (emphasis is mine):The alternative for CSP is using a nonce-based approach, but it has the following drawbacks:
__webpack_nonce__is not applied toimgtags (this may be a bug);data:will need to be present in the CSP header anyways for CSP version 1;All in all, it would be way simpler to just have an option to disable inline images. #6060 gets my +1 👍
peterbe commentedon Mar 15, 2019
Messing with CSP just to bend-over-backward for this "flaw" in CRA isn't the right direction. I still think my pr should get reviewed and landed. And perhaps it should be changed to make the default minimum 0 bytes, meaning you have to deliberately set an env var if you want base64 inlining.
Hey! If you're here and also don't want base64 inlining you can...
src/*.jsdon't do this:Instead, do this:
src/App.jsdon't do this:do this instead:
You'll also need to
git mv src/foo.png public/static/images/or whatever is equivalent in your project.some1else commentedon Apr 1, 2019
But I want the images loaded, checksummed, optimized and whatnot. I just don't want them inlined. In my use case long strings are problematic (using React to render multipart emails).
some1else commentedon Apr 1, 2019
Hopefully #6060 gets the stamp of approval
Kizmar commentedon Apr 10, 2019
Pile on reason: I realized a .png was being added as "data:" instead of using a path. At first I thought it was the file type because the same image as a .jpg worked. I don't want to have to add "data:" to my CSP as it's not recommended for security reasons. I'd like to be able to basically disable this feature all together and always use the image path.
imyoka commentedon May 16, 2019
Adding my name to this because I don't want my images inlined!
fredrivett commentedon Jun 12, 2019
We're in the exact same position as @Kizmar, images are being converted to
data:with base64, which our CSP is blocking. It's not advised to allowdata:URIs as content source,as MDN says:Ideally there would be a solution that enables us to keep our sites secure whilst still utilising the standard image processing (just without the base64 step).
Add environment variable to control image inlining threshold (#6060)
Add environment variable to control image inlining threshold (react#6060
Add environment variable to control image inlining threshold (react#6060