Came across this fix for the FOUC. It utilizes the fact that the responsive grid classes are not applied until the very end. In summary it shifts down all the page content, and then when the responsive-grid-* classes are applied it overrides that css. I'm sure there are some optimizations that can be made, but this is a first attempt at it.

/* Fixes the "flash of unstyled content" when loading an Omega theme */
html{background-color:#FFF;}
body.html {
 opacity: 0;
 opacity: 0.0;
 -moz-opacity: 0.0;
 filter:alpha(opacity=0);
}
body.html.responsive-layout-mobile, body.html.responsive-layout-normal {opacity: 1;}

Source: https://gist.github.com/1622320

CommentFileSizeAuthor
#11 1407000-FOUC-11.patch2.45 KBgilbot

Comments

Steven Brown’s picture

Steven Brown commented

I'm new to the Omega theme however, I'm not sure what you mean by "flash of unstyled content".

Anonymous’s picture

Anonymous (not verified) commented

If you use the responsive grid, there's a fraction of a second before the javascript applies the correct class to the body. If you subscribe to the "mobile first" design philosophy, this means until that javascript class is applied, the mobile version of the site appears on your desktop for that fraction of a second. The more CSS and javascript you have on the site, the longer this time segment becomes and the more noticeable.

I've leveraged the way this works by moving all body content down below the "fold," then when that javascript class is added move it back up. This way until that javascript class applies, the content is not visible to the user and the first they see of the site is the correct version for their device.

Steven Brown’s picture

Steven Brown commented

I haven't experienced this issue from Omega out of the box. Are you sure there isn't something that has been added that could be causing this issue? I'll need to test it again. Also what browser are you using?

Anonymous’s picture

Anonymous (not verified) commented

Yeah, I work as a Sr Software Engineer for a web development company that has built several D7 sites using the Omega theme. This is an issue we started noticing when moving to the "mobile first" design approach, and is inherent to javascript. There will always be to some extent a lag between download to the javascript parsing, and the larger the site the bigger the issue. For the majority of sites it's been very minimal - but the issue is well documented as are the various approaches. LearningjQuery.com has some interesting ideas to avoid this, as does Webkit.org. It is worth noting however that this mostly applies to "mobile first" responsive design, and doesn't affect your more classic approaches as much.

http://www.learningjquery.com/2008/10/1-way-to-avoid-the-flash-of-unstyl...
http://www.webkit.org/blog/66/the-fouc-problem/

Steven Brown’s picture

Steven Brown commented

I'm not 100% sure if the links you sent are site that do this or not, but if they are I'm not getting the flash issue.

cellar door’s picture

cellar door commented

FatGuyLaughing - what bryanburkholder is describing is common among mobile first responsive sites. The flash of content is less noticeable on sites in which there is minimal js or css that needs to be applied to the page. What I think this fix does is move the content off the page entirely until is is styled and moved back by the regular omega grid css files which are loaded last. The lag depends on the speed of the device that is parsing the files and what has to be done on the site from them. It's a performance tuning issue and makes the screen look as if it is still "loading" (white screen) but in reality it's styling it off page then moving it back in.

Good reference for larger sites that are experiencing this issue, thanks bryanburkholder!

Himerus/Fubhy - should this be rolled into an alpha stylesheet (reset maybe?) for the next update that way it can solve the issue for those who are experiencing it and for those that aren't there won't be any effect to their current sites?

jerryitt’s picture

jerryitt commented

There are several ways around this, I believe its only Webkit based browsers that are affected if memory serves. I have done something very similar to this in the past.
I agree with Cellar Door, perhaps this should be rolled into an alpha stylesheet reset for the next update as it is an easy fix?

Steven Brown’s picture

Steven Brown commented

I don't know what the right answer is but this is basically a CSS hack/workaround to make it work. Although this works, it would be nice if we could implement something more concrete.

Anonymous’s picture

Anonymous (not verified) commented
Issue summary: View changes

Modified code to fix issue with IE browsers

Anonymous’s picture

Anonymous (not verified) commented
Issue summary: View changes

Code fix to prevent WYSIWYG issues.

Anonymous’s picture

Anonymous (not verified) commented

Slight change to the original code. Now using opacities instead of margins - better browser performance and no worries about larger screens.

lewisnyman’s picture

lewisnyman
he/him
commented

The problem with this javascript is it runs too late, the resize function is called on window.load, which is long time after the page has been rendered. I played around with the Javascript, calling the resize function in behaviours is still too late to prevent the FOUC.

This function is essentially filling the same role as the Monderizr add class function, it needs to run as early as possible because it affects how the dom is rendered.

gilbot’s picture

gilbot commented
Status: Active » Needs review
StatusFileSize
new 1407000-FOUC-11.patch2.45 KB

Based on LewisNymans comment, here is a patch which removes the behavior and runs the code without the FOUC

gilbot’s picture

gilbot commented
Issue summary: View changes

Performance tweak