Skip to content
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

Closed
samonxian opened this issue Dec 15, 2016 · 47 comments
Closed

Entrypoint size exeeds the recommened limit (250kB) #3486

samonxian opened this issue Dec 15, 2016 · 47 comments

Comments

@samonxian
Copy link

samonxian commented Dec 15, 2016

WARNING in asset size limit: The following asset(s) exceed the recommended size limit (250 kB). This can impact web performance. Assets: bundle.js (10.3 MB)

WARNING in entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (250 kB). This can impact web performance. Entrypoints: app (10.3 MB) bundle.js

WARNING in webpack performance recommendations: You can limit the size of your bundles by using System.import() or require.ensure to lazy load some parts of your application. For more info visit https://webpack.js.org/guides/code-splitting/

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.

@samonxian samonxian changed the title Entrypoint size exeeds this limit Entrypoint size exeeds the recommened limit (250kB) Dec 15, 2016
@jmalonzo
Copy link

@xianshannan The warning is pretty much explanatory. But you can turn it off by adding performance: { hints: false } to your webpack config.

@TheLarkInn
Copy link
Member

It is just a warning but like @jmalonzo said this can be changed with performance: { hints: false }

@samonxian
Copy link
Author

samonxian commented Dec 15, 2016

@jmalonzo @TheLarkInn Thinks a lot! It did work. I tried stat: { warning: false } before,it did not work.In ther API,i didn't find the performance: { hints: false }.

@glenjamin
Copy link

Could this be kept open as a docs bug? There's no mention of performance in the configuration docs. Ideally I'd have this on in my production build but not in dev.

@TheLarkInn
Copy link
Member

We have an issue on it on our docs page.

Here's the PR in review. Hopefully this helps!!!

webpack/webpack.js.org#500

@TheLarkInn
Copy link
Member

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.

@just-boris
Copy link

What do you think about disabling this by default for development builds?

Developer mode build (NODE_ENV=development) React+React-DOM+React-router gives me 1.1Mb bundle. But the warning doesn't make any sense, because with NODE_ENV=production, bundle size will be reduced and everything will be fine.

@glenjamin
Copy link

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.

Developer mode build (NODE_ENV=development) React+React-DOM+React-router gives me 1.1Mb bundle. But the warning doesn't make any sense, because with NODE_ENV=production, bundle size will be reduced and everything will be fine.

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.

@just-boris
Copy link

just-boris commented Dec 16, 2016

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.

@damassi
Copy link

damassi commented Dec 20, 2016

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.

WARNING in asset size limit: The following asset(s) exceed the recommended size limit (250 kB).
This can impact web performance.

Any thoughts about turning this off by default?

@glenjamin
Copy link

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?

@damassi
Copy link

damassi commented Dec 20, 2016

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 Optimization in your docs, they discover them and turn them on. This seems no different. JS runs in so many different environments, all with different perf standards / requirements. Default warnings seem most helpful when you can be totally certain that your assumption is global.

@ZenSoftware
Copy link

ZenSoftware commented Dec 20, 2016

I would have to agree with @damassi
It really does seem like this particular feature is being overly presumptuous. A default, should be a default if it accommodates for the most common scenario. This really does not seem like it is the case. This warning, in many cases, will be simply unwanted spam. It is not to say that we don't see that value in this feature. It's just that the output for these kinds of tools are already crowded enough without the presumptuous spam.

@bjornstar
Copy link

I get three(!) warnings for a .js.map file being too large. Of course it's large, it's a map file.

WARNING in asset size limit: The following asset(s) exceed the recommended size limit (250 kB). 
This can impact web performance.
Assets: 
  loader.js.map (539 kB)

WARNING in entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (250 kB). This can impact web performance.
Entrypoints:
  main (614 kB)
      loader.js
      loader.js.map


WARNING in webpack performance recommendations: 
You can limit the size of your bundles by using System.import() or require.ensure to lazy load some parts of your application.
For more info visit https://webpack.js.org/guides/code-splitting/

You're not helping.

@ZenSoftware
Copy link

ZenSoftware commented Dec 21, 2016

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.

WARNING in asset size limit: The following asset(s) exceed the recommended size limit (250 kB).
This can impact web performance.
Assets:
  vendor.bundle.js (2.93 MB)

WARNING in entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (250 kB). This can impact web performance.
Entrypoints:
  vendor (3.06 MB)
      polyfills.bundle.js
      vendor.bundle.js

  angularjs (3.08 MB)
      polyfills.bundle.js
      vendor.bundle.js
      angularjs.bundle.js

  zen (3.1 MB)
      polyfills.bundle.js
      vendor.bundle.js
      angularjs.bundle.js
      zen.bundle.js

  zenexamples (3.15 MB)
      polyfills.bundle.js
      vendor.bundle.js
      angularjs.bundle.js
      zen.bundle.js
      zenexamples.bundle.js

  signalrmonitor (3.16 MB)
      polyfills.bundle.js
      vendor.bundle.js
      angularjs.bundle.js
      zen.bundle.js
      zenexamples.bundle.js
      signalrmonitor.bundle.js

  zenangularjsexamples (3.16 MB)
      polyfills.bundle.js
      vendor.bundle.js
      angularjs.bundle.js
      zen.bundle.js
      zenexamples.bundle.js
      signalrmonitor.bundle.js
      zenangularjsexamples.bundle.js


