I have a script that has a jquery script controlling the css(init.js) and another noscript tag with the css files themselves. There are 3 css files for various screen dimensions
However i realise this approach causes the css to keep fluctuating. E.g refresh causes font size to change, refresh again page changes back. The font itself also changes.
Anyone could suggest what may be an issue?
Thanks!
Related
FOUT in SPAs using FEFs. That's a lot of odd acronyms. :)
But it's still an issue.
I have a dynamic component which loads a bunch of components which are meant to look in a very specific way. Each would have its own css, and critically, its own specific fonts.
The fonts are the issue here.
What ways are there to avoid this FOUT in this case?
This is my current research on the topic:
Browsers have a mechanism to hide text it detects is styled with a custom font until the font has loaded.
This does not work in vue, because the text isn't loaded yet either for the browser to detect, so when JS puts the text, this browser mechanism isn't triggered.
Might be fixable via SSR, static DOM - browser can now detect. Still might not want - FOIT (Flash of invisible text) arguably worse (no content vs bad content).
This does nothing for dynamic components
CSS is consolidated unless async component.
You do get all CSS imports, but not all fonts until they are used on the page. I.e. it makes a network request for the css import, but not the fonts, until something on the page gets styled with this font. At least it's... quic. :D
WebFontLoader?
A js library by google/typekit, companion to google web fonts.
Possibly can be used to delay component loading until the font has loaded using its events?
Requires things outside the component to know about the font.
No obvious way to reach down and pull out CSS.
Depending on how many fonts you're loading and the size there are a few things you could do.
Call the fonts in the base HTML file (separate from your other CSS) so the browser is aware of them. Then create a hidden div in the parent component with CSS calling the font for the child. This will cause the browser to request the font before the child component is loaded.
Load all fonts separately in the HTML with rel='preload' or rel='prefetch'. I would do this at the bottom of the HTML so you don't block other content.
Load your fonts in the created lifecycle hook using the CSS Font Loading API. I'm not sure how this will work with Google Fonts vs self-hosting.
Create CSS transitions when loading content like a half-second fade to mask the FOUT. This is obviously not a solution but never underestimate the power of smoke and mirrors to influence the way your app feels.
Also, you should try to make use of the font-display (docs) CSS property. This won't solve the problem but it will make the results more predictable.
I have 2x promo banners one for desktop (#usp-banner), one for mobile (#usp-banner2).
Each one should only be displaying to their respective sizes because of the use of the .css:
layout.min.css
#usp-banner2{display:none}html{padding-bottom:0!important}...
custom.css
#usp-banner2{display:none}
#media (max-width:767px){
#usp-banner{display:none!important}
#usp-banner2{display:inline}
}
Upon loading the page on Desktop or Mobile we see BOTH banners and their correct banner hides after about 1 sec. Source: https://www.ivyandfig.com
I am fairly new to Shopify, but am able to modify templates. I'm curious is this due to the way .css is loaded?
Anyone have suggestions on how to ensure the css is being loaded before the images display (as I am assuming this is part of what is happening)?
Most of the stylesheets and scripts on your site are being loaded via JavaScript. That JavaScript is triggered much later as compared to when the initial content is visible on your site.
As you have guessed, this is happening because CSS is loaded much later so for the time being both images are visible.
As that part is a Shopify section, a quick fix is to include the related CSS rules inside section. More of that is available on Shopify Documentation for Sections.
Another fix may be is to create a separate stylesheet with only rules like that CSS reset, hide and show content etc and include it via link tag in header.
You can also use some logic based on inline styles by hiding both initially and then display later via JavaScript.
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.
I'm using jQuery mobile to create a list menu.
I use a 'slide' effect, when you click an element to show the next page.
I was using a css style sheet which had too many design elements.
So I went ahead and removed the stylesheet and instead added the required styling in the html document.
But now the slide effect doesn't work if I click the elements.
If I include the css style sheet, then it starts working again.
Here is the http://jsfiddle.net/r24XY/ code.
The whole reason why you see those cool looking animations is because of that CSS file.
You must have both JQuery Mobile .js and .css library files in order for things to move.
Ripping certain elements out of the library CSS files just to build your own is a bad idea, very bad idea. What if you miss something ? Even if you don't.. what if they release an update tomorrow? You're going to have to maintain a lot of code.
CSS animations (or transitions / transforms) are used in jQuery Mobile and other mobile web frameworks since these are hardware accelerated on certain devices (namely iOS). Thus, removing the CSS file of course removes the animations.
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.