Simple question hopefully.
We have a style sheet that is over 3000 lines long and there is a noticeable lag when the page is rendering as a result.
Here's the question: Is it better to have one massive style sheet that covers everything, or lots of little style sheets that cover different parts of the page? (eg one for layout, one for maybe the drop down menu, one for colours etc?)
This is for performance only, not really 'which is easier'
3,000 lines? You may want to first go in and look for redundancy, unnecessarily-verbose selectors, and other formatting/content issues. You can opt to create a text stylesheet, a colors stylesheet, and a layout stylesheet, but it's likely not going to improve performance. That is generally done to give you more organization. Once you've tightened up your rules, you could also minify it by removing all formatting, which might shave off a little bit more, but likely not much.
Well, if you split those 3k lines into multiple files the overall rendering time won't decrease because
All 3000 lines will still need to be parsed
Multiple requests are needed to get the CSS files which slows down the whole issue on another level
According to this probably reliable source one file, to satisfy rule 1 (minimize http requests). And don't forget rule 10, minify js and css, especially with a 3000 line monster.
It'll be worse if you split them up because of the overhead of the extra HTTP requests andnew connections for each one (I believe it is Apache's default behaviour to have keep-alive off)
Either way, it all needs to be downloaded and parsed before anything can happen.
Separating that monster file into smaller once (layout, format and so on) would make development more efficient. Before deployment you should merge and minify them to avoid multiple http requests. Giving the file a new number (style-x.css) for each new deployment will allow you to configure your http server to set an expire date far into the future and by that saving some additional http requests.
It sounds like you are using CSS in a very inefficient way. I usually have a style sheet with between 400 and 700 lines and some of the sites that I have designed are very intricate. I don't think you should ever need more than 1500 lines, ever.
3000 lines of code is far to many to maintain properly. My advice would be to find things that share the same properties and make them sub-categories. For example, if you want to have one font throughout the page, define it once in the body and forget about it. If you need multiple fonts or multiple backgrounds you can put a div font1 and wrap anything that needs that font style with that div.
Always keep CSS in one file, unless you have completely different styles on each page.
the effort of loading multiple css files stands against the complexity (and hence speed) of parsing as well as maintenance aspects
If certain subsets of the monster file can be related to certain html pages (and only those certain pages) then a separation into smaller units would make sense.
example:
you have a family homepage and your all.css contains all the formats for your own range of pages, your spouse's, your kids' and your pet's pages - all together 3000 lines.
./my/*.html call ./css/all.css
./spouse/*.html call ./css/all.css
./kid/*.html call ./css/all.css
./pet/*.html call ./css/all.css
in this case it's rather easy to migrate to
./my/*.html call ./css/my.css
./spouse/*.html call ./css/spouse.css
./kid/*.html call ./css/kid.css
./pet/*.html call ./css/pet.css
better to maintain, easier to transfer responsibilities, better to protect yourself from lousy code crunchers :-)
If all (or most) of your pages are sooo complex that they absolutely need the majority of the 3000 lines, then don't split. You may consider to check for "overcoding"
Good luck
MikeD
The only gain in dividing your CSS would be to download each part in parallel. If you host each CSS on different server, it could in some case gain a bit of speed.
But in most case, having a single 3000 lines of code CSS should be (a bit) faster.
Check out the Yahoo performance rules. They are backed by lots of empirical research.
Rule #1 is minimize HTTP requests (don't split the file--you could for maintenance purposes but for performance you should concat them back together as part of a build process). #5 is place CSS references at the top (in < head>). You can also use the YUI compressor to reduce the file size of CSS by stripping whitespace etc.
More stuff (CDNs, gzipping, cache-control, etc.) in the rules.
I have a site css file that controls the styles for the overall site (layout mainly).
Then I have smaller css files for page specific stuff.
I even sometimes have more than one if I am planning on ripping out an entire section at a later date.
Better to download and parse 2 files at 20kb than 1 file at 200kb.
Update: Besides, isn't this a moot point? It only has to be downloaded once. If the pause is that big a deal, have a 'loading' screen like what GMail has.
3000 lines is not a big deal. If you split them into multiple chunks, it still needs to be downloaded for rendering. the main concern is the file size. i have over 11000 lines in one of our master css file and the size is about 150 kb.
And we gzipped the static contents and the size is drastically reduced to about 20 kb.. and we didnt face any performance issues.
Related
I have a style.css file and almost every component on the website is using rules from this file, but not always for example I have a main template and then a section where requested pages are displayed and of course requested pages sometimes have parts which are unique(not in other pages) and use rules from style.css.
my question is what happens to the css rules that are not used by the current page?
Let's assume that there's a login page and in the login page there's some special button called button_xyz (only exists in login page). The css rule for this button is inside style.css - What happens to this rule when a page, which does not require this rule, is in use?
Does it use extra memory?
Does the browser optimize this for you?
Unused CSS rules probably use a little extra memory, but not on a scale that matters for even the weakest of devices. Some additional time will also be spent parsing the CSS, but not on a level you'd likely be able to even measure.
The main concern about unused CSS rules is that it's wasted bandwidth, but if you only have a few that would be unused on each page I'd say it's best to stick with putting all styles in one file and making sure it gets cached by the browser.
Unless your CSS is drastically inefficient, bandwidth shouldn't be of concern, assuming your server gzips files to send them to your visitors. The bandwidth used really is nothing at all these days. It won't make much difference, but you may also be interested at looking into minifying your CSS, and also HTML and JavaScript while you're at it.
the unused css rules will be a burden for your user who access your website.
because the user first time access your website will download all your css and javascript after that cache it in your web browser. if there are many unused css it size will become big
Css matches your rules based on regular expressions. You have a database inside your browser for exact match, where some kind of hash table works to match exactly name A to name B and since CSS supports Regular Expressions, it can also search with a while loop if regular expression is supplied. For ApplyToAll aka *{ it's also some kind of optimization similar to hash table which applies a rule to everything on the site. So in case you don't have regexes and you don't since in stylesheet they are complex to write, your site won't slow down.
I'm working on a web app; one of the screens requires some CSS that's very specific to that page (i.e., it isn't used anywhere else in the app/site).
So - I have three options:
Include it in the global CSS file
Include it in a page-specific CSS file
Include it in the <head> of the page
The downside of option 1 is that the CSS will be loaded when when the user visits any screen of the app, even if she never visits this specific screen (which is quite likely).
The downside of option 2 is that it's a separate HTTP request; since the CSS itself is trivially small (<1kb) - it seems like the overhead of the http request itself is worse than the actual bandwidth to download the data.
The downside of option 3 is that the user will download the CSS every time she visits the page (i.e., the CSS won't get cached). But since this is an infrequently viewed page (and seldomly revisited page), this seems minor.
To me - it seems like option 3 might be the best. But everything I read seems to discourage that approach.
Given how hard experts push CSS sprites to minimize http requests, doesn't the same logic apply to a tiny CSS file? So, why isn't #3 a good option? Are there other considerations I've missed?
For what it's worth - it seems like this same question applies to any page-specific JavaScript; I could include that in a <script> tag at the end of the page, or in a separate .js file.
Thanks in advance.
Put it in the head and move on to other problems. :)
"Programmers waste enormous amounts of time thinking about, or
worrying about, the speed of noncritical parts of their programs, and
these attempts at efficiency actually have a strong negative impact
when debugging and maintenance are considered. We should forget about
small efficiencies, say about 97% of the time: premature optimization
is the root of all evil. Yet we should not pass up our opportunities
in that critical 3%." --Donald Knuth
If you're using it in a single page, you'd best include it in the <head> directly. It results in fewer HTTP requests going through, less bandwidth usage, and marginally faster loading.
You can also consider using a combination of an internal and external stylesheet: for stuff that you might use site-wide, like the styles for h1, h2, h3, and so on, link to an external stylesheet. For stuff specific to the one page, like the background-image, put style in the <head>.
Sometimes when I look at style sheets of big websites (even this one) the css code is completely formated (or however you call it), like this: http://cdn.sstatic.net/stackoverflow/all.css
Is this just the result of a style sheet beeing generated by a CMS ?
I call it "minified", and I think that's the general term. But the reason is to reduce loading times. All those useless spaces and comments still count as bytes, and sometimes you can have more spaces and comments than actual effective characters! (It also obfuscates the stylesheets, although that's really pointless as spaces can easily be restored with whatever formatting you need.)
It's probably generated on the fly from a more scriptable/dynamic/dry layout language, and there is simply no reason to add the whitespaces since non-one should be reading them, and it would only add to the file-size.
It can be generated by CMS or manually. Removing all the tabs and spaces reduces the size of the file, thereby loading it faster an inturn can make a site faster.
Most web pages are filled with significant amounts of whitespace and other useless characters which result in wasted bandwidth for both the client and server. This is especially true with large pages containing complex table structures and CSS styles defined at the level. It seems like good practice to preprocess all your HTML files before publishing, as this will save a lot of bandwidth, and where I live, bandwidth aint cheap.
It goes without saying that the optimisation should not affect the appearance of the page in any way (According to the HTML standard), or break any embedded Javascript or backend ASP code, etc.
Some of the functions I'd like to perform are:
Removal of all whitespace and carriage returns. The parser needs to be smart enough to not strip whitespace from inside string literals. Removal of space between HTML elements or attributes is mostly safe, but iirc browsers will render the single space between div or span tags, so these shouldn't be stripped.
Remove all comments from HTML and client side scripts
Remove redundant attribute values. e.g. <option selected="selected"> can be replaced with <option selected>
As if this wasn't enough, I'd like to take it even farther and compress the CSS styles too. Pages with large tables often contain huge amounts of code like the following: <td style="TdInnerStyleBlaBlaBla">. The page would be smaller if the style label was small. e.g. <td style="x">. To this end, it would be great to have a tool that could rename all your styles to identifiers comprised of the least number of characters possible. If there are too many styles to represent with the set of allowable single digit identifiers, then it would be necessary to move to larger identifiers, prioritising the smaller identifiers for the styles which are used the most.
In theory it should be quite easy to build a piece of software to do all this, as there are many XML parsers available to do the heavy lifting. Surely someone's already created a tool which can do all these things and is reliable enough to use on real life projects. Does anyone here have experience with doing this?
The term you're probably after is 'minify' or 'minification'.
This is very similar to an existing conversation which you may find helpfull:
https://stackoverflow.com/questions/728260/html-minification
Also, depending on the web server you use and the browser used to look at your site, it is likely that your server is already compressing data without you having to do anything:
http://en.wikipedia.org/wiki/HTTP_compression
your 3 points are actually called "Minimizing HTML/JS/CSS"
Can have a look these:
HTML online minimizer/compressor?
http://tidy.sourceforge.net/
I have done some compression HTML/JS/CSS too, in my personal distributed crawler. which use gzip, bzip2, or 7zip
gzip = fastest, ~12-25% original filesize
bzip2 = normal, ~10-20% original filesize
7zip = slow, ~7-15% original filesize
I have a 50x50px div I want to display on my homepage as fast as possible.
Is it faster for me to do
<div style="height:50px;width:50px">
Or to assign it a class to avoid the inline style:
<div class="myDiv">
And put the myDiv class in a CSS file in the HEAD section of the HTML page?
My thought was that the first one should be faster since it doesn't need to request and recieve a CSS? I guess ultimatley I'm asking if BODY and HEAD get rendered sequentially or in parallel.
Without HEAD loading first there can be no BODY.
Before your BODY gets rendered, it has has to be loaded first. And if it is loaded, then the HEAD has already been loaded.
You're probably interested in whether a browser can load simultaneously both CSS files and the HTML document itself. It will depend on the browser implementation, but I believe most can download at least two documents simultaneously.
One other important thing is that the more files a document consists of, the more chances the request for one of them gets lost. So by using inline CSS you make sure the CSS never gets lost.
But I must point out that inline CSS is considered a bad style. Once you have a sufficient amount of markup, you will find it increasingly difficult to update your pages all at once. You will inevitably be losing one or the other instance. It is a much better idea to declare all styles in a separate document and reference them from pages. This way, when you need to change some color, you do it in one place and not in 37 places to be found in your pages.
As others already pointed out, the right thing to do would be to put the styles in an external file and refer to it in the <head> part of your document.
But if you're going for fast (and this is what you were asking for) then you should use the inline-declaration like
<div style="height:50px;width:50px">
There are several reasons for that:
You don't have to load an external file. This is very slow (compared to the next reason) since there is an additional HTTP request involved which (on top of the request and download itself) might be held back by other external files like JavaScript, favicons etc.
So it will already load faster if you put your declaration in some <style> tags on the same document. But then there is the next reason.
The browser does not have to look through the DOM tree and search for nodes with the class myDiv to apply the styles to. It finds the <div> and immediately (or at the next render turn) applies the style information.
This second delay will hardly be noticeable but if you are going for high performance, this is the way to go.
I agree that these may somewhat be theoretical reasons but here you go. :-)
There are cases when this would be a "good" practice. For example, you have a high value landing page, that requires about 500 bytes of CSS to support, verses the 200K Style sheet.
While true, that they customer will have to download that file on the NEXT page, time to render is often most important on the landing page.
Also, AFAIK, browsers will not begin rending until the entire CSS file is downloaded, which is not the case for inline styles. But yes, Best Practices, and 98% of the time you want to put CSS in a single linked file.
Use an embeded css file. After the first request the file will be cached by the browser and won't have to be downloaded again. Making the page load faster and reducing the strain on your server.
Placing styles inline is not only ugly it also undermines the whole cascading thing.
The differences in performance will be imperceptible and should be irrelevent. Instead of worrying about premature optimisations like this be more concerned with doing the "right thing" - and in this case the right thing is to use external style-sheet files for your CSS as it is more maintainable and separates concerns.