WARNING in webpack performance recommendations:
You can limit the size of your bundles by using import() or require.ensure to lazy load some parts of your application.
For more info visit https://webpack.js.org/guides/code-splitting/

@jmcclell
Copy link

jmcclell commented Dec 25, 2016

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.

@damassi
Copy link

damassi commented Dec 25, 2016

Can someone reopen to continue discussion? At the very least there are some edge-cases around this issue that need to be smoothed out.

@TheLarkInn
Copy link
Member

We are tracking The discussion in the original "Performance Budget" issue. Id send the link but I'm on my phone currently 😅

@damassi
Copy link

damassi commented Dec 26, 2016

@TheLarkInn 👍 Moseying over there

@bjornstar
Copy link

#3216 For discussion about the feature

And regarding source maps, #3503 says:

For webpack 2.2.0-rc.0, we filter .map files by default.

@jmcclell
Copy link

Thanks guys!

@DuudeXX8
Copy link

Hi guys i got this error please help me anyone

const path = require("path");
const ExtractTextPlugin = require("extract-text-webpack-plugin");
const NODE_ENV = process.env.NODE_ENV || "development";
const webpack = require("webpack");
const tinypngCompress = require("webpack-tinypng-compress");

const config = {
	entry: "./common.js",
	output: {
		path: path.resolve(__dirname, "dist"),
		filename:"bundle.js",
		publicPath:"dist/"
	},
	// performance: {
	// 	maxEntrypointSize:400000
	// },
	module: {
		rules: [
			{
				use:"babel-loader",
				test: /\.js$/,
			},
			{
				loader:ExtractTextPlugin.extract({
					loader:"css-loader",
					options: {minimize:true}
				}),
				test: /\.css$/,
			},
			{
				test: /\.(jpe?g|png|gif|svg)$/,
				use: [
					{
						loader:"url-loader"
if i uncommend this line i got an error that image size is too big but if this line	will remain as it was i got error that style.css size is to large 					// options:{ limit:1000, name:"[name].[ext]" } 
					},
					"image-webpack-loader"
				]
			}
		]
	}, 
	plugins: [
		new ExtractTextPlugin("style.css"),
	]
};
if (NODE_ENV == "production") {
	config.plugins.push(
		new webpack.optimize.UglifyJsPlugin({
			compress:{
				warnings:false,
				drop_console:true,
				unsafe:true
			}
		})
	);
}
module.exports = config;

Please help me guys SOS

@Jakobud
Copy link

Jakobud commented Nov 21, 2018

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.

@JamesTheHacker
Copy link

JamesTheHacker commented Nov 27, 2018

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.

@mainstreetmark
Copy link

@Jakobud

Could someone enlighten me on why there is a warning at all about entrypoint size?

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.

@Jakobud
Copy link

Jakobud commented Jan 13, 2019

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).

@rkingon
Copy link

rkingon commented Feb 4, 2019

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

@RobertGary1
Copy link

I'm still confused. Other than to disable the warning what should I do with the warning? Mine says...
WARNING in asset size limit: The following asset(s) exceed the recommended size limit (244 KiB).

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.

@x93008
Copy link

x93008 commented Apr 27, 2020

如何优化呢

@MaxmaxmaximusGitHub
Copy link

@RobertGary1

in webpack config:

  performance: {
    maxEntrypointSize: 512000,
    maxAssetSize: 512000
  }

@jsathu07
Copy link

Try this one
expo build:web --clear

@rec
Copy link

rec commented Aug 17, 2021

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.

@Jakobud
Copy link

Jakobud commented Aug 17, 2021

Just make the 250k value a configurable option for the user.... different use websites and different use cases could use different configurable threshold values.

@rec
Copy link

rec commented Aug 18, 2021 via email

@adamsmasher
Copy link

250k is tiny tiny tiny in 2021.

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.

@nyngwang
Copy link

nyngwang commented Apr 4, 2022

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!

@vankop
Copy link
Member

vankop commented Apr 4, 2022

you can split chunk ( using import() syntax ), but this will make some part of your application async. If this is not an option for you ( loading part of your application asynchronously ), there is no way to reduce entrypoint.

Also make sure that tree-shaking works in your case.

@rec
Copy link

rec commented Apr 4, 2022

@vankop: An easier solution would be to turn off the bogus warning message.

@vankop
Copy link
Member

vankop commented Apr 4, 2022

you can use warning filter https://webpack.js.org/configuration/stats/#statswarningsfilter

@rec
Copy link

rec commented Apr 4, 2022

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.

@vankop
Copy link
Member

vankop commented Apr 4, 2022

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.

@rec
Copy link

rec commented Apr 4, 2022 via email

@nyngwang
Copy link

nyngwang commented Apr 4, 2022

To @vankop: (Apologies for just tagging you, this message is for all maintainers)

[...]
I, personally, understand that warning could be annoying and create extra noise, so [...]

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."

[...] people to spend half an hour [...]

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

@lizozom
Copy link

lizozom commented Aug 1, 2022

@nyngwang just went through the same conundrum.

@vixero-dev
Copy link

vixero-dev commented Dec 29, 2022

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests