I just discovered Google Web Font and I was really interested in how this tool could work...
With just a
<link href='http://fonts.googleapis.com/css?family=Gloria+Hallelujah' rel='stylesheet' type='text/css'>
You can use whatever Google has in his fonts collection.
Do you have any idea on how this stuff works ?
It simply returns CSS that includes #font-face rules that allow you to use fonts that are accessible over the web versus on the client's local machine. Note that not all browsers support #font-face.
Choose a font here
http://www.google.com/webfonts#ChoosePlace:select
and select Quick use
When you're on the font page, scroll down a little and you'll have 3 choice to add this font in standard mode, #import or javascript.
This stuff is simply working by loading the #face-font from Google's server without you have to install them on yours. This could result to a faster loading but more you and custom web font, more time it will take to load. So choose wisely.
Related
This is my first qeuestion here.
I have searched for a solution to this, but whatever I've tried did not work.
I use Newspaper theme on my website and one of the problems which causes around 6 seconds of delay of mobile website loading is the problem with the newspaper.woff fond preloading.
I have added the following code to functions.php for both mobile and desktop version:
// Preload Newspaper fonts for responsive theme (main theme)
function dns_prefetch_responsive() {
echo "<link href='https://jakaoferta.pl/wp-content/themes/Newspaper/images/icons/newspaper.woff?19' rel='preload' as='font' type='font/woff' crossorigin>";
}
add_action( 'wp_head', 'dns_prefetch_responsive', 0 );
Also, added this to header.php:
<link rel="preload" href="/wp-content/themes/Newspaper/images/icons/newspaper.woff?19" as="font" crossorigin>
However, Google PageSpeed does not understand this has been done and still shows the issue.
On GtMetrix it is shown I load the font from two sources now.
What should I do so that this will start working properly?
when trying to preload font crossorigin should be set to anonymous (eg: crossorigin="anonymous") fonts are expected to be fetched anonymously, without this attribute, the preloaded font is ignored by the browser, and a new fetch takes place.
You should also use direct pathing instead of url pathing. This is ok /wp-content/themes/Newspaper/images/icons/newspaper.woff?19 ... This is not ok https://jakaoferta.pl/wp-content/themes/Newspaper/images/icons/newspaper.woff?19
<link rel="preload" as="font" type="font/woff" href="/wp-content/themes/Newspaper/images/icons/newspaper.woff" crossorigin="anonymous">
You can instead use the rel="prefetch" attribute to tell the browser to prepare the download of the resources that may be required later during page load or user actions so it will assign a low priority to those resources. This will result in a default load font then a switch to the custom one later on. (we're not waiting on the font to load before showing the content, which is I think default behaviour).
Stuff to know regarding font loading and browser default behaviours... Edge (even tho nobody use it) uses a system font until the custom font is ready, then swaps out fonts.
Chrome will hide text for up to 3 seconds. If text is still not ready, it will use a system font until the custom font is ready. Firefox will hide text for up to 3 seconds. If text is still not ready, it will use a system font until the custom font is ready. Safari hides text until the custom font is ready.
Taking a look at your website page-source I can see that you're currently loading your font 3 times (probably once in style.css, once in function.php and once in header.php), which is probably causing major performances loss. loading it only once is sufficient. Loading through cc is the least recommended regarding performances. Best practice is to register and enqueue from function.php
Following is the output from your website source code:
<link href='https://jakaoferta.pl/core/assets/13c402efbe/images/icons/newspaper.woff?19' rel='preload' as='font' type='font/woff' crossorigin='anonymous'>
<link rel="preload" as="font" href="https://jakaoferta.pl/core/assets/13c402efbe/images/icons/newspaper.woff?19" data-wpacu-preload-font="1" crossorigin>
<link rel="preload" as="font" href="https://jakaoferta.pl/core/assets/13c402efbe/images/icons/newspaper.woff?19" data-wpacu-preload-font="1" crossorigin>
Finally i would highly suggest using Google Fonts https://fonts.google.com/ for future projects. Google Fonts makes product and web pages run faster by safely caching fonts without compromising users’ privacy or security. Cross-site caching is designed so that you only need to load a font once, with any website, and we'll use that same cached font on any other website that uses Google Fonts.
In short, if somebody visit a website that uses the same Goole font, upon visiting your website that person wont have to download it nor cache it again.
Google Pagespeed test doesn't recognize preload when it is used together with stylesheet. I tried
<link rel="preload stylesheet" href="http://www.example.com/style.css" />
and it still shows "Consider using to prioritize fetching resources that are currently requested later in page load.". If I remove stylesheet from rel attribute, it recognizes the preload.
I was thinking to try this:
<link rel="preload" rel="stylesheet" href="http://www.example.com/style.css" />
but I am not sure if you can have 2 the same attributes for the same link tag. Would this work?
For loading CSS styles asynchronously, you should indicate it, as a preload stylesheet. Whenever you use rel="preload" alone, it won't transform to stylesheet on page load and it will remain as preload, so to indicate it as stylesheet you should use another attribute such as as which indicate the type of element and in your case, it should be style. Then you need to tell the browser whenever the loading process got finished you need to consider this as a stylesheet, so you have to define another attribute like onload and then define its real relation.
so you have to import it like this:
<link rel="preload" as="style" onload="this.rel='stylesheet'" href="http://www.example.com/style.css">
NOTE: You can read more about it here in google developers.
UPDATE
Since preload is not supported in firefox until now (according to this), the only way to do it, is to declare it twice in the one rel tag or two separate tags.
<link rel="preload" as="style" href="http://www.example.com/style.css">
<link rel="stylesheet" href="http://www.example.com/style.css">
Or
<link rel="stylesheet" rel="preload" as="style" href="http://www.example.com/style.css">
NOTE: As #JohnyFree tested the second one (one with a line through) in the Google page speed, it won't be recognized as valid preload style, whilst the format is valid according to W3.org.
preload https://web.dev/defer-non-critical-css/
<link rel="preload" as="style" onload="this.onload=null;this.rel='stylesheet'" href="http://www.example.com/style.css"/>
fallback for not supported browsers https://www.filamentgroup.com/lab/load-css-simpler
<link rel="stylesheet" media="print" onload="this.media='all'" href="http://www.example.com/style.css"/>
If you feel you need to do this Javascript circus trick to save a few hundred milliseconds, I recommend the version below. Use it instead if you want cross-browser support:
<link media="print" onload="this.media='all'" rel="stylesheet" type="text/css" href="style.css" />
Why does this work? In nearly all browsers going back to the 1990's, support of linked "print" media type style sheet was universally supported. Linked print style sheets were only used when printing pages. Because browsers knew the "sheet" media type must always be downloaded before "print", they often delayed or downloaded sheets with "media=print" asynchronously. Nothing was needed by the page author. It has worked this way for many years in most browsers, naturally.
Recently, developers trying to follow Google's new ranking policies discovered this trick to stop some styles from blocking others or from downloading immediately. They then realized the "print" media type was the only built-in, cross-browser way to fool browsers into delaying downloading of style sheets.
Turning your style sheet into a "print" type using the trick above doesn't mean its "print", as the script later changes it back to "all". It is simply a "hack" or way to prevent modern browsers from downloading your CSS styles in parallel with other sheets.
Note: "all" is not supported in a wide range of older browsers including Internet Explorer versions 1-7, so a bad idea, anyway.
Stopping one or two style sheets from blocking another sheet from downloading would be the only reason to use this trick, and assumes you are using a HUGE style sheet that is 50+ kilobytes in size and use a server with slow connections.
RECOMMENDATIONS?
I recommend you do NOT ever "preload" CSS for the following reasons!
Just because Google flags this as an issue in Lightspeed, doesn't mean filling your webpages up with duplicate style links and elaborate JavaScript hacks to shave off a 100 milliseconds is a good idea. You should care more about the quality and integrity of your HTML pages above all other concerns, including speed or advertising-driven search engine demands!
There could be racing issues! What happens when your HTML downloads before your async "print" sheet resolves itself back to "all"? You may see a flash in some browsers where the HTML downloads first and rendering begins before the async styles are downloaded. Your user then sees your website layouts and fonts move or shift. Nasty!!
Async'ing CSS is kinda pointless compared to these poorly designed Javascript frameworks kids are downloading in 2021 that waste download times anyway. Most style sheets are 50 kilobytes or less in size compared to the MASSIVE 500-1500+ kilobytes most modern Javascript frameworks shove into the browser today (ie. React, Angular, Ember, etc.). These downloads often "embedd" the same CSS over and over into the browser's cache anyway, forcing a reload of the same CSS each site visit unlike CSS linked styles which can be cached for months! So preloading linked CSS makes no sense if its reloaded every visit. So what is the point?
Many browsers may crash and burn with this trick! The preload is not widely adopted anyway, so you run a huge risk in a percentage of your users
seeing an unstyled web site if you use this "hack". Imagine 5%-10% of your users seeing your website displayed in the default 'Times Roman' font and a white block-level, unstyled content page because you wanted to save 500 milliseconds of download time? Sorry, not worth the risk!
Most old browsers had only 2 open connections allowed when downloading files, so they were limited by open connections, not style sheet downloads. Many modern browsers have 6 maximum. So again, connections are the bottleneck here when combined with multiple open JavaScript calls, not style sheet downloads. So little is gained using this trick.
Slow Servers are Often the REAL Bottleneck: Server delays on opening connections on the server can be huge bottlenecks. Even if your host provider or web application like Wordpress is using cached images, pages, and proxies but your waiting hundreds of milliseconds for a connection to open up on the server, all that becomes meaningless. CDN's can also fail, be delayed, blocked, etc., too.
The number one factor delaying downloads, besides slow servers and giant JavaScript API libraries, is more often huge image files. Consider using new HTML5 'picture' elements with multiple image types like "WebP" that are highly compressed. If you page has "on-demand", non-streaming video, that also must be set to preload or download asynchronously. Adding "width" and height" values to force 'alt' attribute placeholders, as images download will create reserved dimensions in your page layouts so they don't shift waiting images to download. You will be amazed at the savings in download times and bottlenecks prevented when you focus on image and media issues, not CSS.
All that makes preloading CSS pretty worthless as far as website improvements. I would go look at the multiple Bootstrap, JavaScript modules, and JQuery file downloads stacked up in your browser grabbing limited, shared browser connections and focus on less scripts. 30 or so kilobytes of CSS will likely not be the issue.
Firefox has supposedly enabled "preload" in version 85, but it doesn't seem to work correctly. What I found that this code below works:
<link rel="preload stylesheet" as="style" href="style.css">
My wordpress website having troble with khmer font showing wrong on ios device.
i'm tried to change font Khmer but it not work. but i use defualt divi theme font i work find.
You need embed Khmer font into your website, you can use Google web font: https://fonts.google.com/?subset=khmer
<link href="https://fonts.googleapis.com/css?family=Battambang&display=swap" rel="stylesheet">
Or include the font and use CSS3 to embed it
I'm a bit late to the party but hope this will help those who finally arrived here.
As #Osify suggested, the best way to have Khmer font displayed correctly on your WordPress website is to use web-fonts, like Google Fonts.
Some Khmer fonts from Google render correctly in the majority of devices and browsers. However, some not.
Some fonts namely, Moul or Nokora will render incorrectly when you browse your WordPress website on Safari of an iPhone 6 or later.
I would recommend you to switch to other fonts like 'Hanuman', 'Battambong', and 'Content' which will fix your problem.
Plus
For speed improvement, I'd suggest hosting those fonts locally as your website asset. A tool like google-webfonts-helper is the best assistant when working with Khmer Fonts.
The tool provides all the needed font files in all formats along with options to choose from and then generates the CSS font-face ready to use.
In CSS why is a backup font recommended if I am uploading a custom font for use with the webpage?
I thought the backup fonts were only needed in case the client doesn't have the 1st/2nd/3rd..etc choice installed.
For example if you have this code:
#font-face {
font-family: MyCustomFont;
src: url('../fonts/MyCustomFont.ttf');
}
Why is this necessary?
body {
font-family: MyCustomFont, Arial, Helvetica, sans-serif;
}
It's not necessary to specify a font stack, but it helps to degrade gracefully in obscure cases when a browser is unable to use the font somehow, e.g. if the HTTP request for the font file times out, the font file itself becomes corrupted or otherwise unusable, the browser doesn't support any of the given font formats, among others.
You should do your best to ensure the custom font gets downloaded and used properly, of course. But things can and do happen that are out of your control sometimes, so it doesn't hurt to still have something nice to fall back to. That's why they're called backup or fallback fonts :)
DaveRandom, these would be the only nested while loops involved in the business of computing.
I figured out a way to integrate Google Fonts without any of the problems usually found when 3rd party fonts are used.
First off, we know our Google Fonts files are in the .woff format and may not work in all browsers.
Second, if a Google Cloud or some other molest prevents the download of the font file from our server due to cache restrictions or other network limits we know this pseudo-state of connectivity will likely support the .woff fonts from Google Fonts.
To the credit of Google we may be able to load our images in some other way so why not try a Google Fonts version of our end product.. so here is why not:
In order to insure the font remains the same when adding Google Fonts I recommend not removing the self-hosted fonts unless a verified plaintiff requests you do so for rights ownership reasons.
Instead of removing self-hosted fonts which are the true key to real cross-browser compatibility, create a same-font entry in CSS that specifies it's font title as 3rd party such as: 'ArialVanityGoogleFonts'.
Use the browser's built-in font fallback .csv and include the fonts as follows: ArialVanity, ArialVanityGoogleFonts, Arial
I have no idea why this is happening. I am following the standard tried and tested method of using google web fonts
<link href='http://fonts.googleapis.com/css?family=Sunshiney' rel='stylesheet' type='text/css'>
<style>
h1{ font-family: 'Sunshiney', cursive; }
</style>
<h1>Hi there</h1>
This works in Safari, Chrome and IE but not FF7.
Has anyone come across this. I've also tried using the JS integration and the #import syntax and it is the same. I'm really stuck.
This is a known issue with Google Web Fonts. An internal configuration change broke serving of one of the headers needed for reliable operation in Firefox and IE9+. The fix is propagating now and it should be working soon.
Thanks for reporting the issue!
(I'm an engineer on the Google Web Fonts team, found this in a twitter search trying to investigate how deep the breakage went)
I think its problem with google
On my browser FF 7.01 is show Comics Sans
http://fonts.googleapis.com/css?family=Sunshiney => redirect to
themes.googleusercontent.com/static/fonts/sunshiney/[...]3HZu7kw.woff
And response with no font data
but when type this adress in url bar i can save this font
so.
Just download this font and simple embennded to webpage
Will be faster
eq
====> 0,20second to download family=Sunshiney
=====> 0,30 to download woff font
There is currently an issue on Google's end with the Webfonts. It's odd because they were working just a few days ago, and I've seen them load up once or twice, but otherwise it's reverting to the fallback font.
Your best option is to download the file and manually embed it into your webpage using #font-face. There's a good article on that at Six Revisions.
I hope Google gets it sorted soon.
Just in case it helps someone, I just had a problem with Google Web Fonts not rendering on a colleague's Mac, but working on other (similarly configured) Macs. It was obviously something client side, and turned out to be the browser.display.use_document_fonts setting (see here).
To stop it happening, it's a case of going to Preferences .. Content .. Fonts & Colors .. Advanced and making sure "Allow pages to chose their own fonts, instead of my selections above" is checked.