I’m not sure if this is in the correct forum, but please bear with me.
I have a client that I’m helping with his website. He is running it through Google’s Page speed Insights and is not pleased with the result, and what he is asking me is, to do something about a rendering blockage. Google has some suggestions here: https://developers.google.com/speed/...izeCSSDelivery, but it seems to be lacking the onload code that is mentioned right after the three code blocks. And that is the problem. This is one of the pages in question: www.upholster.com/howto/index.html. What kind of code do I write, and where? I have searched for ‘onload’ and ‘asynchonous css loading’ and found a couple of things, but I don’t know how to use them, and whether it is the right code for my purpose.
Your help would be greatly appreciated! And please spell it out in detail, because I’m not familiar with js and don’t know where or what I have to (possibly) change to adapt it to the site in question.
It’s not really clear what that has to do with loading JS, but these days, there are three common recommendations for optimising JS delivery:
Minify your scripts. (That basically means removing all the unnecessary white space, and sometimes reducing the length of variables etc. There are plenty of free tools online for minifying scripts.)
Concatenate your scripts. (That means, join them all together into one file. Again, there are tools and processes for this, but if you don’t have a lot of them, or if it’s a one off, it’s easy enough just to paste all the scripts into one file.)
Move scripts to the bottom of the page, just before the closing <body> tag. (This means that the rest of the HTML will load before your script(s), obviating the need for onload scripts etc.)
@ralph.m
It was the correct site you found. I have minified and compressed all that I can compress. I tried your code, changing it like this:
<script type=“text/css” src=“/css/styles.css”></script>, was that correct? And I tried placing it in the head, in the body bottom, to no avail.
@myty
You are right, and I may end up doing that. This client is a friend, and I owe him a favour, so I don’t want to give up until I have tried very hard.
Ralph,
I know how to link to a style sheet, but in this particular case Google’s page speed Insights wand me to have the style sheet load asynchronously, and they have a code example on the page mentioned above, placing the css file at the bottom of the page, even below </html>, like this
<noscript><link rel=“stylesheet” href=“small.css”></noscript>
And below that code example they go on talking about 'The original small.css is loaded after onload of the page. '. Therefore I assumed there has to be some loading script in the document head that causes the page to start loading, with the css kicking in a bit later. Am I right in my understanding of this?
Just placing the noscript at the bottom of the page, without a normal link to the css in the head, leads to nothing. Therefore there has to be some kind of script loading something when the css link is placed in the noscript. It’s that script I’m trying to find, so far without success.
Below the </html> tag is a completely invalid location for anything. The lowest place in the page that anything can be validly placed is just before the </body> tag.
Also the <noscript> tag is long dead. A one line JavaScript in the head of the page to add or remove a class on the HTML tag is far more flexible for deciding how the appearance of the page should change based on whether JavaScript is or isn’t supported than the noscript tag ever was.
The only JavaScript that needs to test for the load event is one that is going to handle where files the page references failed to load. Any other JavaScript (with two exceptions - one the script mentioned above and the other a one line framebreaker) can simply be placed just before the </body> tag and run straight away.
which is not allowed in the head of the page prior to HTML 5 because noscript is a block tag only allowed in the body. Simply get rid of the noscript tags and add a .nojs class reference to all the definitions in that file and change the html tag to <html class=“nojs”>
Then add the following JavaScript in the head of the page:
That way the class will be removed from the html tag if JavaScript is available and so none of the styles in small.css that have the class reference on the front will be applied.
The other alternative is to add a .js to the front of all the styles you want to apply when JavaScript is available and use the following script instead.
‘long dead’ may be interpreted as an opinion rather than stating of fact.
At no point was it stated that the <noscript> tag had been deprecated and no longer in use.
Long dead in the sense that there are simpler ways of achieving the same result in a small fraction of the code that <noscript> usually required.
<noscript> is a block level tag and so every time you want a single character to disappear when JavaScript is enabled you need to repeat the entire block of code it contains in the script if you use noscript.
With a single line of JavaScript you can style the entire page differently depending on whether JavaScript is enabled or not using CSS where you can apply any change to the p[age that CSS can apply rather than just hiding blocks of code as noscript does.
Also by adding further one line tests you can change the appearance of the page using CSS based on whether the browser supports specific JavaScript commands - something noscript cannot do.
I consider any command that has been replaced by a more powerful alternative that involves far less code to be effectively dead even if some people who like typing and making their pages way bigger than necessary decide to continue using it.
In post 6 I gave two alternate one line JavaScripts that can replace all the noscript tags in the page and allow you to use CSS to select what should and shouldn’t appear in each case instead. Why would anyone use noscript instead of that one line of JavaScript - particularly if you have nore than one noscript tag - given that noscript needs to at minimum wrap an entire block - unless of course they sdidn’t realise that the simpler JavaScript alternative existed.
For anyone who actually understands how to use JavaScript the noscript tag is dead as they’d never use it.
I saw that you were trying to help with that line of js you mention. I need a much more detailed explanation, as I said in my first post.
I may not have been able to explain properly what I need, sorry about that, but the fact is that I’m trying to get a grasp of what Google’s PageSpeedInsight actually wants where they say something about rendering blockage and asynchronous loading of css. And since nobody here seems to have understoood my attempt to explain, it must be something very weird that Google wants anyway. I have asked other places and have been ridiculed because of trying something that would be of very little effect as regards page speed. Someone I asked downright refused to waste his time on this. This forum was kind of my last chance
If you think that trying to mess with this asynchronous page loading is wasted efforts, then please tell me so and I’ll shut up.
That’s a correct understanding, yes. The article, as it turns out, didn’t specify that loading script. I presume they omitted it because there are many different choices. Modernizer is common. [URL=“https://github.com/rgrove/lazyload”]LazyLoad is a small and simple option I’ve used before. I think all the major frameworks come with it built in (Dojo, YUI, Closure, etc). Plus it’s simple enough that you could conceivably roll your own (create a link element, set rel and href, and append it to the head).
I can understand the benefit of having a small bit of javascript calling up larger amounts of javascript thereby saving uneccessary BW if javascript is not enabled.
And I can see how applying CSS onload can help with initial page load time (though maybe introducing re-rendering problems?).
But I don’t understand what Insight means by “rendering blockage”.
I know what rendering is, but do they mean blockage as in “preventing” or as in “chunks”?
Browsers won’t paint anything to the screen until CSS files have downloaded. So if for whatever reason a CSS file tends to load slowly, then it should be faster to inline only those styles needed for above-the-fold rendering while the rest are loaded in a non-blocking way (that is, dynamically loaded with JS).
