I'm working in an AngularJS app that uses webpack for bundling the resources. Currently we are creating a single app.js file that contains the CSS as well. The size of the app.js is around 6MB. If we break the app.js into multiple chunks does that improve the page performance. My colleagues convinces me if we break the single JS file into 2 or 3 then the page load time will increase twice or thrice. Is that really true? I remember reading some where having a single file is better than multiple. I don't really remember the reasons now. Do I really need to break the app.js file for page performance? or what other options I can apply here?
A single file is better because it requires fewer connections (means less overhead), but this is really negligible when talking about < 5 files. When splitting parts of your file you do gain the ability to cache the files separately, which is often a great win. Therefore I'd recommend splitting the files in logically cachable sections (like vendor code and custom code).
Also note that if the client and server support http/2, the fewer connections reason is also gone since http/2 supports connection re-use.
Note that there is no real difference for the initial load time, since in that case all files will need to be downloaded anyway.
A single file will usually mean better performance. You should also ensure that this file is properly cached (on the browser side) and gzipped when served by your webserver.
I did a practical test in Chrome (Mac 54.0.2840.98 (64-bit)) to prove whether there is really a performance gain in breaking a huge JS file into many. I created a 10MB js file and made three copies of it. Concatenated all the 3 copied and created a 30MB file. I measured the time it took for the single file that is referenced using a normal script tag at the page bottom and it's around 1 minute. Then I referenced the 3 10MB script files one after other and it took nearly 20seconds to load everything. So there is a really a performance gain in breaking a huge JS file into many. But there is a limit in the no. of files the browser can download parallely.
Related
I am just thinking of ways to reduce the bundle size of my app. I just want to get feedback on a small thought I had. Will it be a good idea not to ship the language file at all in the main bundle of a application?
Because if your application too big with a lot of entries in the language file, it will start to take a small part of the bundle size, and if you have support for 2-5 languages in the app, then it can be even bigger part of your bundle size.
What if we removed the language files completely from the bundle and put it in a static get endpoint which will serve the static JSON of the language file and the get endpoint will be the 1st thing called when the app gets initialized?
Is it a somewhat of a feasible idea or am I completely crazy?
Heretic Monkey is right, you need to try it out and compare the performance.
Another consideration is that your interface might render in the default language before switching to the client language, if there's a long delay between the two resources this switch could be visually bothersome.
Personally I like to have each component have its own individual language files and have languages all be separate. So when you load a component of the page, the component quickly pulls a very small language file for itself in only the language it needs. Serving lots of small files like this works best when the server can serve HTTP/2 connections and lots of small files can be downloaded in parallel.
Caching is also important here, so if another of the same component loads it won't pull the same language file for itself again, it just grabs it from the cache.
As you suspect, separating everything out like this just might not be worthwhile depending on the size of the application and the number of languages you're supporting, so start by considering the size of your application and the size of the language portion. Does the language pack take up more than 10% of the file? Would that be worthwhile time savings?
I found the first web page loading time for CN1 Javascript Built taking too long, need about 2 minutes.
I attached the Chrome's network loading screen shot, found the classes.js is the most heavy page, possible to zip it?
Second, there is 2 theme files that downloaded sequentially, is it possible for them to load at the same time?
Kindly advice.
Normally I would answer that you can look at the performance section of the developer guide but the relevant sections there relate to reducing the theme.res size which seems pretty small in your case.
The largest portion in your code is the class files so I'm guessing that the best way to reduce them is to further reduce dependencies so the obfucator can remove more dead code. Keep in mind that the classes.js file is cached and can be deployed via CDN's such as cloudflair to improve download speeds. It can be served in a gzipped form as well which is a part of the CDN repertoire.
I am working on an AngularJS app.
According to a lot of articles in the Web, every file on the project can not have more than 100 / 150 lines of code.
Then, here is where my concern comes up: if I am concatenating/minifying my code, at the end all of the code will be in one very big single file.
So in that case, the rule(good practice) of the 100 / 150 lines of code still applies in this case ?
Kylek is right on about small files being for developers, and big files being for machines. More specifically, if you're interested, read about synchronous http calls and web loading speed. Basically, every separate external resource you have load on the page (a css file, or a javascript file) requires overhead on top of the actual content download, so for maximum speed, you want both a small number of files (accomplished by concatenation) and a small content size (accomplished by minification).
Of course, as a developer, you still don't want to have to worry about this while writing and maintaining code. Check out grunt, specifically uglify and cssmin, which can keep monolithic minified files up to date for you while you work on your source. Regarding angularjs in particular, make sure you're using dependency annotation or minification will break your code.
Keep files small is not a performance good practice but a way to keep things organized for developers and to find quickly what you are looking for, it's not for machines but for humans.
No human will have to develop minified files, so no coding rules apply to minified files. A contrario, minify and concat JS, CSS etc. make your pages load faster. It's a performance good practice.
By the way, do not follow a rule because some one tell you to. Be sure the rule match your case, your project, your team, etc.
I have about 10 directives and they are pretty complicated. Today I use one file only directives.js.
Is there some performance penalty if I'll put each directive to separate file for better maintenance?
Thanks,
JavaScript itself doesn't care where the code comes from. But JavaScript code has to be loaded by the browser. Making 10 HTTP requests to load 10 files is obviously slower than making 1 HTTP request to load the equivalent code.
But that's not a good reason to put everything in a single file. You should make one file for each component to make the code maintainable and easy to find. But the build procedure of your application should concatenate and minify the JavaSript files into a single file for production, so that a single file is used by the actual application.
Grunt and Gulp are two good build tools to do that, and much more.
Yes, there is a performance penalty for the client if it has to load every file individually. There are, however, server-side techniques to mitigate this, such as ASP.NET's script bundling, Grunt's building and many many more, that bundle several JavaScript files into one file for the client.
Yes, you should put your directives in separate files. This will cause performance degradation if used as is, however by using build tools like Grunt you can concatenate and minify whole of your app into a single JS file.
I want ask : if cache too many page 10000 page is cached.
10000 page create 10000 file cache.
Is it ok ? it can create slow?
I don't think that this could slowdown the application. Modern file systems support big amount of files in a directory. The problem is if you what to manually list all those files.
A cache file is stored on the server as static HTML rather than the dynamically generated HTML code that is created with PHP.
Loading these cache files is significantly quicker than running PHP code through the PHP compiler at runtime.
The only issue is perhaps disk space as the cache files are physical files on the server. Most cache filesizes should be relatively small if used correctly so this really shouldn't be an issue on a proper web server with sufficient resources.
Cache files are generally always faster than running the PHP script as they do not have to be processed - the overhead is just hitting the file and retrieving it.
The compromise you make with cache is whether or not your data changes often enough to warrant using file cache, and whether or not users need access to an always up to date file.
I wouldn't worry about it, and hey you can always turn the cache off - right?
Yes, but probably not significant
Full-page cache files are all stored in the same folder. As such caching 10k pages, means having 10k files in a folder. It will not likely be significant, but there will be a slow down in application performance as the cache fills up.
Also note that there's a limit to how many files you can store in a folder depending on the drive format though generally speaking by the time the limit is reached performance is already significantly affected.
Don't use view caching if it's not necessary
Even full page caching has a cost. A normal php request is the following logic:
user -> internet -> webserver -> php -> (application logic)
Using full page view caching this doesn't change much:
user -> internet -> webserver -> php -> (read and render cache file)
If there is no dynamic content in the cache file it's a better idea to store the contents as a static file and move the response closer to the user:
user -> internet -> webserver -> static html file
Plugins like html cache permit this by storing cached views as html files and allowing the webserver to handle requests before invoking php.
That also means, depending on the cache headers sent for html files, that subsequent requests come straight out of the user's browser cache - and you can't get faster than that:
user -> user's browser cache