Talking of Design
The show must go on
This is a bit of a smoke and mirrors way of dealing with FOUC (flash of unstyled content) on your website, while still getting the “Look Mum! I’ve got green on my Google page speed analysis check!”
I call it the “curtain fix”.
I’m well aware that this may have already been done, and that cleverer folk than me may need to put me in my place as to why this is a bad idea.
But anyways
So your website uses some JavaScript to enhance the way it looks and/or performs. You follow the guidelines of placing this JavaScript at the bottom of your page so that CSS and HTML are dealt with first, and — hey presto — your page speed analysis gives you a healthy pat on the back. Have a gold star.
But then you demo the page remotely and — ew — you get a glimpse of the site not looking at its best. This is because the CSS and HTML are rendered before the JavaScript kicks in to add some lippy and do its nails.
So you put the JavaScript in the head, which fixes the FOUC, but then the page speed check does a shit and that gold star you were given is removed, ripped up, and put in a bin somewhere.
Just hide it?
A basic method to avoid FOUC is to add a little bit of inline JavaScript in your head that hides your content, then for some JavaScript at the bottom to show it. So nobody sees your site all unshaven and in its pants. Win.
But then your page speed analysis tool slaps you in the face, as your CSS is considered as a render block, as your HTML is “display:none” hidden, and so the rules are applied to nothing.
Putting up a curtain
So rather than hiding the content, you could write some inline JavaScript and inline CSS in your head tag to create an element on page that “covers” your content, rather than actually hiding it. Some JavaScript at the bottom of your body tag then removes this element.
Page speed analysis is fine with it, as the HTML relating to the CSS is “there”, but just “covered” momentarily.
So think of it like the curtain at a theater. Behind it the actors have their make-up applied and costumes adjusted, the props are put in place, and then — voila — the curtain comes back and the show begins.
The content is there, you’ve just visually hidden it until the stage is set.
And so the code
In your head tag:
<script>
document.getElementsByTagName('html')[0].className+=' fouc'
window.onload = (function(){
var html = document.getElementsByTagName('html')[0].className;
html = html.replace('fouc', '');
document.getElementsByTagName('html')[0].className = html;
});
</script>
<style>
.fouc {
background-color: #fff;
height: 100%;
position: fixed;
left: 0;
top: 0;
width: 100%;
z-index: 9999; }
</style>
window.onload ensures that the class is only removed when everything on page is loaded, so that should any other JavaScript fail anywhere else, your users aren’t left with a blank looking screen.
Why are we waiting?
There is, of course, the issue of the user getting a white screen while they wait for the page to load — especially if it is the first visit to the page, and/or they have a slow connection
To deal with this you might wish to add a loading animation, so the user knows that something is loading. I’d recommend a CSS animation — like the examples at http://tobiasahlin.com/spinkit/. You can add the code to the initial head CSS rule.