My webpages uses 2 CSS files. Both contains some styles but not many. Will merge these two into a single CSS file improve the webpage performance?
Thanks
Having css spread over files does not really do anything with your load speed. (I usually keep a different css file for big animation, big content blocks etc.)
But keep aware of folders. always keep all your css together in one folder, (not spreaded all over your directory).
Also css minifying (https://cssminifier.com/) Keep a minimised file loaded on your page, edit your normal file, then minify it and load the minified again. I believe this will do most regarding to load speed.
No, it's the same.
Performance improving could be accomplished in some different ways (e.g. removing unused or duplicated styles).
Yes, it will but do not expect a big change in performance. You could save only a few KB. Removing all blank space inside css file will make a bit more difference (but keep a copy of the file, after removing blank space it is going to be difficult to edit the file) but still as far as size is concern you will not make any difference. But I recommend you to do it because your site will have less "links" do download and will be closer to SEO rules.
Please read this article
Reducing code smell, javascript placement, limiting css/html animations, cache management of images/assets/scripts and writing quality queries(more importantly, nested subqueries) are going to improve performance. Merging css files will only hurt code management.
Minifying your assets and/or converting css to sass/scss or less will increase performance NOT css file merging.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
SO I have a big ASP.NET MVC Razor application that has a large Site.css with over 7000 lines of code, we have been discussing splitting that file into multiple files depending on Views.
For example with have the following views:
About Folder
Index.cshtml
Detail.cshtml
Contact Folder
Index.cshtml
Detail.cshtml
Support Folder
Index.cshtml
Detail.cshtml
and so on...
What we are considering is creating a Common.css file that will be added to the Layout.cshtml
And for each Views folder create a css file specific to those views, is it good practie to do this? Is is it a good idea?
I would keep everything in one css file (especially in production) because it requires only one request to get everything and the browser will cache it for future requests. You can make an exception for views that use excessive css (big 'file' size) and not requested frequently (you can track your visitors browse behaviour and optimize the css loading depending on that). For example you can consider splitting the css for a page that users/visitors only request once or not very often.
However I think it is a good idea to split the css files in development. This will keep things conveniently arranged and easy to maintain. Once you've ready with development you can merge the css files and minify them to decrease filesize. you don't have to do this manually. I'm not an ASP.net'er but I'm sure there are libraries out there that do exactly that. Also you could easily write a css merger by yourself. In the end it's just getting the content of all css files and merge them in one file (in the right order). This file can then be passed to a css minifier like http://code.google.com/p/reducisaurus/
An other option could be to embed the correct css in your html view files between style tags. This way you can separate your css without increasing the number of requests. In fact it will decrease the number of requests by minimum one. However this is not a good idea for dynamic pages as the css will always be a part of the http response (so no caching here, unless its a static page that has not been changed)
EDIT
So to conclude, I would go for a good library to handle your css. Preferably a library that supports less css as this will keep your css even more organised and a lot easier to maintain. With lessCSS you can import css files, nest classes, define variables, do other logic, etc. Great for developement! In production you simply use the compiled css.
for asp.net you could use:
http://www.dotlesscss.org/
for php you could use:
http://leafo.net/lessphp/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I would wish to start a discussion to get some good ideas on how to organise style sheets in a very big project with a big team of developers working on it.
One possible approach here is to have just one sheet with all the styles organized using comments and regions, unfortunately even using a one-lined writing approach with tabs this sheet would become incredibly big and even having SVN commits and updates could become messier.
So we think it would be better to divide styles in different sheets. What we are not sure is how to organize this as we have different ideas for it.
One possible idea is to organize it for types: colors.css, fonts.css, forms.css, ...
Another idea is to group them by functionality/behaviour: navigator.css, menu.css, warnings.css, errors.css, ...
We could also organize them by page: login.css, contact.css, home.css, ...
Or even use a combination of those three ideas together.
Now what worries me is the fact that we would prefer not to add all the styles to every page, as not all the pages require all the styles and we are really worried about performance as our project is consumed by millions of users everyday. We of course compress it later on deploying but even so we think it's wiser to load only the required ones per page.
On being so, I am worried about other developers not loading styles in correct order, as having different sheets needed to be loaded depending on the page, or on the group of pages, they could get this messed up and on doing so cascading will fail (imagine they load menu.css before global.css, global would override some menu styles!!!).
Now we could just go for one sheet, we could just load all of them always, or we could use some idea we came to like using an alphabetical prefix to tell developers the loading order:
a_global.css
a_forms.css
b_region1.css
b_anotherregion.css
c_page.css
But that looks a bit horrible being honest. So now I was wondering if there is some type of popular css architecturing out there or at least some good ideas we could use for our project here.
Many Thanks!!
Go with a preprocessor, so you can organize source files however you want. (Our team uses LESS, because we've started with Twitter Bootsrap and it stuck). The compiled CSS file should not be under version control, each developer should compile their own version for testing. I'd recommend a grunt task to compile a minified version for production. I'd go with component-centric approach (forms, navs, grid, typography etc).
Using a preprocessor gives you the power of variables and mixins. You can keep files like variables.less and mixins.less in which you define common styles. So you when that blue color changes into slightly lighter blue you just change it in one file.
One large file including all the CSS you need should be fine as it is cached by browsers, so it minimizes HTTP requests to your serwver. Page-specific stylesheets are OK when a particular page has many uncommon elements.
Create a style guide html template which includes every common element you can think of. Headings, link colors, lists, photo thumbnails, form inputs, grid configurations, accordions etc. When you need to create a new component add it to this template, modify the stylesheets, see if it breaks any other elements and how it fits with the rest. Then use these snippets to create particular pages.
SASS or LESS
This will help you to keep your code easy managed. (variables, mixins etc)
Divide in multiple count of files.
Always a good idea. How to divide.
I suggest basically to divide them per page.
BUT -
Exclude general styles to seperate files which will be included everywhere.
By the way, one single file doesn't imply low performance. Are you sure that 10 requests for smaller sheets will be faster than one request for bigger file?
Additionally this files will be cached in web browser, so one file doesn't look like a bad idea.
I recently stumbled across a project that has 27 different CSS files used by the same theme, and they are for specific sections in the application, rules split like this: there's a CSS file for the menubar, there's two more files for contact forms, another one does the footer, specific-page formatting, two more for galleries, so on.
So I asked lead what's the reasoning for so many CSS files and if it's safe to concatenate.
His reply was that all files sum 126KB, bandwidth matters and there's 500+ CSS rules, so best not concatenate to prevent selector collisions.
I know that 126KB of uncompressed CSS files is an awful lot, but I also know (from the best practices guide) that all these files should be downloaded single shot, so browsers will cache one biggie instead of downloading them one by one across the browsing session.
Why should I not keep myself from gluing all these files together? Is it a big deal?
Due to how cascading works, there is no possible way to cause harm just by concatenating the files together, provided you keep them in the order they appeared in the source. This will ensure that later files overriding earlier ones will still do so.
Then, you can consider minifying the CSS. This won't change the function of the selectors, but will compress them to reduce bandwidth.
All in all, having 27 CSS files is just stupid. The user would have to wait for 27 connections to be established, requests to be made, and downloads to be completed, just to see the page. Now, this does improve somewhat with proper cacheing, but even so...
Why should I not keep myself from gluing all these files together? Is it a big deal?
If you know that the CSS files do not have any conflicting directives and that they should be loaded in the same order for each page in the application, then you should, in fact, bundle them into one minified CSS file.
But that's just it. Typically when you find yourself in this situation, it's extremely difficult to discern which CSS directives are applied to which screen(s).
Emphasis: The situation that you are facing indicates technical debt.
While I agree that 27 CSS files is utterly nuts, and that ideally it should be merged and minified, there are some use cases where dividing stylesheets make sense.
Consider this:
You are working on a subsite, which requires a large number of CSS rules, that are not otherwise used on the site. If there is no guarantee that the user will visit both the sub site and the main site (and therefore take advantage of caching), it makes sense to keep two stylesheets, so the browser doesn't have to read through a huge stylesheet to see if anything matches the HTML document.
Now, this is no common case, but it does happen. An example would be a large corporation, with a lot of subdivisions with their own sites. They might include one stylesheet for all their shared styles (corporate specific UI and so on) and separate stylesheets for layouts and overrides.
That said, I very much doubt that 27 stylesheets would ever make sense. The original author probably didn't have a clue, and thought it was more structured that way. Modularized CSS is actually pretty neat, but it should always be merged and minified before it reaches the client. This is the common work method in SASS. You will have a lot of partial stylesheets for specific parts or functions of the site, but as soon as you hit Ctrl+S, it's automagically merged into one neat little package.
Now, you could probably figure out in what order the CSS files on your site is loaded, simply by visiting each page and noting the order. It would be tedious work, and there's no guarantee it will ever really pay off, but it can be done.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Is there any advantage to having a single monster .css file that contains style elements that will be used on almost every page?
I'm thinking that for ease of management, I'd like to pull out different types of CSS into a few files, and include every file in my main <link /> is that bad?
I'm thinking this is better
positions.css
buttons.css
tables.css
copy.css
vs.
site.css
Have you seen any gotchas with doing it one way vs. the other?
This is a hard one to answer. Both options have their pros and cons in my opinion.
I personally don't love reading through a single HUGE CSS file, and maintaining it is very difficult. On the other hand, splitting it out causes extra http requests which could potentially slow things down.
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.
EDIT:
I found this blog that shows how to combine CSS at runtime using nothing but code. Worth taking a look at (though I haven't tested it myself yet).
EDIT 2:
I've settled on using separate files in my design time, and a build process to minify and combine. This way I can have separate (manageable) css while I develop and a proper monolithic minified file at runtime. And I still have my static files and less system overhead because I'm not doing compression/minification at runtime.
note: for you shoppers out there, I highly suggest using bundler as part of your build process. Whether you're building from within your IDE, or from a build script, bundler can be executed on Windows via the included exe or can be run on any machine that is already running node.js.
A CSS compiler like Sass or LESS is a great way to go. That way you'll be able to deliver a single, minimised CSS file for the site (which will be far smaller and faster than a normal single CSS source file), while maintaining the nicest development environment, with everything neatly split into components.
Sass and LESS have the added advantage of variables, nesting and other ways to make CSS easier to write and maintain. Highly, highly recommended. I personally use Sass (SCSS syntax) now, but used LESS previously. Both are great, with similar benefits. Once you've written CSS with a compiler, it's unlikely you'd want to do without one.
http://lesscss.org
http://sass-lang.com
If you don't want to mess around with Ruby, this LESS compiler for Mac is great:
http://incident57.com/less/
Or you could use CodeKit (by the same guys):
http://incident57.com/codekit/
WinLess is a Windows GUI for comipiling LESS
http://winless.org/
I prefer multiple CSS files during development. Management and debugging is much easier that way. However, I suggest that come deployment time you instead use a CSS minify tool like YUI Compressor which will merge your CSS files into one monolithic file.
Historically, one of the main advantages x in having a single CSS file is the speed benefit when using HTTP1.1.
However, as of March 2018 over 80% of browsers now support HTTP2 which allows the browser to download multiple resources simultaneously as well as being able to push resources pre-emptively. Having a single CSS file for all pages means a larger than necessary file size. With proper design, I don't see any advantage in doing this other than its easier to code.
The ideal design for HTTP2 for best performance would be:
Have a core CSS file which contains common styles used across all pages.
Have page specific CSS in a separate file
Use HTTP2 push CSS to minimise wait time (a cookie can be used to prevent repeated pushes)
Optionally separate above the fold CSS and push this first and load the remaining CSS later (useful for low-bandwidth mobile devices)
You could also load remaining CSS for the site or specific pages after the page has loaded if you want to speed up future page loads.
You want both worlds.
You want multiple CSS files because your sanity is a terrible thing to waste.
At the same time, it's better to have a single, large file.
The solution is to have some mechanism that combines the multiple files in to a single file.
One example is something like
<link rel="stylesheet" type="text/css" href="allcss.php?files=positions.css,buttons.css,copy.css" />
Then, the allcss.php script handles concatenating the files and delivering them.
Ideally, the script would check the mod dates on all the files, creates a new composite if any of them changes, then returns that composite, and then checks against the If-Modified HTTP headers so as to not send redundant CSS.
This gives you the best of both worlds. Works great for JS as well.
Having only one CSS file is better for the loading-time of your pages, as it means less HTTP requests.
Having several little CSS files means development is easier (at least, I think so : having one CSS file per module of your application makes things easier).
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. faster loading pages
There are also some software that do that combining of CSS files at run-time, and not at build-time ; but doing it at run-time means eating a bit more CPU (and obvisouly requires some caching mecanism, to not re-generate the big file too often)
Monolithic stylesheets do offer a lot of benefits (which are described in the other answers), however depending on the overall size of the stylesheet document you could run into problems in IE. IE has a limitation with how many selectors it will read from a single file. The limit is 4096 selectors. If you're monolithic stylesheet will have more than this you will want to split it. This limitation only rears it's ugly head in IE.
This is for all versions of IE.
See Ross Bruniges Blog and MSDN AddRule page.
There is a tipping point at which it's beneficial to have more than one css file.
A site with 1M+ pages, which the average user is likely to only ever see say 5 of, might have a stylesheet of immense proportions, so trying to save the overhead of a single additional request per page load by having a massive initial download is false economy.
Stretch the argument to the extreme limit - it's like suggesting that there should be one large stylesheet maintained for the entire web. Clearly nonsensical.
The tipping point will be different for each site though so there's no hard and fast rule. It will depend upon the quantity of unique css per page, the number of pages, and the number of pages the average user is likely to routinely encounter while using the site.
I typically have a handful of CSS files:
a "global" css file for resets and global styles
"module" specific css files for pages that are logically grouped (maybe every page in a checkout wizard or something)
"page" specific css files for overrides on the page (or, put this in a block on the individual page)
I am not really too concerned with multiple page requests for CSS files. Most people have decent bandwidth and I'm sure there are other optimizations that would have a far greater impact than combining all styles into one monolitic CSS file. The trade-off is between speed and maintainability, and I always lean towards maintainability. The YUI comperssor sounds pretty cool though, I might have to check that out.
I prefer multiple CSS files. That way it is easier to swap "skins" in and out as you desire. The problem with one monolithic file is that it can get out of control and hard to manage. What if you want blue backgrounds but don't want the buttons to change? Just alter your backgrounds file. Etc.
Maybe take a look at compass, which is an open source CSS authoring framework.
It's based on Sass so it supports cool things like variables, nesting, mixins and imports. Especially imports are useful if you want to keep seperate smaller CSS files but have them combined into 1 automatically (avoiding multiple slow HTTP calls).
Compass adds to this a big set of pre-defined mixins that are easy for handling cross-browser stuff.
It's written in Ruby but it can easily be used with any system....
here is the best way:
create a general css file with all shared code
insert all specific page css code into the same page, on the tag or using the attribute style="" for each page
on this way you have only one css with all shared code and an html page.
by the way (and i know that this is not the right topic) you can also encode your images in base64 (but you can also do it with your js and css files). in this way you reduce even more http requests to 1.
SASS and LESS make this all really a moot point. The developer can set up effective component files and on compile combine them all. In SASS you can toggle off the Compressed Mode while in development for easier reading, and toggle it back on for production.
http://sass-lang.com
http://lesscss.org
In the end a single minified CSS file is what you want regardless of the technique you use. Less CSS, Less HTTP requests, Less Demand on the server.
The advantage to a single CSS file is transfer efficiency. Each HTTP request means a HTTP header response for each file requested, and that takes bandwidth.
I serve my CSS as a PHP file with the "text/css" mime type in the HTTP header. This way I can have multiple CSS files on the server side and use PHP includes to push them into a single file when requested by the user. Every modern browser receives the .php file with the CSS code and processes it as a .css file.
You can just use one css file for performance and then comment out sections like this:
/******** Header ************/
//some css here
/******* End Header *********/
/******** Footer ************/
//some css here
/******* End Footer *********/
etc
I'm using Jammit to deal with my css files and use many different files for readability.
Jammit doest all the dirty work of combining and compressing the files before deployment in production.
This way, I've got many files in development but only one file in production.
A bundled stylesheet may save page load performance but the more styles there are the slower the browser renders animations on the page you are on. This is caused by the huge amount of unused styles that may not be on the page you are on but the browser still has to calculate.
See: https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/
Bundled stylesheets advantages:
- page load performance
Bundled stylesheets disadvantages:
- slower behaviour, which can cause choppyness during scrolling, interactivity, animation,
Conclusion:
To solve both problems, for production the ideal solution is to bundle all the css into one file to save on http requests, but use javascript to extract from that file, the css for the page you are on and update the head with it.
To know which shared components are needed per page, and to reduce complexity, it would be nice to have declared all the components this particular page uses - for example:
<style href="global.css" rel="stylesheet"/>
<body data-shared-css-components="x,y,z">
I've created a systematic approach to CSS development. This way I can utilize a standard that never changes. First I started with the 960 grid system. Then I created single lines of css for basic layouts, margins, padding, fonts and sizes. I then string them together as needed. This allows me to keep a consistent layout across all of my projects and utilize the same css files over and over. Because they are not specific. Here's an example: ----div class="c12 bg0 m10 p5 white fl"/div--- This means that the container is 12 columns across, utilizes bg0 has margins of 10px padding of 5 the text is white and it floats left. I could easily change this by removing or adding a new - What I call a "light" style- Instead of creating a single class with all these attributes; I simply combine the single styles as I code the page. This allows me to create any combination of styles and does not limit my creativity or cause me to create a massive number of styles that are similar. Your style sheets become a lot more manageable, minimized and allow you to re-use it over and over. This method I have found to be fantastic for rapid design. I also no longer design first in PSD but in the browser which also saves time. In addition because I have also created a naming system for my backgrounds and page design attributes I simply change out my image file when creating a new project.(bg0 = body background according to my naming system) That means that if I previously had a white background with one project simply changing it to black simply means that on the next project bg0 will be a black background or another image..... I have not found anything wrong with this method yet and it seems to work very well.