My css file is very large and not suitable for maintenance. I decided to split it into 5 smaller ones and then import them all into one main.css, like this:
#import url('menutop.css');
#import url('wraptop.css');
#import url('body.css');
...
Will entire site become slower or not?
Is there any other downside of this approach?
A potential downside is that the browser must make multiple HTTP calls to the server before it can know the styles to use.
In general, CSS minification is a good strategy. In fact, many sites split the CSS during development then bundle the files together and minify them into one blob.
Yes, there is a chance to make your site slow. You can compress your css if they are too large. There are different online minifier are avilalble,you can try one of them. For example, i often compress my css from here https://cssminifier.com/
If is too large firstly try to minify (compress) CSS with online tools. Check out for "css minifier", etc.
Related
We currently use SASS to pre-compile CSS which consists of various SCSS files.
How does one remove the implementation of SASS so that CSS files are managed directly?
As a side question, is using SASS just personal preference or is it best practice for smallish projects? Why would I want to work in several files when I can just work out of one in a syntax that I'm familiar with?
Cheers
Just remove the sourceMappingURL in your main css will do.
You can also, should you wish, reconstruct traditional CSS by looking at what was being accomplished in the SASS files and rebuilding from scratch. This is cleaner than beginning with the compiled CSS ... but it is not for the faint-hearted: it's kind of like picking out stitches. But if the number of SASS files is few, you'll be better off.
CSS preprocessors (sass/less) were always a solution in search of a problem, in my opinion. They were likely designed by developers who were given sloppy CSS from designers who may not have had good coding practices - but in general, there is very little reason for them, and they add one more bit of unnecessary tooling. I've used them, don't like them, and will never use them again. Totally unnecessary. Good structure in one's CSS will always win.
Using sass helps you organize your code in a better way. And ease the development by using nested selectors and using mixins,variables and much more which you code once and re-use many times.
One will simply go to concerned file and change the contents easily if it divided to multiple meaningful files.
And coming to your question, you can move away from sass very simply. Generate a css file once and from next time onwards start coding in your css local copy rather than extending your sass files again . :)
If you just want to move away from SASS to return to the pure CSS, you have to use the compiled stylesheet. If you compile it via command line, then you would have got the compiled CSS. Anyway, you can use an online tool to compile it, such as this.
Once a time you have the compiled CSS, you just have to import that rather than the SASS stylesheet you've been including in the HTML previously. Just insert this in your <head>.
<link rel="stylesheet" type="text/css" href="Your pure CSS stylesheet URL">
Using a large CSS file, does it also slow down DOM processing?
Or the loading speed of the page is only affected by the file size?
I imagine that the browser when first loading the css file does
some kind on indexing to be able to use the css rules.
The parsing of the file logically will take longer for a larger file.
But the processing of the dom elements will be affected or not?
Not Necessarily!
According to This link and This Link, there are many, many factors that can go into this Such as;
Don't use #import
Always use Backup Fonts
Segregate large CSS files out into multiple Smaller ones
Minify as much as possible
I hope this is useful to you :)
As this article suggesting
http://www.456bereastreet.com/archive/201002/css_efficiency_tip_use_a_single_stylesheet_file_for_multiple_media/
or different external CSS for different media would be better option?
in terms of maintainability, site performance.
Basically, if you can programmatically add CSS files to your client based on the media (as long as you only send ONE css file in the end), then yes, build multiple CSS files based on the #media.
If you cannot add css programmatically, then I would suggest combining them into a single css file (since you have to send them all to the client regardless), thus reducing the number of http requests by the client.
fewer http requests = faster page loads.
Combined Style Sheet Pros:
Optimal/Fast
Good reduction in size after compression
and yes fewer http requests
Combined Style Sheet Cons:
Messed up; all different style sheets in one place
Difficult to maintain
Less readable
You could use media-dependent #import rules like so:
#import url("print.css") print;
#import url("projection.css") projection, tv;
it should work in everything but IE5-7 (as per: http://www.westciv.com/wiki/CSS_Guide:_Media#mediaspecific )
I can't test for IE8 so you might be disappointed there too.
it would result in a very small initial CSS load, then upload just the needed stylesheets based on media.
I recently came across a use of the #import rule on Coda.com. They're actually using to import the main style sheet for the site, specifically the format:
<style type="text/css" media="screen">
#import url(./coda.css);
</style>
Which will hide the rules from Netscape 3 and IE 3 and 4. Since a web development tools primary audience will be using modern browsers, what other reasons would there be to use this rather then a link?
None. Using a <link> element also has the advantage of getting rid of the FOUC.
EDIT: Using #import in another stylesheet (.css file) can be used like an #include in C, but there isn't any reason to use #import in a <style> block.
For Coda's site, I'd imagine they did that more out of force of habit rather than any pressing technical need.
#import statements inside of actual CSS files (not in a <style> element in HTML) serve many purposes, such as making it easy to swap in and out other CSS files. The Blueprint CSS framework does this to let you easily remove certain portions of the framework such as the typography stuff or the grid stuff.
Of course, in a production environment, using a bunch of #import statements is frowned down upon because it increases the number of files a web browser has to pull down.
The only reason to use this rule today is to make your CSS more modular by splitting it into different files, like libraries.
So, while your page might link to one stylesheet, that stylesheet can #import other stylesheets for reset, typography, etc.
However, this does slow the loading of your page since it's just more sequential http requests.
I agree with Andrew. I also use imports to split out my css logically. Personally I like to split them out in 4: reset, structure, typography, general (bgs/borders etc)
Depending on the person doing it, their style and preference, css files can also be split out by page section eg header.css, footer.css etc.
One extra thing I do however to avoid the multiple http requests is have a build process which merges (in order of import) and compresses the css files for live deployment.
Hope this helps
I use a modular development approach myself, and often end up with 10+ individual CSS files. As you know, that's a pretty drastic number of HTTP requests, so I like to use Blender.
Blender is a rubygem that consolidates and minifies any number of CSS files into a single stylesheet. It also works for JavaScript.
You can define #media in your individual stylesheets to only serve the appropriate rules to the correct device types.
Can someone explain what are the benefits of using the #import syntax comparing to just including css using the standard link method?
As the answerer said, it lets you split your CSS into multiple files whilst only linking to one in the browser.
That said, it's still wasteful to have multiple CSS files downloading on high-traffic websites. Our build script actually "compiles" our CSS when building in release mode by doing the following:
All CSS files are minified (extra whitespace and comments removed)
We have a "core.css" file that's just a list of #import statements; during compilation, each of these is replaced by the minified CSS of that file
Thus we end up with a single, minified CSS file in production, whilst in development mode we have the separate files to make debugging easier.
If you use <link>s in your HTML files, all those files have to keep track of all the CSS files. This obviously makes changes and additions (both for CSS and HTML files) harder.
Using #import, you reduce a theoretically infinite number of changes down to one.
#import allows you have an extensible styesheet without having to change the html. You can link once to your main sheet and then if you want to add or remove additional sheets your html doesn't change.
Also, more smaller files help the browser do better caching. If you make a change in one part of a large sheet, the entire sheet must be downloaded again for every user. If the styles are separated into logical areas among a few sheets, only the file containing the part that changed needs to be downloaded. Of course, this comes at the cost of additional http requests.
One other handy bit, although pretty outdated, is that Netscape 4 couldn't handle #import, so it is a good way of serving a stylesheet to NS4, then having another stylesheet for more modern browsers that was imported in a standards compliant way.
#import is CSS code. <link> is HTML code. So, if you want to include stylesheets in other stylesheets (or if you can’t change HTML), #import is the way to go.
According to the CSS spec, all #import declarations must appear before any style rules in your stylesheet. In other words, all at the top of your stylesheet
Any #import declarations that appear after style rules should be ignored. Internet Explorer has never respected this; I believe other browsers do. This makes #import a bit less useful, because rules in a stylesheet that’s imported will be overriden by rules of equal specificity in the importing stylesheet.
It allows you to keep your logic CSS file spread over multiple physical files. Helps in team development, for example. Also useful when you have a lot of CSS files that you want to separate by functional areas (one for grids, one for lists, etc), let have accessible in the same logical file.
Say you work for Massive Dynamics, Corp.. It has a Widgets division. The Widgets division has an Accounts department. Accounts is divided into Accounts Payable and Accounts Receivable.
Using #include, you start the website with one top-level global.css stylesheet, which applies to everything.
Then you create a second stylesheet, widgets.css for the Widgets division. It #includes the global one, and its own styles (which can over-ride the global styles if needed, because of the Cascade). Then you create a third accounts.css for Accounts. It #includes widgets.css, which means it also includes global.css. Lather, rinse, repeat.