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 :)
Related
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.
I have a few lines of styles in every page. I'd rather not to put them in one css file for it might affect the styles of other page.
Do we really need to put the styles on a css file or is it ok to have
<style>...</style>
on every page?
What are the advantages of putting the styles in one page regarding to it's speed?
Does it speed up the loading of a page?
Basically it is a compromise option. Like Marty Wallace and Marc B stated.
The speed aspect is therefore a consequence of the option you take, as they are both valid. Just remember these two factors:
should you choose to use the CSS in the <style> section of your HTML file, it will be loaded everytime with each page load. Therefore, the more CSS rules you have in this section, the bigger the file, hence, longer loading time and slower speed.
If you <link> a stylesheet, that file will be requested everytime you load the page as well. So more or less the same relation to loading time is implied, although it may differ a lot in absolute value.
Also, you should have in mind that most browsers have caching mechanisms to optimize the usage of CSS. Try to read more about it so you can take advantage of it as well.
My opinion is that a mixed approach is probably the best option. Choose the rules that are to be applied to the common elements between your different pages and put them in a linked CSS file. Then, use the <style> tag to set specific CSS for elements on that page. This is my I-don't-care-about-it-that-much way of doing it.
Most of the time I found that CSS doesn't impact performance that much - but of course, it depends a lot on how much CSS you are actually using.
I am wondering if unused CSS styles affect load times because I normally break my sections of my code using this format
/*===================
Nav-Styles
===================*/
However, I also use coda to write my code. It has a code navigator, which detects ids followed by {}
what I thought might help with my code organisation is to create this format of break
/*==========================================
#----NAV-STYLES-BEGIN {} /* Nav Styles */
==========================================*/
This will mean my section breaks will them appear in the code navigator and can be jumped to quickly. However, if this is going to cause speed related issues, the means will outweigh the end.
Is this a bad idea or will the difference be so insignificant that it's worth doing if I wanted?
The answers here are not correct.
Unused CSS does two things:
Adds more bytes that need to be downloaded before the engine can start rendering the page
The browser engine has to go through each css selector to evaluate whether it is on the page and how it should render.
The second part is crucial. If 50% of your css file is unused css, you are essentially have the browser engine take twice as long to render your CSS for the page. Of course, the type of CSS selectors you have matter as well, so the twice as long is more of a easy example than full truth. Never the less, unused CSS increases your browsers page load time, even when the file is cached on the local drive.
Any unused CSS or JS that is passed over the wire to the client will hurt the sites performance at the least to a small degree. The unused CSS increases the size of the page, therefore increasing the time it takes to download a page. A few characters here and there will not have a huge impact on your download times, however if there is a large amount of unused styling there may be an impact. This is why many people compress their CSS and JS.
The effect of this is going to be unnoticeable, and could be described as negligible at best. Regardless, you could use a build script to remove all comments and minify your CSS. This will improve load times, if only slightly.
The short answer - go for whatever is easiest to develop with. You can worry about production later.
I hesitate to add
I have a PHP script that has two CSS files in it's header. One of the CSS files only have about 5 short lines in it.
Is is safe to move that one into the larger CSS file? What's the point of having two separate CSS files when one is only a few lines?
Yes their is a point in it. I have for example a design.css that handles all of the colors, a layout.css pure for positioning and sizes and I have a interaction.css which handles the animations etc..
There is no problem in combining the CSS file as long as it doesnt affect readability.. Just keep in mind that the structure must remain:
file1.css
file2.css
results in on file containing the below code in the same order:
/* content of file1.css */
/* content of file2.css */
No point at all (in this case). You should move the few lines into another.
If you have 2 separate files - there will be 2 requests to the server.
You'll probably not see the difference as these are miliseconds, but it would be a "best practice" in this case.
In essence it helps browsers only load content relevant to the page, speeding up page load times.
There are services that can show how much of your downloaded CSS was applied to a given page.
There is no reason why you shouldnt move it into the same file.
You can have as few or as many CSS files as you need.
The advantage is only really when you have a huge number of styles and the CSS file gets large and unreadable. Then it makes sense to break them down. Or when you want to split them for different pages etc.
Its just an extra request to the server which seems pointless for only 5 lines.
Check to make sure that your PHP script does not reference the CSS file that has just a few lines in it. If it does not, then you're in the clear to merge the two. If it DOES reference it, then consider calling the shorter CSS file inside the larger CSS file like so:
#import url('/css/smaller-file.css');
If you add that to your larger CSS file, then you should be able to just have the larger CSS file in your PHP header.
Hope this helps!
Of course there is a point, just like there is a point in having many files of any languages to organize the content.
As having many requests is a big burden on performances, the usual solution (and mine) is to use a build script to build the version in production by concatenating all the CSS files of the directory into one. The precise way to do that depends on your building
Note that it's similar with what is done with JS files which are concatenated and minified.
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.