New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Entrypoint size exeeds the recommened limit (250kB) #3486
Comments
@xianshannan The warning is pretty much explanatory. But you can turn it off by adding |
It is just a warning but like @jmalonzo said this can be changed with performance: { hints: false } |
@jmalonzo @TheLarkInn Thinks a lot! It did work. I tried |
Could this be kept open as a docs bug? There's no mention of |
We have an issue on it on our docs page. Here's the PR in review. Hopefully this helps!!! |
An aside, Although it is subjective we'd recommend using it for dev as well! (But maybe set high size limits) that way developers dont have to be caught off guard by performance errors that could be caught in the act during dev vs prod builds. |
What do you think about disabling this by default for development builds? Developer mode build ( |
This is the problem I had - the warning is kinda relevant, but as long as I set the NODE_ENV and run DCE in production the resulting bundle should be fine. |
So far I have solved my problem with the following configuration performance: {
hints: process.env.NODE_ENV === 'production' ? "warning" : false
}, Don't think any sense to show developer the size of the build with developer-warnings, hot-reloading runtime, a stuff, that is not included in production builds, where the size matters. |
I just ran into this issue as well. Having this error on by default seems, IMO, to be somewhat presumptuous as it is making a lot of assumptions about the users environment.
Any thoughts about turning this off by default? |
I think on by default is sensible, otherwise no-one will know to turn it on. Perhaps the warning should include a link to the docs for how to turn it off / change the limit? |
That would definitely help! But still -- it seems like Webpack has many features that could benefit users if they only knew to use them. When the time comes, thanks to sections like |
I would have to agree with @damassi |
I get three(!) warnings for a .js.map file being too large. Of course it's large, it's a map file.
You're not helping. |
I win! I get six(!) for a vendor bundle that goes over. Everything that gets chunked after the bundle that exceeds the limit seems to cascade a bunch of more warnings. Although, I believe even if they fixed this to become one warning, it would still be unwanted spam. It simply needs to be turned off by default to reduce the clutter and the unnecessary fear that this sort of message is going to induce in new programmers.
|
I recognize that this is a closed issue, but an important thing to note about this issue is that it seems to incorrectly include sourcemap in the total calculation. Either that, or it is happening too early in the stack and including the size before plugins such as the CommonsChunkPlugin, etc. which greatly reduce the actual size. This warning should really only be based on the actual final size of the output bundles, imho. I am seeing this warning with final bundles that are less than 50k, but if you include the size of a full sourcemap it's around 1mb and it's cluttering my log. Turning it off in dev is fine, but I don't think this feature is at all useful if it's not going to calculate the size of the actual bundles correctly. |
Can someone reopen to continue discussion? At the very least there are some edge-cases around this issue that need to be smoothed out. |
We are tracking The discussion in the original "Performance Budget" issue. Id send the link but I'm on my phone currently 😅 |
@TheLarkInn 👍 Moseying over there |
Thanks guys! |
Hi guys i got this error please help me anyone
Please help me guys SOS |
Could someone enlighten me on why there is a warning at all about entrypoint size? If a webapp requires X size of scripts in order to function, then that is just what it is. You can't do anything about it. For example if you have a big web app that requires 500kb of JavaScript on page loads, you can't really escape from that. There may be places where you can optimize via dynamic imports, but if you can't then you just can't. Right? You can give someone performance hints all day long but it doesn't mean people are always able to abide by those hints/rules for their web app. |
Landed here from Google as I wanted to see if the warning was significant and if there was anything I could do to improve the size - I'm a stickler. But reading this issue is madness. There is an argument both for and against this warning. In my opinion the warning should be kept IF there is sufficient documentation that can advise the user on how to reduce the size. Otherwise it's pointless because there is nothing the user can do to address the warning. For new users it will lead to frustration. I'm an advanced user and warnings don't sit well with me. They lurk in my mind and cause too many questions about my competence. But maybe that's just me. If there's no docs to support the warning it should defiantly be removed. That's my 2 cents. |
Because if your app requires 5MB to work, then (new) visitors will be staring at a blank white page wondering how long to wait, as it loads. A better way to do things is to have a very small loading "splash" screen. A new visitor will then be greeted by this screen almost immediately, while the bulky stuff loads up in the background. You might even consider a progress bar as the chunks load in. |
I fully understand the downsides to loading a 5MB web page. Just doesn't seem like it should honestly be webpack's responsibility to warn about stuff like this. I dunno. The entry point limit recommendation value is pretty arbitrary too and slowly will increase as time goes on (faster internet, etc). |
being this is completely configurable, i would say it is a positive feature. if you don't care how large your entry is, turn it off! if you do care and want to be notified, set the limits to what you expect. this way if you have new devs on your team and they add some absurdly large package to do an absurdly straight forward task... it'll fire off a warning! quite useful, actually. edit: it also keeps you honest and gives you goals to shoot for... once your entry is getting too large it is time to start splitting files |
I'm still confused. Other than to disable the warning what should I do with the warning? Mine says... Does this mean I should do something different? Or does it just mean "Oh, cool you have a really big app!". In that case it seems utterly meaningless. |
如何优化呢 |
in webpack config: performance: {
maxEntrypointSize: 512000,
maxAssetSize: 512000
} |
Try this one |
After years of this, there still isn't any explanation of what one is to do about these messages except turn them off. You still see people filing issues about this everywhere on the net. A 250k limit in 2021 is particularly intrusive. Think of all the human time wasted on this! This warning should be turned off by default, or raised to something generous, like 4M. |
Just make the 250k value a configurable option for the user.... different use websites and different use cases could use different configurable threshold values. |
Had you read the dialog above, it *is* configurable. Of course, there's no
hint anywhere what a good number for this actually is.
Hundreds of thousands of people get this message and are confused. 250k is
tiny tiny tiny in 2021. It should be turned off my default.
…On Wed, Aug 18, 2021 at 1:20 AM Jake Wilson ***@***.***> wrote:
Just make the 250k value a configurable option for the user.... different
use websites and different use cases could use different configurable
threshold values.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3486 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB53MRUHD5BHIVLGNG4BTDT5LVENANCNFSM4CZXEUFA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
--
/t
PGP Key: ***@***.***
*https://tom.ritchford.com <https://tom.ritchford.com>*
*https://tom.swirly.com <https://tom.swirly.com>*
|
Seriously - I have a barebones React app that does almost nothing, and I'm not sure if I'm doing something wrong or could do more to optimize, but even in production mode, just pulling in some basic libraries (things like react, react-dom, immer, reselect) puts me over the limit. |
I have the same question as clearly kindly described by so many people @JamesTheHacker @RobertGary1 @rec @adamsmasher. But there is still no reply from maintainers. We want to know how to really solve this problem, not just disable it! |
you can split chunk ( using Also make sure that tree-shaking works in your case. |
@vankop: An easier solution would be to turn off the bogus warning message. |
you can use warning filter https://webpack.js.org/configuration/stats/#statswarningsfilter |
Literally millions of people use webpack, and nearly all of them are using it transitively as part of another package. The only interaction I have ever had with webpack was this bug. To push the problem onto the users means some big chunk of these millions of people to spend half an hour discovering what webpack is, find this setting, change it, test the results and commit it - simply to handle this bogus warning message. A better possibility is to have one person remove the bogus warning, and another person review it, and commit it, so instead of wasting hundreds of thousands of people's time, ongoing, for the rest of time, two people spend a tiny bit of time, and it's all over. |
Basic idea of this warning is to help new users ( or users that see this warning first time ) to help them improve UX of there application. For other users there are different stats options to play around.. I, personally, understand that warning could be annoying and create extra noise, so we trying to add only really needed warnings and make them useful. |
Thanks for the fast and thoughtful responses! :-)
On Mon, Apr 4, 2022 at 12:03 PM Ivan Kopeykin ***@***.***> wrote:
Basic idea of this warning is to help new users ( or users that see this
warning first time ) to help them improve UX of there application.
But it fails at that idea, unfortunately. If you're a beginner and you get
this issue, it's almost certainly because some package you are using has a
"large" component, and there's nothing you can do about it.
More, the threshold is set so low that it's triggered all the time.
Instead, this warning trains new users to *ignore* warnings. :-/ It
encourages the eye to glide over the many warnings as long as the build
actually completes.
Life is short. Researching why you're getting some strange webpack error
and suppressing it wastes a little time from an immense number of people.
… For other users there are different stats
<https://webpack.js.org/configuration/stats/> options to play around..
I, personally, understand that warning could be annoying and create extra
noise, so we trying to add only really needed warnings and make them useful.
—
Reply to this email directly, view it on GitHub
<#3486 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB53MQWCTJWOVE3BSYLUVDVDK47RANCNFSM4CZXEUFA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
/t
PGP Key: ***@***.***
*https://tom.ritchford.com <https://tom.ritchford.com>*
*https://tom.swirly.com <https://tom.swirly.com>*
|
To @vankop: (Apologies for just tagging you, this message is for all maintainers)
No, this is not the point! The problem is that: we don't know that is just a noise!Intuitively people who care their products will think that there will be some instructions to follow to solve this ERROR. Here are some of the (so many!) examples:
We, naive developers, don't have that much background knowledge like you, the maintainers. So we will think that we've done something wrong even if it is displayed as a WARNING, which can be turned off. Do you get my point? We have to first realize that this is not that important before we will make the decision "OK, this is safe to turn off."
In my case, I had spent two days on this message: I was trying to create extra entrypoint just to decrease their size. I finally stopped trying after I read though the thread #3216 to understand the intention of this WARNING. So, please, put a note aside the warning to notify people that this warning is not that serious before setting the threshold themselves! Sincerely, Rain |
@nyngwang just went through the same conundrum. |
@nyngwang I had the exact same experience here. I believe the default size needs to be 512kb. When you are learning React and configuring it for the first time using Webpack and receive this warning, it is definitely not fun. I initially believed that I had done something incorrectly, but I later learned that there isn't really a recommended package size. It was really perplexing to see the Webpack warning. |
I use webpack@2.1.0-beta.27,it do not have the warning before.
The warning comes after installing all the package again.It would be great appreciated ,if there any solutions.
The text was updated successfully, but these errors were encountered: