Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lighthouse Issue with Font Performance for font-display #14387

Closed
gyto opened this issue Dec 11, 2018 · 40 comments
Closed

Lighthouse Issue with Font Performance for font-display #14387

gyto opened this issue Dec 11, 2018 · 40 comments
Assignees
Milestone

Comments

@gyto
Copy link

gyto commented Dec 11, 2018

Currently, if you try to use a Lighthouse tool in the Chrome you would find that "Text is invisible while web fonts are loading" in which we need to "Leverage the font-display CSS feature to ensure text is user-visible"

In this case, it means that @font-face should load with font-display property. In case of the icons, it should be load in font-display: block which helps the font face a short block period.

In the main time, I am using font awesome as a package which I am importing it to the project via SCSS.

Is this something that can be added to the @font-face?

Reference:

@tagliala
Copy link
Member

Hi!

Thanks for being part of the Font Awesome Community.

Interesting!

Have you an 1-vs-1 comparison? Do you know if there are any breaking changes in including this property on the supported browsers?

@kiler129
Copy link

@tagliala There's no side effects for supported browsers - the declaration is ignored and FA behaves like it wasn't ever set. font-display is really just a hint for rendering engine which may be even ignored by browsers depending on e.g. power saving settings.

@yolofy
Copy link

yolofy commented Dec 18, 2018

+1

@gyto
Copy link
Author

gyto commented Jan 10, 2019

@tagliala per @kiler129 it is not about support browsers, this is Lighthouse report that I getting recently and fonts are really something that I would like to fix on my project with font-display: auto;

@tagliala
Copy link
Member

Thanks for the heads-up

@robmadole could you please take a look?

@jorgehjr84
Copy link

jorgehjr84 commented Jan 10, 2019

This is also something I would be interested in as well. It should be a simple fix in the _path.scss file(in version 4.7. Not sure about the current version)

@font-face {
  font-family: 'FontAwesome';
  font-display: swap;
  src: url('#{$fa-font-path}/fontawesome-webfont.eot?v=#{$fa-version}');
  src: url('#{$fa-font-path}/fontawesome-webfont.eot?#iefix&v=#{$fa-version}') format('embedded-opentype'),
    url('#{$fa-font-path}/fontawesome-webfont.woff2?v=#{$fa-version}') format('woff2'),
    url('#{$fa-font-path}/fontawesome-webfont.woff?v=#{$fa-version}') format('woff'),
    url('#{$fa-font-path}/fontawesome-webfont.ttf?v=#{$fa-version}') format('truetype'),
    url('#{$fa-font-path}/fontawesome-webfont.svg?v=#{$fa-version}#fontawesomeregular') format('svg');
//  src: url('#{$fa-font-path}/FontAwesome.otf') format('opentype'); // used when developing fonts
  font-weight: normal;
  font-style: normal;
}

You would just add font-display below the font family line

@tagliala
Copy link
Member

Isn't font-display supposed to be block?

Also, just because it is one css it doesn't mean that it is a simple fix 😅

It should always be tested against all browsers supported by Font Awesome and prepare for something we didn't think about

@yolofy
Copy link

yolofy commented Jan 11, 2019

Definitely not block, swap is recommended as the best performing option.

Check out this guides:
https://css-tricks.com/font-display-masses/
https://css-tricks.com/almanac/properties/f/font-display/

@yolofy
Copy link

yolofy commented Jan 11, 2019

Here is a cool demo of the differences between the various options:
https://font-display.glitch.me/#demo

@tagliala
Copy link
Member

swap: Fallback text is immediately rendered in the next available system typeface in the font stack until the custom font loads, in which case the new typeface will be swapped in. This is what we want for stuff like body copy, where we want users to be able to read content immediately.

what would be a system replacement for Font Awesome? Any local installed version? 🤔

@yolofy
Copy link

yolofy commented Jan 11, 2019

https://css-tricks.com/snippets/css/using-font-face/#article-header-id-17
What About Icon Fonts?
It's true, @font-face can load a font file full of icons that can be used for an icon system. However, I think you're far better off using SVG as an icon system. Here's a comparison of the two methods.

https://css-tricks.com/icon-fonts-vs-svg/

@jorgehjr84
Copy link

@tagliala I'm aware of development processes and was not suggesting that you should deploy a 1 line CSS fix without doing your due diligence of testing across all browsers, etc. Hence why I said It should be a simple fix. Thanks for looking into it

@gyto
Copy link
Author

gyto commented Jan 11, 2019

swap: Fallback text is immediately rendered in the next available system typeface in the font stack until the custom font loads, in which case the new typeface will be swapped in. This is what we want for stuff like body copy, where we want users to be able to read content immediately.

what would be a system replacement for Font Awesome? Any local installed version? 🤔

I agree with @tagliala. At this point, it should be font-display: auto or font-display: block

@yolofy
Copy link

yolofy commented Jan 12, 2019

Would it be possible to make this a setting in _variables.scss?

@robmadole
Copy link
Member

I'm going to add it to _variables with a value of auto so it can be overridden. I would like to be very cautious about changing this in a major version (it's something that we might consider in version 6 but would not change drastically in 5). Also I'm not convinced that font-display: block; is a good idea for FA 😉.

@gyto
Copy link
Author

gyto commented Jan 16, 2019

@robmadole so does it mean that you will implement variable in the nearest release version?

@tagliala tagliala added this to the 5.7.0 milestone Jan 17, 2019
@tagliala
Copy link
Member

https://github.com/FortAwesome/Font-Awesome/blob/master/scss/_variables.scss#L6
https://github.com/FortAwesome/Font-Awesome/blob/master/scss/solid.scss#L11

Feel free to set the variable as you wish

@kiler129
Copy link

Thank you all!

@gyto
Copy link
Author

gyto commented Jan 29, 2019

Thank you, @robmadole and @tagliala

@rilwis
Copy link

rilwis commented Mar 21, 2019

@tagliala Can it be swap by default? We use FontAwesome CDN and can't change it.

@stave15
Copy link

stave15 commented Mar 21, 2019

This is my site https://www.fileour.com/ I will try to fix the font problem. But it not works fine. I am very sad.

@kiler129
Copy link

kiler129 commented Mar 21, 2019 via email

@stave15
Copy link

stave15 commented Mar 21, 2019

Thank you. I will try this.

@rilwis
Copy link

rilwis commented Mar 21, 2019

@kiler129 Thanks! That's very helpful.

@MastaBaba
Copy link

How to make this work when using either the free font awesome kit, or the FontAwesome Wordpress plugin?
Using the Wordpress plugin, PageSpeed tells me "Ensure text remains visible during webfont load", referencing three FontAwesome files.

@MastaBaba
Copy link

@garygreen: That's neat. But, for me, using this approach does load the file, but the font is not displayed.

@rosemusic
Copy link

i have same issue in my site https://www.rosemusics.com

@tagliala
Copy link
Member

Hi @rosemusic,

the best option for icon fonts is the block display, otherwise you will see squares while loading. Ref: #14387 (comment) and we don't want that

If you are interested in improving your website's performance, my advise is to use svg files directly or to use a custom version of the SVG framework (webpack/rollup with tree shaking) with async loading of the javascript asset

Ref:

@rosemusic
Copy link

Hi @rosemusic,

the best option for icon fonts is the block display, otherwise you will see squares while loading. Ref: #14387 (comment) and we don't want that

If you are interested in improving your website's performance, my advise is to use svg files directly or to use a custom version of the SVG framework (webpack/rollup with tree shaking) with async loading of the javascript asset

Ref:

* https://fontawesome.com/how-to-use/on-the-web/setup/using-package-managers

* https://fontawesome.com/how-to-use/with-the-api/other/tree-shaking

thanks so much.

@gacallea
Copy link

hi,

I'm having the same OP issue with lighthouse and I don't know how to solve it.

I don't host fonts nor scripts locally anymore because it's a small static site hosted on gitlab pages and it had massive performance issues when I did. hence my switch to cdn for FA (cdnjs), gfonts, jquery and leaflet maps.

I see that this issue has been resolved and closed but I cannot find a way to use &display=swap in the cdn url as google fonts offer. is that possible with FA/cdnjs? how? any advice would be highly appreciated.

thanks

@robmadole
Copy link
Member

@gacallea you don't want to use swap. block is the appropriate setting for an icon font.

@gacallea
Copy link

@robmadole thanks for your quick reply. how do I do that? is it the default?

@robmadole
Copy link
Member

It's the default. But Lighthouse is going to ding you for it. I don't think there is anything that can be done about that.

@Stanzilla
Copy link

I filed GoogleChrome/lighthouse#10127 for that.

@patrickhulce
Copy link

👋 Lighthouse maintainer here, Lighthouse will not ding you for using block. If the Font Awesome CDN were to explicitly declare the font-display as block by default that seems like a win-win for everyone involved.

The intention of that audit is to explicitly opt-in or opt-out of font blocking, not to force icon fonts to render gibberish characters; no one wants that :)

@Stanzilla
Copy link

@tagliala Please re-open :)

@tagliala
Copy link
Member

@Stanzilla thanks for the heads-up, I've missed @patrickhlauke 's comment (sorry!)

Perfect, we can set block as a default value one more time (we switched from block to auto)

About FA 4's CDN link, it is in EOL, and it is not hosted by us

/cc @robmadole

@tagliala
Copy link
Member

Sorry, I'm going to close this in favour of #16077

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests