I am using bootstrap.css and I found that there is another css file named bootstrap-combined.min.css, is there any difference in style? Is there any need to include both css files? Which one is more preferable?
The file bootstrap-combined.min.css is for Bootstrap v2, it is the combined css file of bootstrap.css (the main css file) and bootstrap-responsive.css (the responsive Bootstrap styles). It's exactly the same as using those two files separately but it just saves you an extra request.
The "min" part of the filename just means that it has been minified, which is to say that it has had all the unnecessary white-space/comments/etc removed.
Conclusion
bootstrap.min.css = compressed version of bootstrap.css
bootstrap-combined.min.css = bootstrap.min.css + bootstrap-responsive.min.css
Basically min is minified version, which is intend for production. In normal version you can see through codes and edit (In some cases, necessary though). Sizes are remarkable reduced in minified version and relieve bandwidth, time and memory.
The combined indicates a collection of bootstrap components merged into one file. The min indicates a minified file, meaning:
Minification (also minimisation or minimization), in computer
programming languages and especially JavaScript, is the process of
removing all unnecessary characters from source code without changing
its functionality. These unnecessary characters usually include white
space characters, new line characters, comments, and sometimes block
delimiters, which are used to add readability to the code but are not
required for it to execute.
The minified combined version is most preferable for production deployment, as it minimizes the number of requests and bandwidth used, thus improving page load speed. During development you may find a use for non-minified non-combined files for debugging purposes, but that's unlikely. In general, the combined-min version is just fine.
from the comments: afaik in general the min.js versions of .js files dont have any comment-sections or unneccessary blank-spaces to reduce the file size - at the end of the day, as you already said, there's no difference in functionality. in case of bootrap: you dont have to include both of them (as shown here).
Related
I have a website which uses 1 css file, it is called body.css and it consists of 841 lines. Should it be sorted in different files (header.css, footer.css page1.css, etc...), is it better in just 1 file or does it not matter?
The only thing I know for sure is sorting it in more files is a lot more readable.
Also if someone answers this I'd be most grateful for a little explanation.
My opinion would be one of two things.
1) If you know that your CSS will NEVER change once you've built it, I'd build multiple CSS files in the development stage (for readability), and then manually combine them before going live (to reduce http requests)
2) If you know that you're going to change your CSS once in a while, and need to keep it readable, I would build separate files and use code (providing you're using some sort of programming language) to combine them at runtime build time (runtime minification/combination is a resource pig).
With either option I would highly recommend caching on the client side in order to further reduce http requests.
So, there are good reasons in both cases...
A solution that would allow you to get the best of both ideas would be :
To develop using several small CSS files
i.e. easier to develop
To have a build process for your application, that "combines" those files into one
That build process could also minify that big file, btw
It obviously means that your application must have some
configuration stuff that allows it to swith from "multi-files mode" to "mono-file mode".
And to use, in production, only the big file i.e. Single CSS
Result : faster loading pages
maybe this will help you..
For optimal performance it is better to have only one css file.
But for readability it would be better to have different files for different parts.
Take a look at tools like SASS, which help do that without sacrifice performance. Additionally it has features to make your files even more readable by introducing variables, function and much more.
Using more files means more requests. It will take more time to load and make unnecessary requests to the server. I'd stay with one file.
The only good reason to have other css files would be if you have third-party components, to keep them separated and be able to update them easily.
The order matters: Rules loaded later will override rules with the same name loaded before (this is valid even for rules in the same file).
What do you mean that your website uses one CSS file? Normally you'd write your style definitions in multiple files, and they are concatenated (or not) into one file. My point is, what you are working on in your development environment should stay modular, readable, it shouldn't be influenced by what you have in production.
As for the order of the CSS files, yes, it matters, as you can overwrite your previous definitions.
For optimal caching I'd recommend you to build all the vendor CSS in one file, and your CSS in another file, versioned, so that if you change something in your code, only that file has to be updated by the browser.
But these things depend on the infrastructure. As the browsers are able now to send multiple requests simultaneously, having multiple files can lead to faster page load than only one. But I'm not sure about this.
you might want to take a look at gulp to automatically optimize, and minify your CSS code.
All css in one file is OK.
But it's free : you can make as many css file as you want.
However usually this is how it is:
1 global css file for the entire page. You put the common css in here that is useful for every page on your site. You can call it app.css or style.css or mywebsite.css or any name you want.
1 specific css file for a specific page when you want to specially separate this css from the global css file. Because it will contains css only useful for a few pages. For example you have a special component made by your own or a special functionnality. Example : you have made a spcial javascript code working with some html for uploading some file and you want to have your code js/css separate.
Usually, you can also have one css page for each page, but always one global css file for the entire site.
Note : Same question is also valid for javascript
Note 2 : You can also think about using a framework to minify your javascript and css into one single css / js file at the end. At work our technical boss use wro4j which works for java but it should exists many more other frameworks as you can search on google.
Im using W3TC with minify
Im detecting that css and js minified files takes a lot to load, blocking the following elements in the waterfall.
If i use other minification plugin, like head cleaner, those minified files load instantaneously with no blocking at all
Regular uncompressed css and js files are loaded with no blocking nor waiting neither
I don know if the problem is related to number of files minified (can i limit the number of files to minify?) or its related to not limiting the number of characters in file name.
Could this really be an issue loading minified files?
Here is an example of the tests:
http://gtmetrix.com/reports/www.externateam.com/eeQZ0MXm
Since i have no clue, any approach would be awesome
Thanks and best regards
W3total cache has this issue where the character limit is added. So every file is, infact, separated through comma and loaded to the url for instance.
I am not sure about the orignal format, but it looks something like this: www.example.com/wp-content/plugins/w3total_cache/wp-content/themes/js/jquery.js,wp-content/themes/js/bootstrap.js
Its fine for a few files but as the number of files grow larger this becomes a mess. Some servers done allow more than a few hundred characters to be added.
I have seen the link you shared, these files are separately loaded, and this is what has to be expected.
The only ways to get rid of the blocking time is:
by either combining all the files, there is an option in w3totalcache.
Or using an async defered blocking (which is also available in w3totalcache).
But async method doesn't always work perfectly for every theme. If you dont have a well developed theme you will really have a hard time getting this one to work.
Is there any way in LESS to render the original LESS File + Line Number in the rendered CSS?
Just as Middleman does with SASS... (I'm not sure if it is a SASS or a Middleman feature)
I'm not familiar with Middleman, but the GitHub page for FireLess (inspired by FireSass, I guess) suggests that it would show the Less line number in Firebug, rather than the compiled CSS line number.
I have no idea why the selected answer was chosen to be correct - it relates to a different build of LESS built for the .NET framework, not simply LESS itself.
Anyhow, yes, LESS does support this. It's not particularly well documented, but if you compile using the --line-numbers=[comments|mediaquery|all] flag, it will compile your CSS with the debug info spec SASS established.
If you're using Grunt, and grunt-contrib-less, you can use the dropLineNumbers option (really strange choice of name, imho). I typically set mine to all.
There is now an option in dotless to output this information as per sass does. the flag is "debug". It will be included in the next release - https://github.com/dotless/dotless/issues/186
I'm considering using less in an upcoming project but have been trying to figure out the best way to work with it while in development.
Usually when developing a site I'll write my html and css then start testing it in the browser, see how it looks, refine, reload, and repeat the whole process until I'm happy with how everything looks.
A crucial part of the process is using the Inspect Element feature in the browser to identify the piece of CSS I need to change. Usually just by looking at the line number I know exactly where to go in my CSS file.
But if I use Less (or any other method of combining/compressing my CSS) it makes the line numbers useless. I know I could use Find to search for the section of code but line numbers are much faster.
This is especially true when working on a project that involves other developers or large CSS files.
I just wondered how others deal with this, or maybe there's a better process?
Minified CSS really should only be going out to the production version of your site. When you're performing tests/changes etc, this should all be done in some test or development version of your site in a secondary server area where you can have the line-numbers version of css available. The same would go for JavaScript. On the production viewable copy, you want it minified. In development, you don't.
In any event, you should always have 2 copies of your css. The first copy is the primary source copy that is your development copy. It has all of your properly formatted styles with line-breaks in it. The other is the very latest minified version of your css that went to production. This will allow you to switch between the 2 files rapidly in the event that you need to work something out, assuming your site uses some sort of templated delivery (layout pages, master pages, or whatever).
The minified version will only be useful in the final delivery. All other needs should use the master copy. It might not be a bad idea to put a configuration in server-side portion of your site that determines what style sheet to use. That way you can simply change a configuration setting and go into a "debug" mode.
I agree with Joel - that's how I handle it. A build script minifies the CSS (and JS) before each release is FTP'ed to production. I just have a switch in PHP like:
if ($config->prod()) {
// incldue the minfied css
} else {
// include all the original files
}
Personnaly, I use an ant build script to make a production version:
it "condense" multiple css files in one
then it minify them with YUI compressor
same for scripts
(page recomposition to point to the newly generated files)
this way you divide your http request for those files, and gain some bandwith from 30% to 70% i'd say. depends on gzip also.
in my case, the dev version have:
18 css weighting 178ko
reduced down to 1 css at 96ko in the production version
I personally use tools to minify and inject the CSS into the browser each time i save my Less file. So i see each change immediately. This way it's pretty clear what just happened. I don't need the referencing line numbers that much any more.
I recently started using source maps, to see the correct file and line numbers (of my less files) when inspecting CSS in the browser again. I think that is what you are looking for. I personally don't need this extra fanciness that much.
I came across a strange behavior while theming Drupal. I turned a few modules that added 5 to 10 link tags to the page. While these new stylesheets were added to the cascade in Firefox, in IE8, by adding these the browser discarded the earlier added CSS files from the hierarchy. In fact, the first files were the first to go, which completely screwed up the styling of the page and had me scratching my head for a while. Eventually I discovered the newly added modules had caused IE to pass some internal threshold where it could not add new includes anymore.
Has anyone seen this behavior before? I'm not sure if it's an issue with browser or with my setup.
Internet Explorer has a maximum limit of 32 CSS file links. Definitely a browser issue. You'll need to think about consolidating your css requests.
Generally you can do this by concatenating them if they're static files, but if you're generating them programatically, you might have to look at a solution to manipulate the response before it gets passed to the browser.
We had to get around this issue for our enterprise ASP.Net project and ended up writing a "Css Multiplexor" that examined the response, found the requested CSS links, generated a web resource for one big css file, and output a link to that instead.
I encountered this issue on our site.
IE8 only permits 32 CSS imports per file. That file could be an HTML file or a CSS file. (*) However, the import limit does not restrict you to 32 CSS files total. You can link to two CSS files in your HTML, each of which #imports 32 CSS files. Playing with tricks like that should get you as many as you need.
The specific workaround we use is to split the CSS files we need into two groups, and have two 'import' CSS files. The HTML page imports the first import CSS file, which imports the first group and the second import CSS file, which imports the second group.
This works fine, but results in lots of HTTP requests, so we only use this workaround on development systems. For our live sites we have a build step that compiles all the CSS into one file.
What Johannes has mentioned -- getting Drupal to aggregate your CSS -- sounds like the best bet.
(*) There's some fine print like: the 32 imports includes the CSS files that have already been imported in the chain from your HTML page. So if your HTML imports a CSS file, then that CSS file can only import 31 other second-tier CSS files, and each second-tier CSS file can only import 30 other third-tier CSS files. You really have to wonder what bizarre algorithm causes this limitation...
The limit is 31 - NOT 32!
While some would say "who cares, close enough, right?" --- With larger applications with hundreds of developers it can be very easy for the page to go over the limit, so you should really know the exact number of css stylesheets can be included on the page.
There are several ways to mitigate the problem:
Reduce the number of CSS files by consolidating into larger files - perhaps manually, or some run time grouping mechanism, or you can use an automated css compiler to combine and minimize all your CSS files
Use #import url(...) statements rather than <link href=""> but remember you can only have 31 #import (again, NOT 32...) statements in one stylesheet
Use #2 above with caution because:
You are only increasing the limit (to 961 css files) not removing it
The browser will be forced to download the CSS files in series rather than in parellel. Normally a browser can download more than 1 css file at a time (the count depends on if the files are in the same domain and which browser you are using) - This can have a significant impact on performance.
Each CSS file requires a round trip to the server adding extra time.