i want to eliminate the render blocking from my website, but i can't.
I don't use external css files, or fonts, only just a big css file.
When i copyall content from css file in head AllcontentCSS, render blocking disappear from Google Page Insights
Is there a way to eliminate render blocking and include the css file with link in head instead to copy all css in style tag or is good to insert the css in body tag?
You are most likely looking for:
<link rel="stylesheet" href="yourFile.css" media="none" onload="if(media!='all')media='all'">
But, before you proceed, please read the following resources detailing the technique and its limitations:
initial article by Keith Clark
follow up by Taylor Hunt.
Make sure you also go through the links provided by Taylor Hunt. You probably want to use loadCSS function/polyfill from Filament Group.
But be aware this technique will cause FOUC on your page. You should divide your CSS into two parts:
layout basics (load normally - render blocking),
async styles (load async).
I understand that CSS is used to decide about Layout and other styling things on Web Page. and If CSS is at the bottom of the page then everything (html elements, text, image, etc) will be displayed by using Browser's own styling and when browser find our CSS then it redesign pages again for us. It may be called repainting!
So, I understand that it will look very ugly repainting the page and user seeing it (FOUT - Flash of Unstyled Text - as expert named). But still, I want to understand about:
How much time this repainting can take? Approx value! I understand this can depend on content on the page.
What else happen or can happen?
My main concern right now is about using font-awesome CSS file (externally hosted on their own cdn which download css and font files). I want to know what will happen across devices if I place this at bottom of the page or delay its loading ? Currently it is placed on <head> section as
link rel='stylesheet' href='http://netdna.bootstrapcdn.com/font-awesome/4.0.3/css/font-awesome.css' type='text/css' media='screen'
Use Del so that it should not look main part of the question. Main part of the question is about Some CSS at the bottom then What will happen to repaint, Blocking, etc. with measurement given or supported by measurement etc.
In the above case or in case when only part of document will get affected by CSS at the bottom then what will happen? Browser repaint everything, and what else? How much time it can take. Suppose, font-awesome is used at 10 icons placed in <i>.
I am never sure of what actually happens when CSS is at the bottom. So, please if you have any video or image showing flow then please mention here.
Base everything on performance across devices, and off course user experience as well. Thank you.
Update: I got something more for myself and for everyone.
Here is a function (delayLoadCss) Google suggest for css for below-the-fold content. Though, I am not going to go that extreme but what about doing that for Font-Awesome kind of CSS?
In my experience the loading of css will be virtually instantaneous no mater where it appear on the page--except in one instance: what will cause a delay in the browser applying your css is placing your css after a script element that takes time to complete.
This is why it is considered best practice to end your body section with your scripts, that way your page is rendered and styled before the browser commits to crunching through your scripts.
So if you html looks like this:
<head>
<link rel="stylesheet" type="text/css" href="/css/styles.css">
<script>
[long loading js]
</script>
</head>
<body>
... content
<script>
[long loading js]
</script>
</body>
Then your css will still be applied right off.
However if you structure it like this:
<head>
<script>
[long loading js]
</script>
<style>
[css here]
</style>
</head>
<body>
... content
<script>
[long loading js]
</script>
</body>
or even
<head>
<script>
[long loading js]
</script>
</head>
<body>
... content
<script>
[long loading js]
</script>
<style>
[css here]
</style>
</body>
Then your css will not be applied to the document until after the js has completed.
The first is best practice and I recomend keeping style tags out of your document completely, but certainly out of the body of your document. External style sheets placed above you script tags is the way to go... This is true for font awesome's externally hosted css also. The browser should not hang on rendering that unless your link to it appears after a script element that is taking up the browsers attention.
* EDIT *
However this post directly contradicts what I just said.
There are two cascades that occur with CSS.
The small Cascade: this is the parsing of an individual style sheet
The Big Cascade: This is where the browser performs three "small cascades", in this order:
User Agent (the web browser's native stylesheet)
Author (the stylesheet that you write)
User (the stylesheet the end user can write).
Your question is about what would happen if you put styles anywhere but the head. Let's discuss:
The browser has its own native stylesheet sitting in the background
The browser loads your HTML document first
The browser then reads the <head>
the browser loads assets in the <head>
the browser parses the rest of the document, i.e. the <body>. assets and style rules located here will be processed last.
the last <style> block, or the last stylesheet in your document is the one whose styles over ride everything else.
In a nutshell, the browser applies styles in the order in which they are seen. A stylesheet at the footer would make things worse, not better. I can't offer a quantifiable measurement of worse because I don't have your stylesheets or website.
All Browsers have FOUC (or FOUT). The duration of it is based on the speed of the browser and the quality of your stylesheet. A minified stylesheet which applies text styles immediately after the reset, and before other styles, usually has the least amount of FOUC.
The styles in the footer are not blocked from being processed, and they will not block styles in the <head>, either. Styles in the footer are simply processed last.
I appreciate the answer from Jeremythuff, however I would also like to answer as well and hope it helps you.
Approx it will take a time to download CSS file (if not cached and not inlined) + a moment. This moment depends on CPU, GPU, HD speeds (if cached) and content + scripts as you have already mentioned. In real practice you do not want to use [link href="..."/] at the end of body because of download time.
You also do not want to use inline styles, because they are not cached and this is yet another piece of code users will download with html, however, this solution can work with small inline styles. In practice it does not produce blinks.
I recommend the following schema:
HEAD > MAIN CSS > BODY > HTML > ADDITIONAL CSS > SCRIPTS
If scripts change default behavior of elements (for example preventing a link from clicking) I recommend to put scripts in head instead.
Now about fonts. In my opinion using external fonts is a bad practice. But if you want, fonts better to include in head because you probably cannot inline them in style tag. So the download time problem occurs here.
10 icons is nothing for nowadays CPUs even on mobile phones.
My advices are straightforward:
(if across devices, I also think of page weight because of slow mobile networks)
Have large additional css (significant difference between the size of html with and without css) - do not include at the end nor as [style]...[/style] (never caches), neither as [link href="..."] (takes download time).
Have small additional css - try with [style]...[/style] at the end of the body before scripts.
Do not worry about 10 icons rendering, worry about download time for 1st visiting users (for fonts).
Your questions are interesting... But there's a problem:
CSS stylesheets must be placed in the <head>!! (except if they are scooped)
Otherwise, your html markup is invalid. Then, every browser could handle it differently.
I'm setting up an image cluster for a webpage (similar to sprite-map) for performance reasons. I have a utility that generates the master image, and css to reference the image map.
For simplicity sake, I'd rather include the new css after the regular css file, instead of writing a script to search and replace all the classes in the original css. Something like so in the html (psuedo code):
<LINK href="normal.css" rel="stylesheet" type="text/css">
if(%=usingImageCluster=%)
<LINK href="master.css" rel="stylesheet" type="text/css">
So all the styles that are defined in normal.css would get overridden by the new styles in master.css.
Couple of questions:
Besides the "duplication" of information, does this override cause performance issues?
Will the browser still pull the non-clustered images, because the original CSS file is still included (negating the positive performance gains of image clustering)?
Is there a guarantee that the last loaded style will always be the one applied?
Besides the "duplication" of information, does this override cause performance issues?
Yes, you are generating a new HTTP request for the second external stylesheet. Too many HTTP requests is the #1 slowdown factor for most webpages.
Will the browser still pull the non-clustered images, because the original CSS file is still included (negating the positive performance gains of image clustering)?
Yes, the browser will pull ALL images from the first and second CSS file. Performance time will increase almost linearly (approximate). Especially if you are rewriting every css selector, or changing lots of images.
Is there a guarantee that the last loaded style will always be the one applied?
Yes. Unless the first sheet uses !important on certain style attributes, the last declared styles for a selector will always be applied. This is where Cascading Style Sheets get their name.
How do you usually handle changes to screen and print CSS files? I typically have one screen CSS and one print CSS file and for the most part the I would copy the contents of screen CSS to print CSS file and then modify some properties, classes or ids, maybe set some display:none to certain classes etc.
The problem is, while working on a site or web app I make numerous changes to screen CSS and usually forget about print CSS then I have to sync them from time to time and I just don't think that the most optimal way.
For print stylesheets I tend to also apply the media="screen" stylesheet to the media="print" as well as a second stylesheet that appears later, which essentially, just removes the elements I don't want to print.
It's a fairly simplistic approach, though, and only works to any potential if it's regularly reviewed, so I couple it with a policy of always revising (or, at least, checking) it when I revise the screen-stylesheet.
I'm just wondering what others do in this respect:
Do you try to keep positional CSS (layout) separate from color/flavor CSS (color, background-color, background-images, font-size and family) ?
Use two stylesheets? Combine two stylesheets server-side? Abstraction layer for the CSS?
or you don't even try?
I know sometimes after working on the same web project for six months I can usually live with the positional CSS but end up wanting to change the colors/images.
I tend to keep all the CSS together, without separating "color styles" from "positional styles" or "layout styles". I find that when I often try to debug a specific "module" it's easier to have all the CSS rules applied to one selector, and not spread out over the style sheet.
However, I do suggest you read Creating Sexy Stylesheets over at thinkvitamin.com. One thing I do is list the rules in a certain order everytime, so I know within the declaration block where to find what I want.
More info at Jina Bolton's http://creatingsexystylesheets.com/
You'll find that in large-scale projects, layout and color/flavor CSS will (if you're smart about it) usually just happen to be separate. Firstly, if you're catching yourself setting color/font-size/font-family style rules over and over, you're wasting your time. Typically you should define your fonts in one place: the body tag. Any additional fonts should be defined in their respective tags... h1, h2, p, etc. In my opinion it's not good practice to give these tags positional directives; they should be placed inside a div that will be responsible for their layout. Same goes for color and font size. I think the only exception to the rule would typically be background stuff, which is especially true if you have lots of gradients and fancy things like that.
Really what it comes down to is planning; a well-planned project needs very few color/flavor style rules. So to answer your question, yes, I usually have a "Global.css" file that defines all of my fonts and colors for h1-h5, a, p, and any other tags that will contain text.
Edit:
Usually, since the projects I work in are fairly large-scale and have a number of different modules, we separate the styles with in a sort of hierarchy; this makes sense because of the way CSS works -- as long as you don't change the style-rules put into place at the "base" (or in our case, the global.css) somewhere down the line, the styles will stick. This helps because when we want to modify the font of our site, we simply change the font-family rule at the "body" tag, and it will propagate throughout the entire site.
So, our stylesheet layout works something like this:
Global.css (Fonts/Text/Primary font colors)
--> genericBase.css (basic page structures such as columns that are used throughout the site)
--> nav.css (left-hand nav and/or top nav bar)
--> formLayout.css (labels, inputs, fieldsets, any other form stuff)
-----> forums.css (individual modules' styles that may deviate a bit from the usual structures, or simply things specific to those pages)
-----> blogs.css
-----> messages.css (etc etc etc)
The arrows here are meant to imply the "order" of the files in the hierarchy. The longer the arrow, the further down in the style-sheet the rules these files contain would be, if we had put all of the styles into one file.
So you see, the whole idea is to start with very general styles and work your way down to the most specific. Remember that the order in which your CSS files load matters to the browser. You can use this to your advantage. The interesting thing is, by the time we get to our specific modules' css files, we have very few styles to write because most of the other important stuff has actually work itself out along the way.
So like I said, planning is vitally important. I've found that this methodology makes it easier to "debug" my styles, and I use almost no hacks at all, usually only for silly ie6 stuff.
Let me know if you need more information. I'm glad this is helpful to you.
I used to separate them but it was more difficult to maintain. The problem is that many "formatting" properties will have an effect on the layout and many "layout" properties may actually be design.
Some examples:
While "border" may be considered a "formatting" property, they do take some amount of space so you will need to adjust your layout when setting or removing borders.
"line-height" is tied to the font-size and may be considered a "formatting" property, but it has a huge influence on the size of your elements and how they vertically align each other.
Margins and paddings are sometimes needed for the layout and sometimes used just for formatting.
If you think hard about it, there are very few properties that actually are purely formatting or purely layout.
It's often easier to just keep everything in the same file and try to keep it clean by having your declarations orders, related properties grouped, etc.
I keep everything together in a single file and use the folders feature in CSSEdit to keep it organised. Web design company Viget have a blog post about this technique here.
I separated my layout and color styles recently, and I now have several css files, which i import as follows:
<link rel="stylesheet" type="text/css" href="style.css" media="screen" />
<link rel="stylesheet" type="text/css" href="style-default.css" title="Default Style" media="screen" />
<link rel="alternate stylesheet" type="text/css" href="style-bw.css" title="Black and White" media="screen" />
All layout is in style.css, then colors are in style-default.css.
This way I have a standard style, but users also have the option to change the colors. This not only offers options for the user, but it makes it easy to make color changes without touching the layout (I tend to change my colors much more often).
In Firefox my color options show up in the view menu under "Page Style."
I've fallen into the pattern of separating my CSS out into the following:
Layout (headers, footers, logos - general chrome)
Typography (fonts, sizes, re-usable inline font styles)
Widgets
The latter category is generally made up of CSS code I re-use between projects, and usually gets split down itself into:
Forms (left-aligned, right-aligned, styles for required fields, etc)
Grids (2-col, 4-col, etc etc etc - about 20 or so varieties)
Hacks (IE/other CSS hacks)
Other stuff (AJAX widgets, toolbars, comment boxes, etc - anything re-usable)
For colours, I just keep a cheat-sheet text file around. Keeping them in a separate stylesheet will probably only work if you are very, very disciplined.
I have started to use classes to handle colors specifically.
.element{margin, padding, layout stuff}
.ourcolor{#some color}
It lengthens the class attribute though:
< div class="element ourcolor" >
However, I can reuse the color:
< span class="ourcolor" >Some text
So far I prefer it as adjusting colors is much easier.
As Mark W pointed out, Creating Sexy Stylesheets is a fantastic read. One thing they do advocate is separating the styling concerns through a framework:
screen.css - A screen CSS file can either have all your styles you want to be used for on screen, and/or can import additional styles, such as the following:
reset.css - A reset CSS file can be used to “reset” all the default browser styling, which can help make it easier to achieve cross-browser compatibility.
typography.css - A typography CSS file can define your typefaces, sizes, leading, kerning, and possibly even color.
grid.css - A grid CSS file can have your layout structure (and act as the wireframe of your site, by defining the basic header, footer, and column set up).
print.css - A print CSS file would include your styles you want to be used when the page is printed.
If you follow this pattern, the colors would go in your typography.css, and layout would be in your grid.css.
I keep everything in one file and only provide different files for alternative styles (e.g. for printing).
Within that file I keep the overall layout (columns, headeer & footer) seperate from the actual contents (paragraphs, headings, lists...)
I am used to thinking object oriented, so I group the styles for different objects (menus, blog posts) together. From that perspective, colour and position both belong to the same object and therefore are kept together.
I am wishing for the ability to define colours once in a style sheet, assign them a declarative name (e.g. 'HeadingColour') and then use the name when assigning the colour to a selector...