I don't know much about speeds and all of that, so I'm not sure if a huge stylesheet would show significant changes in the loading of the page or not. To keep it simple, I want to use a stylesheet that covers all areas of the website using IDs, like #forum div.menu or #game div.menu. Knowing that this would make the stylesheet large, I'm uneasy about it being too much. Could someone provide insight on the significance of the size of a stylesheet and perhaps some specs?
If your users are going to be using all those styles anyway, it is usually better to serve it in one stylesheet because it reduces the HTTP requests and allows the browser to cache it all. However, if you have a lot of CSS for only one page that is not commonly visited for your users (and it is enough that including it in the global stylesheet adds a bunch of weight and would add a substantial amount to the file), it may be better to put it in a separate file.
Bigger stylesheets are better than smaller, multiple stylesheets when trying for speed. HTTP requests are one of the main reasons of slowing your webpage down. Its the same with images. One big image is far better than a lot of littler ones. Here is a good link for reducing your http requests: http://www.dailyblogtips.com/speed-up-your-site-reduce-the-http-requests/.
You may find this Yahoo Developer Network article very useful.
It has a number of sections regarding optimization of CSS
for your site.
"Best Practices for Speeding Up Your Web Site"
http://developer.yahoo.com/performance/rules.html
Related
Less HTTP request the better it's, right ?
Regarding to Google best practice explanation, less unused css rules is also better.
The browser's CSS engine has to evaluate every rule contained in the file to see if the rule applies to the current page.
Even if a stylesheet is in an external file that is cached, rendering is blocked until the browser loads the stylesheet from disk.
In your opinion what's giving better performance :
One css file per page.
One general css that will be cached (even if there will be +70% unused css / but avoiding any other http requests).
Google speed best-practice
One of the important sentence to note from the Google best practice document is "Often, many web sites reuse the same external CSS file for all of their pages, even if many of the rules defined in it don't apply to the current page".
This needs to be taken into account as if the css file has additional code that is never going to be used if user does not visit the page for which this redundant code applies then we are certainly wasting the bandwidth which may not be a proper trade off for an additional HTTP request.
This leads to additional time to load the file plus the time wasted in evaluation of that redundant code.
Certainly using multiple files for just a single page (like different header/footer css files) would be a bad practice.
And as you know that there is not a perfect solution for any problem. You have to choose the best thing that suits your need.
So, I would say the decision to use multiple files or a single file is solely based on the overall structure of website and other trade offs.
Loading CSS is usually extremely quick. CSS blocking is something you will probably never catch. Whereas JavaScript could do so that you are visually aware that it's being downloaded. (white spaces while rendering the page).
In reality one CSS is good enough, because of a single HTTP request.
Optimization should go towards JavaScript, because this is where you can see the page slowing down. We are talking about a second-two of a difference or less here.
Here is a site where you can enter URL and it will check load times. In the graph below you can compare CSS load times.
Once upon a time I was thought by more advanced web developers (gee, when was it again? ;)) that we should avoid managing multiple CSS files and stick to one per project. It helped to improve page load speed and avoid silly mistakes when dealing with a lot overlapping CSS rules.
My question is - is this approach still valid?
Argument about page load performance doesn't seem to hold that much nowadays with awesome broadband Internet and clever web browsers with even more awesome caching capabilities.
CSS cascading can indeed be error prone, but just for inexperienced developer and having one CSS style sheet doesn't really make us bullet-proof.
I think that I would prefer to have a set of default style sheets neatly separated by components, then wire them up into one single rule by CSS #import. This would also allow me to include reset style sheet by default.
Anyone is with me?
It's not about bandwidth speed but number of http requests, this makes a lot of sense for a mobile connection.
However the approach of having different css files to keep the project modular is solid, as it helps you keeping your css organized the way you want it without having all the code in one file only. Then you can benefit of css preprocessors / minifiers to concatenate and compress all your css files in a single one for production.
this article http://www.igvita.com/2012/06/14/debunking-responsive-css-performance-myths/
has a paragraph about mobile that explains well why this is a good practice:
you are much better off downloading all of the CSS content in one shot over the initial, warmed up connection. By doing so, you will also help the user extend their battery life. If there is one optimization to be made here then it is simply: concatenate and compress.
Yes, that approach is still valid. There are dozens of articles about load optimization out there, but the general idea is as follows
Less files = less http requests made to server = better load performance
Main thing that changed over time is that now there are many tools that support merging multiple files into single at runtime. So you have separate stylesheets for better organization, debugging at development time, and those tools merge, minify and set correct caching headers at production.
I agree with you, I find no reason to keep only a single css sheet anymore, nowadays, I do exactly what you just stated, separation by component, along with lazy loading :) (php if statements etc).
I separate stuff with comments. For example divs goes to /* Divs start*/ div#somediv /* Divs end*/ /* Animations start*/ /* Animations end*/. For me this is easier than merging different css files once i've completed the project
I've been using Google PageSpeed to improve my site's performance. One of its recommendations is eliminating unused CSS in my app. Although a lot of the CSS is unused for a given page, it is used elsehwere in the app.
What's the right approach here? I'm considering creating a base CSS file for common CSS and then separate files for each individual page. Luckily there aren't that many pages. Is this overkill? And is there a better approach?
This is a Rails app, and I'm using asset_packager to minify my CSS and Javascript
Thanks!
Moe
It won't speed up your application because you will be adding new http requests, while if you pack all CSS into one file, that file will stay in the cache and you won't have to have an http-request for it for subsequent pages.
Google PageSpeed simply mean that you shouldn't provide styles you don't use anywhere in your application or only in pages that a user can't visit, for example the admin area.
As people in here mentioned, definitely not. You will just add new http requests. You should really keep in mind that pagespeed will probably always show that you have unused css on a given page, but that's not really a big issue.
Take a look at the other recommandations page speed is showing like enabling compression, optimizing the images (consider using css sprites if you aren't already) and more.
See also yahoo best practices to speed up your site.
That'll depend on the size of the file(s) and the way people use your site. If the file isn't huge to begin with and people will often go to many different pages, having page-specific css files will forfeit the benefit of caching, which is generally going to garner more benefit.
The overhead of an extra HTTP request to download yet another CSS file greatly outweighs the overhead of an extra few KB in the master CSS file.
I think it is best to componentise your stylesheets. For example, you might have a base css that provides the layout for your pages. Then you might have a theme css that provides colours, images, borders - visual elements. Then you might have separate css files for individual UI components, e.g. popup.css, calendar.css etc.
base.css
theme-blue.css
theme-blue-popup.css
theme-blue-calendar.css
This approach makes it easier to manage your styles (and switch them if you need to). More relevant to your question however, is that you now have the ability to specify what stylesheets are needed for each page on your site. Now if the user visits the homepage of your site only, and the homepage has no popups or calendars, then they haven't downloaded the styles for the components they aren't using. As they proceed further into the site, they will get the required stylesheets as and when they need them.
We're being told that fewer HTTP requests per page load is a Good Thing. The extreme form of that for CSS would be to have a single, unique CSS file per page, with any shared site-wide styles duplicated in each file.
But there's a trade off there. If you have separate shared global CSS files, they can be cached once when the front page is loaded and then re-used on multiple pages, thereby reducing the necessary size of the page-specific CSS files.
So which is better in real-world practice? Shorter CSS files through multiple discrete CSS files that are cacheable, or fewer HTTP requests through fewer-but-larger CSS files?
Your first port of call is using YSlow or Google Speed to figure out what is going slowest on your site. Sometimes a badly compressed (large) image or two can be slowing the entire thing down. You are told to reduce HTTP requests because each request has a setup cost associated with it but if taken to the extreme can lead to worse performance. In your case having a CSS file for each page is bad form as it means it is harder for browsers to cache.
Taking one method to the extreme is bad practice and you should attempt to approach this problem from a wide angle such as:
Properly compress images or use CSS sprites (reduces HTTP requests)
Implement proper web caching using Expres, ETag etc (so clients don't have to rerequest everything)
Optimise your CSS and Javascript files using YUI or another similar tool
Improve your CSS / javascript code for performance. Certain CSS selectors can lead to the browser taking longer to render a page
Replace images with pure CSS where possible i.e. background colors etc.
Use GZip compression on any text output i.e. html, css, js
If in doubt, look at the source page for the Google home page. They optimise that page heavily and it will give you good clues on what to do.
I would go for combining all CSS into one single CSS file. Even if you have some redundant styles that won't apply to all pages, after compressing it with Gzip the size should be small enough. And after the browser has cached it, the size no longer matters. Just insert all CSS into one file. However, you have one problem: the styles change for different pages. You have to take another route. You could do, for example, something like:
index.html
<div class="navigation_index"></div>
about.html
<div class="navigation_about"></div>
And then share the similar styles along with the navigation classes like:
.navigation_about, .navigation_index {
color: #000;
}
and specify different options in separate styles:
.navigation_about {
font: sans-serif,
}
.navigation_index {
font: serif,
}
Browsers will cache the css files what ever its big or small, so i prefer making bigger css files with fewer requests.
But this is not a rule, i just try to do that as i can.
well crap, i think theoretically it depends on the site type. If people are going to hit the pages of the site one time, and one time only and theres a lot of pages and such, then having the broken up css files ends up working out better on a graph. Versus a site or web app where everything is getting hit constantly or often enough anyway, then having specialized/compiled css for each page might have a bigger hit at first (on a graph anyway), but then gets cached and you win in the long run b/c of fewer http requests. And then theres some overlap-age there somewhere in the nether regions of mass css hysteria.
Now get away from the graphs and look at your average site, it probably doesn't matter unless you taking on some really serious traffic. But overall ima vote for the latter here.
Just wanted to get a few opinions really, I'm trying to increase the loading speed of my site, and one way that Google pagespeed has suggested is to remove the unused CSS from my CSS file for each page.
At the moment I am using one master CSS file for every page on the site.
My question is would having individual CSS files for each page make overall loading times quicker ? I guess the first page would load quicker, but then each page would have a different CSS file which could potentially end up taking longer over a whole site visit ?
Also pagespeed seems to warn against including multiple CSS files so I guess I can't really 'layer' them up...
If the CSS file is cached then including multiple files will not be an advantage.
Note
For performance rules regarding CSS you can
Try minifying your CSS
Optimize CSS Sprites
Avoid Filters
Avoid CSS Expressions
For more detailed reading go through this
Best Practices for Speeding Up Your Web Site
There are two optimisation directives that contradict each other in this case. Of course you should reduce the size of the files if possible, but you should also have as few requests as possible. Using a global style sheet reduces the number of requests, but it means a larger file.
You just have to look into where your needs are. If you need to reduce the initial load time, you should move styles out of the global style sheet. If you need to reduce the number of requests, you should use a global style sheet rather than individual page style sheets.
Download and install YSlow, it will give you an accurate picture of how fast your page is as well as practical steps to improve performance.
I wouldn't worry about it too much. Run your CSS through a filter to strip comments and whitespace, be aware of small shortcuts like padding: 1em 3em .5em 5px etc, make sure the file is being cached properly, and sent from your server with gzipping, and you'll be fine. CSS is usually such a small fraction of the payload, it's not worth losing sleep over.
The only time where I'd split up a CSS file (for delivery to the client) would be if there were large sections of my site which called for unique styles where most people would never venture: eg, an administration section.
Do a little thinking about how the typical user will use your sight. If (like many sites) the average user only views a single page before moving on, then having dedicated CSS files for each page may just be worth it.
However, in the vast majority of cases, a single css file would definitely be the preferred solution
CSS files are cached by browsers anyway, so either you have a single file or many split, it won't matter after all of them got loaded on the first use.
Use just one CSS for all pages. Once your css is cached then there will be no overhead of downloading that css again and again.
Also, ad adam said Minify your css
DustMeSelectors is the extension you need. It will go through all of your site (and providing all of these are inter-linked) will fetch which selectors in your css are not used anywhere.