I have developed an application that is meant to be used offline. It is deployed with it's own, custom tailored, web server and uses default browser to connect to it.
Since it's offline, I also have fonts stored in filesystem, that are loaded with #font-face. Apparently, due to many styles and character sets, they take up some time before the browser load them.
I'm testing it with Chrome (latest), and the flash of unstyled text (FOUT) is really annoying.
How could I reduce the FOUT when working in local context?
How about hidding the entire html, or all of the text, before your css file is loaded?
At the top of your head you'll include inline styles likeso:
<head>
<style>html{visibility: hidden}</style>
<link rel="stylesheet" href="/static/default/style.css"/>
</head>
At the bottom of style.css, or after the #font-face declarations, you'll make the html visible again:
html {visibility: visible}
Related
I'm having an issue with FontAwesome (v4) webfont icon rendering in Chrome when Chrome's caching is enabled. Intermittently, across multiple user machines, a page will load with our FontAwesome icons displayed incorrectly as below. This issue happens only occasionally and can't be reliably reproduced or narrowed down to a single page. The only common repro steps are using Chrome and not having "disable cache" enabled in dev tools or elsewhere.
Checking dev tools computed styles for the icon elements reveals that Chrome is correctly detecting the specified font-family as "FontAwesome", but the <i> tags for the icons are being rendered in Times New Roman, rather than the FontAwesome webfont. The "FontAwesome" #font-face declaration and the above rule assigning font-family: FontAwesome to the .fa class exist in the same stylesheet, site.css, which is causing the issues.
Checking the source below, we see that site.css is properly specified in the site's <head> tag. It isn't being added to the <head> through JavaScript; it's present in the in the initial page loaded by the browser. The href points to the correct stylesheet, which loads without issue when opened in a new tab. This isn't very surprising, since all of the styles specified in site.css are correctly being applied to the page (except for the webfont, of course). Even the .fa's font-family rule is being read correctly by Chrome, as shown in the computed styles in the screenshot above.
My suspicion is that Chrome is loading the stylesheet from cache in a weird way that's allowing all of the styles to load but is interfering with the creation of the FontAwesome webfont. Potential evidence for this below:
Above is a portion of the network tab from the dev tools session. Nothing has been filtered out, but site.css has no entry in the list of requests, even though other cached stylesheets are present and the styles from site.css are being applied to the page. There are entries for theme.css, jQuery, AdminLTE, and other stylesheets specified just after site.css in the same <head> block. It's not pictured, but the fontawesome.woff2 webfont file, specified in site.css's #font-face declaration for "FontAwesome", is also being successfully loaded.
Refreshing the page or navigating to another one sometimes fixes the issue. Refreshing with cache disabled always fixes the issue. Every page of our (quite large) web app loads this stylesheet using the same <link> tag, and while this issue pops up fairly rarely, it has happened across many of those pages. The site.css stylesheet is clearly being loaded by Chrome, as it sees the font-family: FontAwesome rule along with the rest of our site styles. But something seems to be happening during the loading of the stylesheet from cache that's causing Chrome to fall back to Times New Roman despite the webfont being both declared via #font-face and specified as the font-family for the affected elements.
We aren't using a service worker or any server-side caching. We do some cachebusting via a GET parameter as shown in the screenshots above (the ?[productName]Version=2.0.13292.0), that value is baked into the initial document loaded by ASP.NET and changes only when our backend server's version changes -- so that shouldn't be the cause of the issue here.
Has anyone experienced anything similar with Chrome webfonts?
I had the same problem. My compiled CSS file was missing #charset "UTF-8"; and as a result, the cached icons font was broken. Please check if this helps you.
On my vue PWA the css from vue bootstrap and buefy seems to undergo Slow loading of CSS.
I've tried V cloak, but it only hides components ms. after you see a see a glimpse of raw html with no css.
I'm trying to find a way on how to get a loader to show or something that hides the first milliseconds of html blocks or initially fix how the html blocks don't show without any style/don't show at all like on the gif below.
I appreciate any solutions here.
(Can't show image/gif here due to reputation rule)
Click here for gif
The gif shows that the js is loaded before the css. This usually means that the css file is referenced too late in your index.html file. References (usually <link> elements) are loaded in the order that they're listed in html. Check your site in the inspector, and see where your css is listed
<link href="/app.js" rel="preload" as="script />
<link href="/app.css" rel="stylesheet" />
<style type="text/css"> ... </style>
// app.js should come first
This should be done automatically by vue-style-loader, which should be included in vue/cli-service. Are you using the vue cli?
Something strange is happening and I can't figure out why: On my website I have the following CSS for providing Ionicons:
<link rel="stylesheet" href="https://www.domain.tld/themes/places/assets/fonts/ionicons/css/ionicons.min.css">
I decided to move them to CloudFront CDN, now the link looks like this:
<link rel="stylesheet" href="https://[...].cloudfront.net/assets/fonts/ionicons/css/ionicons.min.css">
The link is not broken, the same CSS are now accessible through the CDN, but the Ionicons are gone - I see empty rectangles only. When I change the link back to my server's local CSS file, the icons appear again. Everything else (CSS, JS, Images), which has been moved to the CDN, works as usual - only the Ionicons not. Does someone has an idea where this strange behaviour comes from?
I noticed that when my web page was loading, all of the CSS files loaded first, then the fonts after all of those were done. Is there a way to make the fonts start loading at the same time as the stylesheets?
I'm using #font-face with a url. Would encoding the font in the stylesheet solve this problem?
i haven't experienced this kind of scenario of yours..i'am fond of using embedded fonts on my webpages..i would like to share what i did as what i see to make them synch on web page load..i have a font.css where i embed all the fonts i needed like this:
#charset "utf-8";
/* CSS Document for Fonts :)*/
#font-face{
font-family: trajan;
src:url(../fonts/TrajanPro-Regular.otf);
}
and the url resides on the directory inside the web app..i just link this to the web page then use the defined font on other css directly..hope i got your point and explained the right thing..thank you
While using #font-face HTML5/CSS3 loads the page, and you slowly see the fonts appear. Is there no way to load the fonts first?
You might get some luck (especially in the future) with link prefetching:
<link rel="prefetch" href="pathto/font">
(only supported by Firefox, at the moment). If you use this on a page before the page where #font-face is used, the font file can be in the cache before it is actually used.
There is now a draft for preload which is going to be released with Chrome 50.
With this feature we should be able to do this in the head element and probably flush it before the rest of the html is rendered and sent to the browser
<link rel=preload as=font href=...>