It doesn't always happen so it makes me think it happens when the browser doesn't have the css cached. What happens is the page loads and you see the entire page without any css and then it "pops" in styled. The css files are hosted off a different domain and they're all in the header of the document. Any thoughts?
Browser around the source I noticed that we have google optimizer code on some pages. Could this cause this to happen?
There might be many reasons, behind this, but as you described:
Your CSS are not included in inside the <head>
Is this perhaps a flash of unstyled content.
Related
With Firefox Quantum I noticed a "glitch" on loading the CSS of some websites.
One of these is my company's website:
Or Github too:
In the first one, we have only one CSS file in the <head> section of our pages.
It seems that - only in Firefox Quantum - the CSS doesn't block the render of the page as it should. The rest of the page loads without the CSS for some instants, then the CSS is applied as if it loads asynchronously (but it's not).
Obviously, this behavior doesn't happen in all the websites I visited.
I really have no clue what's going on :)
To summarize information from bug 1404468, the "flash of unstyled content" ("FOUC") usually happens when something asks for information depending on styles before the stylesheets are loaded:
Scripts on the page that force layout/style recalc, that are executed before the stylesheets are loaded.
It's recommended to "Put all your styles in and make sure that any script that asks for layout information comes after them".
Be careful with defer scripts, which may execute before the stylesheets are loaded (spec bug).
An iframe that loads faster than parent page's stylesheets forces layout of the parent page for complicated reasons, described in the bug.
Addons (example) which ask for layout information before the styles finished loading (i.e. on run_at: "document_end"). Firefox 60 (2018-05-09) fixed FOUC with the addons that queried layout using run_at: "document_idle", and a few add-ons were fixed around the same time.
Firefox had a bug causing it on sites with autofocus, notably GitHub. Also fixed in Firefox 60.
Factors that do not cause FOUC by itself, but can increase the chances of it being visible:
Firefox 53 reduced nglayout.initialpaint.delay (which delays the initial painting of a page after it stopped being blocked by stylesheets, assuming the HTML is not fully loaded by that time) from 250ms to 5ms.
If the FOUC-causing stylesheets happen to load before the delay, you won't see the unstyled content. With 5ms it became much less likely.
If the HTML page itself loads slowly, you may see some content jumping around the page with more likelihood.
Slow network combined with the factors above increases the chances of seeing the FOUC.
Finally, it's common to see the fonts on the web page "upgrade" to page-provided web fonts, because they don't block the initial rendering by design.
Quick fix that worked for me (from vrancken.gilbert in bug 1404468):
<body>
<script>0</script>
<!-- Your code ... -->
</body>
(...) if you add a dummy script right after your tag FF will only render the page when the CSS is loaded.
Additionnal info :
If you manage the Content-Security-Policy (CSP) in your application (prevents inline-script), it's necessary to white-list this line :
For example :
In your application :
<script nonce="JwkbSbZ2MYNwp5Adp8Nk">0</script>
In your 'Content-Security-Policy' HTTP Header :
(...) script-src 'self' 'nonce-JwkbSbZ2MYNwp5Adp8Nk'
Ref : MDN
After spending a while creating an online portfolio, then uploading it, I noticed an issue with one of my sections. On the "Advertisement" section, I noticed it was not displaying the information, just the title. So, I kept on re-pushing the stylesheet.css, even editing it, and it would still look the same. The HTML, CSS, and JS is working how I wrote it. But it is just the section that is not showing. After browsing online and on stackoverflow for an answer, I believe it has to do with Firefox. When using Firebug, I noticed the section's background has been removed, causing the entire section to "disappear." It works just fine on Chrome. I'm not worried about IE, I know that browser has some issues in itself. Anyway, would anyone on here have an idea to resolve this issue, if I can? Or even, what could be causing this issue?
Here is my website to see for yourselves. www.voelkerdesigner.com
Cheers!
It is the opposite for me your entire site works in firefox for me but not in chrome, looking through your code, its being caused by your naming conventions. Namely #advertise
I use the adguard extension in chrome and below is the css it plugs into my html pages to hide ads, so im guessing your using an adblocker in firefox
#adsense_top, #adsensewide, #adspace, #adspace_top, #adspot-300x250-pos-1, #adspot-300x250-pos-2, #adswidget1-quick-adsense, #adswidget2-quick-adsense, #adtext, #adtop, #adv-masthead, #adv-top, #advert1, #advert2, #advertbox3, #advertise, #advertisement1, #advertisetop, #advertising-container, #advertising_wrapper {
display: none!important;
}
Might as well post a random answer on this... As i wont visit posted links by new users.. i'm just gonna guess that your background image might not be 100%...
In general i use background-image instead of background.. Short hand can be a little pain and breaks in some browsers if not perfect.
so i would compare against the following example
background-image:url('images/mybg.jpg');
background-image:url('http://somesite.com/images/mybg.jpg');
Basically alot of people do not use the url and just go straight for a file name or dont quote it.. And have seen that be the problem in the past, so do use the url('') method.
Otherwise if it still fails to work and you know the image is absolute, you would then have some other css that is either over riding your elements background or is preventing it from loading.
Another trick is using your console / inspect element to manually inject the background-image and see if that works... So once the page has loaded in chrome, inspect the element as normal.. And double click on your css property listing as you can add your own styles this way and if it fails, then its not the markup but something else.
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.
what happens to them? are they loaded by the browsers?
should I split my CSS files into more stylesheets, so only images the css/images that are used are loaded on the page?
Seeing as people are saying the same thing I said in my comment I guess I should have added it as an answer.
I was going to recommend firebug, but I believe the images are not downloaded until you reference them in the html. You can confirm this using chrome or ie or firebug developer tools. as far as splitting the css, I would only do so if you have an excessively large css file, or you need to split it up for different css files for browser capability i.e. you have styles that are ie7 or ie 8 specific
Browsers will only download images that are actually used on the page. So images that are specified in CSS as background images will not be downloaded unless that CSS rule is applied on the page.
You can use Firebug or other similar programs to see what is loaded by the browser; however, I believe the answer is that since the DOM element is never created, the image is never requested from the server. No bandwidth or loading time is wasted (other than a few more bytes of CSS, but that shouldn't be too much overhead.)
I am working on a site (www.eticket24.at) and have to create an external CSS for both the header and footer.
If I view the header, for example, seperately in FireFox by going to www.eticket24.at/header.php, it looks fine — the CSS is all there, and it's styled the way it should be. However, in IE8, if I do the same, the style is gone compeletely. It works on the index page, but not when I view it alone.
I am using link rel="stylesheet" href="http://www.eticket24.at/et24_header.css to include the CSS at the top of my header.php page. Same goes for my footer.php page.
So, what's the problem with Internet Explorer this time? Why won't it behave?
Thanks.
header.php doesn’t return a full HTML page, so maybe Internet Explorer is borking on that. Even though Firefox renders it, I don’t think you can necessarily expect all browsers to do so.
As ifaour mentioned, you might want to move your <link> tags into the <head> tag, as they’re not meant to go in <body>.
Your link is inside the body of the page... try putting it inside the <head /> section. Also add type="text/css" to the <rel /> tag.
It's because when you're vewing the header on its own, Firefox will correct the incomplete markup and make the page a valid html document with the <html><body>...</body></html> tags.
IE will not do this, so the styles will not be applied as it doesn't know to do this on an invalid page.
This is also why the page looks correct on the live site.
I included all the css inside the .php files themselves instead of linking them and changed some div names (from to , and to . This helped because css styling of the divs before were being overridden by the other companys css styling, so I had to create my own unique div names, instead of the standard HTML5 ones