I am confused with CSS Aggregation. Could anyone describe.
When I googled, its redirecting me to some drupal stuff.
Is the CSS Aggregation deals with the Sprites, compression of css stuffs?
Kindly guide me.
Thanks,
Easwar
It's just a process of combining multiple CSS files into a single file. This is often combined with minimizing the CSS file as well. As a result, your page only contains a single, quite small CSS file instead of many large ones, thus speeding up downloads.
This is often a separate process, because for development it is easier to have multiple CSS files, each for a specific purpose, and each richly commented. During deployment to a production server, this development CSS can be aggregated to a single file.
Of course your server side templating must be smart enough to understand this. If you have CSS references in your header template, it's hard to replace them. A better solution would be to have a collection of files to include and generate the HTML for that on the go. That way, your production website could include the aggregated CSS, while the development website could use the separate CSS's. Toggling between them is just a confguration setting.
A similar process can be used for Javascript.
Related
I'm trying to figure out what the norm or standard convention is. Let's say I have a website, and most pages have the same navigation bar, and same footer. Would it be better, or more efficient, to create two different HTML files then, nav.html and foot.html, and just include them into each of my web pages using
<div w3-include-HTML="nav.html"></div>
Or is it more common to just rewrite the same code over all of the pages? I understand I would need to include the JS with the 'include' method, I'm just trying to figure out the standard practices for web development.
I have been working with web designing for some time, and I feel that including separate files is much better than repeating the same code over and over. It keeps the code clean, and easy to debug later. If you want to change anything for the footer, for example, if you rewrite the code over and over it will be quite tedious to change the code of each and every code. On the other hand, if you have them as separate files, this would be done by simply editing a single code. Including separate files is much more efficient than rewriting the same code.
They're are already plenty of questions about many css files vs one and the solution is to use one because of fewer http request. That's not what I am asking :P
I generally would use two css files. One for the entire site and one for the specific page overwrites.
My thinking behind it is that it will speed up the css since there isn't as many css selectors that need to be evaluated for every element on the page.
Requiring the client to download one more cachable css file seems like it would be worth speeding up the browsers rendering. Especially for larger sites or sites that need lots of custom css for each page.
On the other hand the page files will have additional media queries.
What do you think is the best solutions?
While a technically correct answer would require inside information on your server's performance, your visitors' behaviour and what kind of site you're designing, I'd like to explain my basic reasoning wether to use one or many CSS documents.
For any small, basic site I'll stick to one CSS document, no questions asked. However once a site becomes more complex there may be scenarios where it's reasonable to use more documents.
If a site has several pages with very different CSS and/or markup, or one-off-type pages such as a campaign landing page, or several very different types of content such as a forum or a blog or similar, then I think it makes sense to split up your stylesheets in many documents.
The structure of said stylesheets would, again, depend on the type of site you're designing. Global rules such as normalizing/resetting CSS, general structure and media queries could be in one document, while keeping page-specific rules in another.
This makes sense to me since your visitors can cache the basic structure which should be used on every page anyways, without having to download all the CSS needed for your blog or campaign page until they actually visit it.
I agree that if you have big site with different type of pages your should split your css into different files. However I think that this should not be made based on pages. It should be made on components. When you design CSS you have to split your pages into modules. A module should contain its styles and its media queries. I found that putting the media queries in different file leads to slow development. You may even end up with something like CSS constructor. I.e. a tool which selects the specific modules, combine them in a file and server it like that. You still have only one file, but its content is different.
For CSS optimization check out this tool http://bem.info/tools/csso/
As part of my job I maintain/develop an internal web application. It has relatively few users and just isn't that big. I've got a global CSS file that contains some re-used styles, but 90% of my page-specific styles really really ARE page-specific; they are things like pseudo-column widths (a lot of my output is just non-tabular enough to make tables a poor choice). I have taken to just throwing a <style> block at the top of these pages.
I know this is frowned upon, but every time I read about the reasons for separate CSS files the only one that really stands out is caching. In this case that doesn't matter; it is WAY down on the list of things I would do if I needed to speed up the application. Are there any other reasons, or can I stop feeling guilty?
every time I read about the reasons for separate CSS files the only one that really stands out is caching
Really?
Every time I read about their usage, the fact that you can change something in a CSS file and all pages that include it will have the change is the most important reason to use them.
Having your CSS centralized is a good thing even if your specific pages have different specific rules. It helps you unify the basic CSS structure across the site and when looking for how a specific effect was achieved it will be easy to locate.
These are all worthy reasons to use CSS files, well above any caching/performance reasons.
I face a similar problem, in that most of my styles are very much page-specific. However, my site is far from small, so I had to find a solution.
What I ended up doing was creating a folder css/pages, and naming each CSS file the same as the page that uses it. Then, my PHP "template" can just check if(file_exists("css/pages/".basename($_SERVER['PHP_SELF']))) and add the relevant <link/> tag, resulting in minimal effort on my part.
Just because your site is small is not a valid reason to disregard efficiency, although I have to say I'm a bit of an efficiency nerd so I'll probably be more pedantic over that :p
Ultimately, there's nothing "wrong" with just putting page-specific CSS directly in the page, just make sure that anything that is used on more than one page is in a file so you don't have to repeat yourself.
In my opinion if your app only contain a few web pages(3-5 pages) then you can go ahead define it at the top of the web pages. If your app is going to grow into more that 3-5 web pages then global CSS will help with maintainability and scalability.
Makes for cleaner mark-up, quicker load. Really applies to template and dynamic development. Don't be afraid to use it. It's not like you're going over to the dark side.
Would it be wise to combine all CSS into a single file? Would there be any performance increase. I have to assume that an HTTP request is made to get each file on initial page load, and reducing those requests would seem to make sense.
Are there any reasons NOT to combine all css into a single file?(such as maintainability or other performance issue)
Merging all of your css files into one will absolutely gain performance. Whether that performance is noticeable depends on your load, number of requests etc. For the average blog, this will have close to zero impact.
Read Best practices for speeding up your web site at Yahoo! Developer. It'll explain things way better than i can.
As you say, a reason not to merge css files is for maintainability. However, there are many tools out there which automatically merge and minify your css files into one.
You should check out YUI Compressor, this will help you with merging and minifing your css files.
Would it be wise to combine all CSS
into a single file? Would there be any
performance increase. I have to assume
that an HTTP request is made to get
each file on initial page load, and
reducing those requests would seem to
make sense.
Yes, but make the combination at build or runtime and don't try to maintain a single file if you started with multiple ones.
In addition to the number of HTTP requests it is also important to set the right expiration headers in the response.
Are there any reasons NOT to combine
all css into a single file?(such as
maintainability or other performance
issue)
It is not necessary to maintain a single file, but good to serve a single file, because CSS data is anyway merged.
The YUI Compressor is a good tool for JavaScript and CSS minification.
Would it be wise to combine all CSS into a single file? Would there be any performance increase. I have to assume that an HTTP request is made to get each file on initial page load, and reducing those requests would seem to make sense.
Yes, yes, yes.
Are there any reasons NOT to combine all css into a single file?
No
(such as maintainability
Combine them at build time and not at development time an there won't be a maintainability problem.
When not all page need all the css then splitting it in multiple files might be faster.
Maintainability becomes an issue if the CSS file gets really huge, when different teams need to coordinate their work on it.
There might be another reason, to NOT combine files:
If the combined stylesheet file is getting too large, Internet Explorer 9 will ignore some of the styles..
See: IE 9 ignoring CSS rules
I want to start using modular CSS, but I'm having trouble figuring out the best way to implement it. I was thinking I could just use a bridging technique, where I have one in my HTML and then #import statements for each module. While I like the simplicity of that method, I'm concerned about the negative effects it has on performance, since the #import-ed stylesheets will download later and not necessarily in parallel. So I want to know if there are any other popular techniques for implementing modular CSS. I don't really want to do multiple tags because PageSpeed and Yslow complain about so many stylesheets (although I know it is actually more efficient than #import). Ideally I would like to combine the stylesheets into one on the server, so the browser only every requests one stylesheet.
Using server side includes to assemble your "modules" into one style sheet on the server side is definitely recommended here. So is having some sort of cache on the server so it doesn't have to do the assembly on every request. There are lots of technologies available for this but your message doesn't include anything about your software stack.
Check out the Compass CSS Framework. It supports modular CSS through mixins and makes CSS a lot more pleasant to work with in general by adding variables, arithmetic, and including style frameworks such as Blueprint.
Just be extremely careful how you do this. Caching is your friend, and if you opt to deliver purpose-delivered, server-side generated CSS pages, you'll lose the benefit of caching. It's the classic chicken and egg problem. Do you preload and cache all your CSS and take the hit up front, or custom load each page and incur a hit on every page change? Only you know what's best.
Don't go too overboard on this. I've worked in huge shops where a minor minification change resulted in a 5 gig/day improvement (with millions of uniques)...but most sites I've worked on wouldn't see much if any gain at all. If you've got time on your hands, go nuts. Otherwise, proportion your response based on the need. Those optimizers report on ideal conditions, and we all know that isn't the case in real life. Try runnig the optimizer on some major sites sometime (don't miss trying to validate them either) Makes for good web-geek fun.