I don't know how to ask the question for the confusion I am having.
Currently I am working on an already developed MVC5 project. In which I have seen that on layout page, bootstrap bundle is added and when I check bootstrap bundle code, it is having both minified and non minified js reference like below:
bundles.Add(new ScriptBundle("~/bundles/bootstrap").Include(
"~/Scripts/bootstrap.js",
"~/Scripts/bootstrap.min.js"
));
I don't know if it is required to add both? Will it create any problem? What happen in case of CSS when both minified and non minified files added?
You should not use both the files at the same time
While working on the code(Debug mode) use the non minified version or the even the debug version if available as it will help to find out errors easily.
And when deploying the application use the minified version as the file will be lighter and will be loaded fast.
No, it is not require to add both the files. if you add both, it consider the last file. i suggest you to create two different bundle for production and development, and just switch the flag when you want to upload to production.
It never requires to add both the file further down the line It depends on your requirement.
They are both the same functionally but the .min one has all unnecessary characters removed in order to make the file size smaller.
If you want to edit the bootstrap js keep non-minified js in project as mini JS can't be modified or understood.
And if you are not modifying any js just keep the mini version. Mini js offers loads of benefits over its original format(non-mini). See :
Quicker download times for your users.
Reduced bandwidth consumption of your website.
Reduced number of HTTP requests on your server when combining many javascript files into
one compressed file, thus reducing the server load and allowing more visitors to access our website.
Comments and whitespace are not needed for javascript execution; Removing them will speed up script execution times.
Although Bootstrap offers custom js creation so If you see you project changes demands mini js(for faster execution and several other benefits) just go on their site and modify your js.
Note : Just to point out as well, you are better using the minified version (.min) for your live environment as Google are now checking on page loading times. Having all your JS file minified means they will load faster and will score you more brownie points.
You can get an addon for Mozilla called Page Speed that will look through your site and show you all the .JS files and provide minified versions (amongst other things).
Related
I compress all my JavaScript files and CSS files with YUI Compressor
yuicompressor -o '.js$:.min.js' *.js -v
Should I keep the minified files in my subversion system or not?
I know both is possible but I'm searching for "best practice" and the pros and cons
My opinion is that it is a better to have that as part of the building process.
And builds should not be in the version tracking system for the source code.
For that reason, minified javascript files shouldn't be there either.
I think it would be best to leave out any minified files.
The reason for this is, if you have a junior come in to work on your site and they see the minified files, but not the other files, they might end up formatting your minified file so it's more readable, make changes and then when you go back to edit the correct file and compress, all his work has gone.
Worst case scenario when you don't include them is the junior will ask why his changes haven't displayed on the site and you can explain to him the correct tools which you are currently using.
OKay, this answer will purely depend on your project. Say if your project engine is capable of producing minified files, then you may not need to do this.
But say, if this is the same exact code that has to be deployed in your webserver, and all your HTML files depend on the minified code, then you have to add this.
In a nutshell, in doubt, keep the file!
SVN (or got or any versioning system) is there for keeping track of the code, not of the releases thus (IMO) it does not make sense to keep a version of the releases.
It is better to let a dedicated tool handling that (like artifactory)
Minified versions should not be in source system if you are able to generate them from the actual files in a controlled manner. This would imply that you have a build system and tools in place that is also controlled. For e.g. let's say that someone changes your YUI compressor version tomorrow. If you don't have the old version somewhere your build could break.
With the same logic, it would make sense to keep both the minified and unminified versions of any 3rd party libraries.
I have done my research on combining JS and CSS files. I am still a novice when it comes to all of this so the explanation like some of these minifies and compilers at Github and Google don't really make sense in normal English.
I have the following CSS files:
bootstrap
bootstrap-min
bootstrap-responsive
bootstrap-responsive-min
main
prettyPhoto
These are my JS files:
bootstrap
bootstrap.min
jquery
jquery.prettyPhoto
jquery-migrate-1.2.1
theme
Which tool should I use and if someone could explain step by step that would be great.
If you want to just have one big js and cs file then you can just combine them into ones by copying and pasting the content of each file one after another, in the same order you would include them on a page. Keep in mind that you do not need bootstrap if you are including bootstrap.min file after it. It's the same file, only the one with .min in name is minified version of it. Same goes for js files.
Then if you want... you can run a tool for compression like this one:
http://refresh-sf.com/yui/
and hope everything works fine.
Though combining files is easy that not something you should do to libraries. Moreover for most cases you should not merge these files.
Libraries tend to stay unchanged for long time, thus will be eventually cached by user. Site loading time will be faster.
A good approach is to link these libraries to 3rd party CDNs (Google, JQuery, etc.). They are far better with load balancing and this will increase your page loading time. (There could be some DNS lookup overhead, though).
Larger files tend to skip the cache. So having large file can make your page significantly slower if every next page call will download the library again.
Of course for your custom script joining in single file and minimization will almost always be recommended.
I am using the Jammit gem to aggregate CSS and Javascript files into single resources for faster download. Using YUI compression, I assembled a large number of scripts and stylesheets into the assets.yml config file and everything gets loaded correctly in the development environment.
However, when I specify package_assets: always in the assets.yml file to enforce asset packaging under development, then suddenly multiple errors occur and the Web page fails to load properly.
As the order of the includes is correct, I do not understand what else could have gone wrong... Is it possible that Jammit reorders or damages the code of packaged Javascript files? Could it be that including already minified files into assets.yml causes problems?
which compression are you using?
i've used the YUI and everything worked great.
maybe you've got a previously minified js file and that compression is breaking it?
I'm starting to use the Dojo toolkit and it has rich features like Dijits and themes which are useful but take forever to load.
I've got a good internet connection but those with slower connections would experience rather slow page loads.
This is also a question about heavy vs light frameworks. If you make heavy use of widgets, what are some techniques to keep page load times down?
Dojo has a build system that will drastically improve load times. Take a look at one of the dojo books or the online docs & look at layered builds. In order to do a build, you need to have the "source" (or "full") version of dojo, which has the build tool included -- you can tell if you have this by the presence of the 'util' directory (which is at the same level as dojo, dijit, dojox). If you don't have the full version, go back to the dojo site & delve down into the download area -- it's not completely obvious perhaps.
Anyway, if you have the right version, you basically just need to make a "build profile" file (or files ... aka a layered build), which is essentially your list of dojo.requires that you would normally have in your html. The build system will jam all the javascript code for all the dijits, dojox stuff, etc. together into a "layered build" (a file) and it will run shrinksafe on it, which sort of minifies the code (removes whitespace, shortens names, etc). It will also do some of this to the css files. Aside from making things much smaller, you get just a single file for all the js code (or a few files if you do more than one layer, but most of the time a single layer suffices).
This will improve your load times at least ten-fold, if not more. It might take you a bit of reading to get down the format of the profiles and the build command itself, but it's not too hard really. Once you create a build file, name it something obvious like "mystuff" and then you can dojo.require the "mystuff" file (which will be in the new build directory that is created when you build, then underneath that & hanging out with the dojo.js file in the dojo directory). Requiring in your built file will satisfy all the dojo.require's you normally do (assuming you have them all listed in the profile to build) and things will load very fast.
Here's a link to the older build docs, which mostly still hold true:
http://www.dojotoolkit.org/book/dojo-book-0-9/part-4-meta-dojo/package-system-and-custom-builds
Here's the updated docs (though perhaps a little incomplete):
docs.dojocampus.org/build/index
It reads harder than it really is ... use the layer.profile file in the profiles directory as a starting point. Just put a couple of things & then do a build & see if you get the release directory created (which should be at the same level as dojo, dijit, etc.) and it will have the entire dojo system in it (all minified) as well as your built (layered) stuff. Much faster.
Dylan Tynan
It's not that big (28k gzipped). Nevertheless you can use Google's hosted version of Dojo. Many of your users will already have it cached.
Once you create a build file, name it something obvious like "mystuff"
and then you can dojo.require the "mystuff" file (which will be in the
new build directory that is created when you build, then underneath
that & hanging out with the dojo.js file in the dojo directory).
Requiring in your built file will satisfy all the dojo.require's you
normally do (assuming you have them all listed in the profile to
build) and things will load very fast
Slight correction -- you don't dojo.require that file, you reference it in an ordinary script tag.
<script type="text/javascript" src="js/dojo/dojo/dojo.js" ></script>
<script type="text/javascript" src="js/dojo/mystuff/mystuff.js"></script>
For the directory layout I put the built file "mystuff.js" into the same directory as my package. So at the same level as dojo, dojox, and dijit, I would have a directory named "mystuff", and within that I have MyClass1.js and MyClass2.js. Then a fragment from the profile.js file for the build looks like:
layers:[
{
name: "../mystuff/mystuff.js",
dependencies: [
"mystuff.MyClass1",
"mystuff.MyClass2"
]
},...
I know this is an old thread. But I'm posting this answer for the benefit of other users like me who may read this.
If you are serving from apache there are other factors too. These settings can make a huge difference - MaxClients and MaxRequestsPerChild. You will need to tweak them based on the resources available to your server/machine serving the files.
Changing this worked really well for me.
Using the google CDN is also a good option although it may not be practical in some situations.
Custom build also has an effect as pointed out in other answers.
On a recent project I have been working on in C#/ASP.NET I have some fairly complicated JavaScript files and some nifty Style Sheets. As these script resources grow in size it is advisable to minify the resources and keep your web pages as light as possible, of course. I know many developers who hand-feed their JavaScript resources into compressors after debugging and then deploy their applications.
When it comes to source control and automated builds in the satisfying world of continuous integration (thank you CruiseControl.NET); hand compression will simply not do. The only way to maintain source control and offer compressed resources is to keep JS/CSS source & their minified brethren in a separate directory structure. Then register only one set of resources or the other in code-behind. However, if a developer makes a change to JS/CSS source and then fails to re-compact it and check in both versions, then you’re code-line is now out of sync. Not to mention inelegant.
I am thinking that it would be nice to write a custom executable (if one does not exist yet) for the CC.NET task block which would find and compress all JavaScript and CSS resources in the target directory after the build action but before the asp.net publish to target. This way, developers would only work on JS and CSS source and users would only get the minified resources.
Is there an application that already performs this task and if not, what kind of resource(s) should I look to install on the build server to have CC.NET execute?
(The closest question I could find here to this one required NAnt, which is not an option in my case.)
EDIT:
Dave Ward now has a great article on how to automatically minify in Visual Studio at his site.
The MSBuildCommunityTasks Project has a few MSBuild tasks that may do what you are looking for including Merge and JSCompress.
You could add these into your MSBuild project in the AfterBuild target to allow the project to perform this action every time the project is built and nothing would ever be out of sync. Your web application could then reference the compacted version for run but the developers would edit the full versions.
Nothing else would be needed on the server except the MSBuild community tasks assembly. You can put this assembly in your own source tree and reference from there and your CI build should get that assembly and everything it needs when it builds.
Another JS (and CSS!) compression library for MSBuild:
http://www.codeplex.com/YUICompressor
This is a .NET port of the java-based Yahoo! compressor.
Not a perfect answer, but if you're using MVC4 they've built this in as a new feature. When running a Debug configuration, it outputs individual files with comments and such but when you switch to Release, it will automatically bundle, minify, and change in page references to the minified files. You can setup separate bundles for, say, jquery and your own js. This works with CSS and JS files.
http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
If MVC4 doesn't work for you, you can also find packages on Nuget that can help such as this:
https://www.nuget.org/packages?q=minify