Suppose if I have a website http://somethingsomething.com
And I have 3 css file
common.css
homepage.css
inner-pages.css
homepage.css is required for homepage and common.css is for whole site but inner-pages.css is for other pages only and it's big file. Is it possible to load inner-pages.css after homepage data download. In the same way like we use async attribute for script tag. As far as I know async attribute is only for JS not CSS
my one friend suggested to use requirejs for this http://requirejs.org/docs/faq-advanced.html#css but I don't want to use javascript to load css and even I would think upon JS way i would not use require.js just for this. So if it is not possible with CSS only. what would be the simple JS way to do this?
Async CSS with media="bogus" and a <link> at the foot
Say we've got our HTML structured like this:
<head>
<!-- unimportant nonsense -->
<link rel="stylesheet" href="style.css" media="bogus">
</head>
<body>
<!-- other unimportant nonsense, such as content -->
<link rel="stylesheet" href="style.css">
</body>
More at http://codepen.io/Tigt/post/async-css-without-javascript
You can place an iframe in your page pointing to some dummy page that serves the CSS, that should serve the CSS file async.
<iframe src="loadcss.html"></iframe>
Do note it seems pretty trivial, this causes a minimum of 2 css file transfers per page and 3 css file transfers per child page (if it isn't cached). If you were to minify the css you would only have 1 transfer regardless.
try
$.ajax({
url:'/css.css',
type:'get',
success:function(css){
$('html').append('<style>'+css+'</style>');
}
});
or
function getCss(url){
$('<link>',{rel:'stylesheet',type:'text/css','href':url}).appendTo('head');
}
getCss('/css.css');
ok sorry I didn't see you don't want to use javascript
how about using css #import:
<style>
#import url('/style1.css');
#import url('/style2.css');
</style>
Include your CSS in the <body> instead of <head> ... "it seems this trick causes Chrome & Firefox to start the body earlier, and they simply don't block for body stylesheets." and add a condition for IE:
head
<head>
<!--[if IE]>
<link rel="stylesheet" href="style.css"> <!-- blocking, but what else can ya do? -->
<![endif]-->
</head>
body
<body>
<!--[if !IE]> -->
<link rel="stylesheet" href="style.css" lazyload>
<!-- <![endif]-->
</body>
by Taylor Hunt #codepen.io
As suggested Require is not necessary for loading CSS assets. If you want to get your larger payloads asynchronously without relying on JavaScript you should be looking at leveraging HTTP/2 Server Push to deliver your non-critical style assets. And here's a performance technique you may find useful for delivering critical CSS payloads for browsers which works well even today.
Finally, if you are optimizing your pages for performance and don't want to pull in heavy or complicated tools like Require I've an alternative minimal asset loader you may use if you like.
Related
i'm trying to optimize this website: electronicsportsitalia-it and when i try to analyze it on Google PageSpeed the platforms says that there is a google font blocking the page rendering:
https://fonts.googleapis.com/css?family=Lato:300,400,700
The font firstly was loaded through php but then i inserted it directly in html code trying to load it with this code: <link rel=stylesheet id=avia-google-webfont href='//fonts.googleapis.com/css?family=Lato:300,400,700' type='text/css' media=all lazyload> -put also before the </body> tag- but it didn't worked.
So i tryed to load it with Web Font Loader and actually the website is runnging this script:
`
</script>
<script>
WebFont.load({
google: {
families: ['Lato']
}
});
</script>`
but always the same problem on PageSpeed.
Can someone help me?
You can preload any styles (including google fonts)
<link
rel="preload"
href="https://fonts.googleapis.com/css?family=Open+Sans:300&display=swap"
as="style"
onload="this.onload=null;this.rel='stylesheet'"
/>
<noscript>
<link
href="https://fonts.googleapis.com/css?family=Open+Sans:300&display=swap"
rel="stylesheet"
type="text/css"
/>
</noscript>
You can read more on web.dev
UPDATE
Base on Lucas Vazquez comment I've also added &display=swap (which fixes this issue "Ensure text remains visible during webfont load")
You question boils down how to include less critical CSS asynchronously. I recommend to read this article.
Its similar to Claudiu's answer however, it is recommended in the article not to use preload, because of this:
First, browser support for preload is still not great, so a polyfill (such as the one loadCSS provides) is necessary if you want to rely on it to fetch and apply a stylesheet across browsers. More importantly though, preload fetches files very early, at the highest priority, potentially deprioritizing other important downloads, and that may be higher priority than you actually need for non-critical CSS
Here is the alternative:
<link
rel="stylesheet"
href="https://fonts.googleapis.com/css?family=Open+Sans:300&display=swap"
media="print"
onload="this.media='all'"
/>
<noscript>
<link
href="https://fonts.googleapis.com/css?family=Open+Sans:300&display=swap"
rel="stylesheet"
type="text/css"
/>
</noscript>
This is how it works. The attribute media=print will skip the css on page rendering. Once the page has loaded, it will load the print css. The onload JS event changes the media to all, now the font will be loaded and change the page rendering. Most importantly, the font will no longer render-block your page.
For the edge case, that a user has js disabled, the "noscript" tag will load the font directly.
You can take advantage of the onload attribute like this -
<link
href="https://fonts.googleapis.com/css?family=Open+Sans:400,600&display=swap"
rel="stylesheet"
type="text/css"
media="print"
onload="this.media='all'"
/>
Set the media attribute to print at first, but change it to all when the download callback fires.
I noticed that Laravel added this tag to its html head output recently:
<link rel="preconnect" href="https://fonts.gstatic.com">
I copied it and added it before my font request, i.e:
<link rel="preconnect" href="https://fonts.gstatic.com">
<link href="https://fonts.googleapis.com/css2?family=Montserrat&display=swap" rel="stylesheet" id="google-fonts-css">
This simple tag took me from a Mobile Pagespeed score of 80 up to 95, but I can't be entirely sure that it was in fact the tag I have to thank for this score increase - PageSpeed is unpredicatable. I'm not sure if it's just a Chrome thing or a new standard.
In my case, I will generate my font using a font-face generator tool which is easier to use and less hassle but when I use google fonts, this is what I do.
You can use style element at the end of body, just before the closing </body> tag:
<style>
#import "//fonts.googleapis.com/css?family=Lato:300,400,700"
</style>
or you can refer to How to keep CSS from render-blocking my website?
The following font files must be loaded before this JS file: https://electronicsportsitalia.it/wp-content/plugins/google-analytics-for-wordpress/assets/js/frontend.min.js
https://fonts.gstatic.com/s/lato/v14/EsvMC5un3kjyUhB9ZEPPwg.woff2
https://fonts.gstatic.com/s/opensans/v15/DXI1ORHCpsQm3Vp6mXoaTegdm0LZdjqr5-oayXSOefg.woff2
https://fonts.googleapis.com/css?family=Lato
https://fonts.gstatic.com/s/roboto/v18/RxZJdnzeo3R5zSexge8UUVtXRa8TVwTICgirnJhmVJw.woff2
https://fonts.gstatic.com/s/lato/v14/EsvMC5un3kjyUhB9ZEPPwg.woff2
I'm creating a web site using Web Components and Polymer loading assets via HTML Imports.
My markup looks something like the following:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<script src="vendor/webcomponentsjs/webcomponents-lite.min.js" async></script>
<link rel="import" href="assets.html" />
</head>
<body>
In assets.html I explicitly load the CSS in a way that should avoid render-blocking:
<link rel="import" href="vendor/polymer/polymer-mini.html" />
<link href="main.min.css" rel="stylesheet" type="text/css" />
<link rel="import" href="header.html" />
However, when I run my site through Google's PageSpeed Insights I get the following error:
Eliminate render-blocking JavaScript and CSS in above-the-fold content
Your page has 2 blocking CSS resources. This causes a delay in rendering your page.
None of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML.
Optimize CSS Delivery of the following:
http://is-aws-assets.divshot.io/main.min.css
http://fonts.googleapis.com/…y=Source+Sans+Pro:200,300,400,600,700,90
What is confusing to me is that Google's own, official Optimize CSS Delivery guide states clearly that HTML Imports should load CSS without render-blocking:
Note that the web platform will soon support loading stylesheets in a non-render-blocking manner, without having to resort to using JavaScript, using HTML Imports.
Am I doing something wrong? Is this a bug with PageSpeed Insights?
the documentation is right, even though a little ambiguous.
<link> is not non-blocking by default, when it hits a nested CSS resources it blocks rendering.
try adding the async attribute like so:
<link rel="import" ... async>.
http://w3c.github.io/webcomponents/spec/imports/#link-type-import
Depending on the size of your CSS you could also consider inlineing a large portion if not all of the CSS in the head of your element, rather than making a blocking request.
That way you won't have a flash of unstyled content like you would with the async approach, and you wouldnt be blocking your content from displaying.
I'm not seeing this issue in any other browser that I've tested - IE, Chrome, Opera - but whenever I load a page from the server, I'm seeing a flash of unstyled content before the CSS is applied.
This is even happening on subsequent page loads where everything should be cached - every time the page loads I see the unstyled content for a split-second, then everything settles in.
It's also worth noting (perhaps?) that the page is using #font-face to pull some Google fonts. They are stored in a separate stylesheet being pulled after the main responsive stylesheets and media queries.
I've tried a few different things, to no effect:
Rearranging order of CSS stylesheet links
Removing link to stylesheets with #font-face
Disabling Firebug? (Read on here somewhere...)
One other thing that may be worth mentioning is that I used quite a lot of Element Type CSS selectors in the page's CSS. Is it possible that this is slowing down the rendering process?
This seems unlikely as there is no problem immediately re-rendering the page upon changing the dimensions of the window - the responsive stuff renders fine immediately.
So this leads me to believe that there is some issue with how the CSS is being loaded.
Here is my HEAD code:
<!DOCTYPE html>
<head>
<!--<meta name="robots" content="noindex" />-->
<meta charset="utf-8">
<meta name="description" content="">
<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; minimum-scale=1.0; user-scalable=no; target-densityDpi=device-dpi" />
<title></title>
<!-- responsive stylesheets -->
<link rel="stylesheet" href="resources/css/320.css" type="text/css" media="screen and (max-width:320px)" />
<link rel="stylesheet" href="resources/css/480.css" type="text/css" media="screen and (min-width:321px) and (max-width:480px)" />
<link rel="stylesheet" href="resources/css/768.css" type="text/css" media="screen and (min-width:481px) and (max-width:768px)" />
<link rel="stylesheet" href="resources/css/960.css" type="text/css" media="screen and (min-width:769px) and (max-width:960px)" />
<link rel="stylesheet" href="resources/css/960+.css" type="text/css" media="screen and (min-width:961px)" />
<!-- custom fonts stylesheet -->
<link rel="stylesheet" href="resources/css/fonts.css" type="text/css" />
<!-- favicon -->
<link rel="shortcut icon" href="resources/images/ui/favicon.ico">
<!--[if lt IE 9]>
<link rel="stylesheet" href="resources/css/960+.css" type="text/css"/>
<![endif]-->
</head>
WTF is going wrong with Firefox? It's driving me nuts!
If you add a dummy <script> tag right after <body>, Firefox will show the page after all the css from <head> is loaded:
<body>
<script>0</script>
<!-- rest of the code -->
</body>
There is an official bugreport about this FOUC (Flash Of Unstyled Content) on the Firefox site: https://bugzilla.mozilla.org/show_bug.cgi?id=1404468
I had the same problem with Layout was forced before the page was fully loaded. If stylesheets are not yet loaded this may cause a flash of unstyled content. showing in the console, and a visible flash of unstyled content upon page refresh, withouth (F5) or with clearing the cache (Ctrl + F5). Having the developer tools open does not made a difference either.
What helped me was declaring a variable in a script just before the </head> tag ended, so basically after all the <link> tags.
It's important to note, that an empty script (or with just a comment) or any random javaScript would not help, but declaring a variable worked.
<head>
<link rel="stylesheet" href="css/main.css" />
<link rel="stylesheet" href="css/other.css" />
<script>
/*to prevent Firefox FOUC, this must be here*/
let FF_FOUC_FIX;
</script>
</head>
There was no need to rearrange links or not use imports within css or js files.
Please note that the issue will no longer be visible (FOUC is visibly gone), but the console might still show the same warning.
I was experiencing this error. A colleague has said that it's caused by the attribute, autofocus being added to a form field.
By removing this attribute and using JavaScript to set the focus the brief flash of unstyled content stops happening.
For what it's worth, I had this same problem and found that it was being caused by having poorly formatted <html>...</html> tags.
To be precise, in my code I accidentally closed the HTML tag too early, like this:
<!DOCTYPE html>
<html lang="en"></html>
<head>
<title>My title</title>
The code provided by the original poster is missing the opening <html> so I suspect that's probably what is happening there.
Filament Group share they way they load their fonts in detail,
http://www.filamentgroup.com/lab/font-loading.html
which is a nice modern approach to #font-face loading
Smashing magazine also review there website performance and came up with a different solution that stores the caches a base64 copy of the font in local storage. This solution may require a different licence for you font.
A gist can be found at:
https://gist.github.com/hdragomir/8f00ce2581795fd7b1b7
The original article detailing their decision can be fount at:
http://www.smashingmagazine.com/2014/09/08/improving-smashing-magazine-performance-case-study/#webfonts
Additional recommendation
The head of your document contains far to many individual stylesheets, all these css files should be combined into a single file, minified and gziped. You may have a second link for your fonts placed before you main stylesheet.
<link rel="stylesheet" href="resources/css/fonts.css" type="text/css" />
<link rel="stylesheet" href="resources/css/main.css" type="text/css" />
I've had the same issue. In my case removing #import rule in the CSS file and linking all the CSS files in the HTML resolved it.
In my case the reason of FOUC in FF was the presence of iframe on page.
If I removing iframe from markup then FOUC disappears.
But I need iframe for my own hacking reasons so I changed this
<iframe name="hidden-iframe" style="display: none;position:absolute;"></iframe>
into this
<script>
document.addEventListener('DOMContentLoaded', ()=>{
let nBody = document.querySelector('body')
let nIframe = document.createElement('iframe');
nIframe.setAttribute('name', "hidden-iframe");
nIframe.style.display = 'none';
nIframe.style.position = 'absolute';
nBody.appendChild(nIframe);
});
</script>
I've added this inline JS right in template just for readability: in my case this code runs once per page.
I know that it's dirty hack, so you can add this code in separated JS-file.
The problem was in Firefox Quantum v65.
I had the same problem (but also in chrome). Even if many of the existing answers provide clues to the reason for FOUC I wanted to present my problem and its solution.
As I said, I had FOUC in a fairly large project and already had the suspicion of a racecondition in some form.
In the project SASS is used and via a "bootstrap" file for the css a fontawesome free package was added via import.
#import "#fortawesome/fontawesome-free/css/all.css";
This import has increased the total size of the css file by a lot, which caused the file to take a long time to load, and the browser went and already loaded the following javascript.
The JS that was then executed forced the rendering of its content and thus created the FOUC.
So the solution in my case was to remove the big fontawesome package and insert the icons I used from it (~10) via an Icomoon custom font. Not only did this solve the FOUC but it also had the nice side effect that the delivered CSS files are much smaller.
I'm rather new to this so its mostly (copy and paste) with a little YouTube and reading materials here and there.
Why have both? Please simplify you answer, don't go so technical.
<style type="text/css"> is when you want to have style rules embedded within the page.
<link rel="stylesheet" href="path/to/style.css" /> is when you have a separate stylesheet file that you want to reference in the current page - doing this means that clients don't have to download the CSS every time, which makes page-loads faster.
CSS has the #import directive, if you use <style>#import style.css;</style> then it's roughly equivalent to <link rel="stylesheet" href="style.css" /> (but with some minor differences: see Difference between #import and link in CSS ).
Method 1 (using <style type="text/css">)
Is simple way to declare CSS. But it should be used for small codes. When you want to overwrite an attribute of the main stylesheet.
Method 2 (using <link rel="stylesheet" href="path/to/style.css" />)
The first advantage of this method is that, we have a style in an external file. And that means that we can use it repeatedly. But this is not the end of the advantages. You can tell your browser to save the file in the cache. Which reduces page load time.
What is better?
In my opinion Method 2.
Using <style type="text/css"> is for CSS code in your HTML file and <link...> is for including an external CSS file.
The first case <style type="text/css"> is for including css definitions in your html file. The 2nd case puts the css definintions in style.css (or whatever file is the href). The 2nd case makes it easy to use the same css across multiple html files.
The first is used to insert css code directly in your html files, while the second is calling an external css file.
When loading two CSS files via an include I am only seeing one of them being used. The other isn't being included and I don't know why.
I have a standard header file which is included on all of the site's pages.
Example below:
<html>
<head>
<link href="css/jquery-ui.css" type="text/css" />
<link href="css/main.css" rel="stylesheet" type="text/css" />
</head>
This is of course a cut down version of the header for simplification. As you can see both CSS files are within the css directory. but only the main CSS file is being recognised.
Either one of the CSS files cannot be loaded (probably because of a typo or a server misconfiguration). You can detect that by checking that all resources are properly loaded in the developer tools of your browser.
The other cause may be that you're implicitly expecting your own stylesheets to take precedence over the default jQuery UI ones. If that's the case, move your own stylesheets under the jQuery UI one, or make your rules more specific than the default ones.
This is a simple demo that shows that your example works.
Solution:
In your live example, you're missing rel=stylesheet for the jQuery UI stylesheet:
<link href="css/jquery-ui-1.8.13.custom.css" type="text/css"/>
should be
<link href="css/jquery-ui-1.8.13.custom.css" type="text/css" rel="stylesheet" />
You are missing the rel attribute in the first link tag, and most likely this is the reason it's not being parsed as CSS.
Looks like you forgot to close you link tags, just add a forward slash '/' before the closing of both tags.
You're certain the second file is linked correctly? Check Firebug's NET panel, for instance, to double-check that it's loading and not returning a 404 error or somesuch.
You wouldn't be the first developer to be brought down by an unintentional typo!