Unexpected results for font-display ('Ensure text remains visible during webfont load') audit

[erlapso]

I adjusted all the ‘font-display’ so that is optional or fallback as explained in the documentation, but I still get ‘Ensure text remains visible during webfont load‘ performance warning

[robdodson]

similar to #483, are you able to send us a URL so we can test and verify? thank you!

[erlapso]

Not sure if it's similar as I see that ligthouse is picking up the new CSS rules related to the font. This is the URL: https://botsociety.io

[robdodson]

Cool site :)

I tried changing all of your @font-face styles over to using font-display: swap; using local overrides in DevTools but I'm still seeing this audit fail in LH when I run it in DevTools. I'm going to see if I can transfer this issue to the LH repo in case they know what's up.

[robdodson]

To add more context, I created a Glitch to test:
https://glitch.com/edit/#!/juicy-policeman?path=index.html:17:24

The glitch seems to pass the audits in DevTools

[wardpeet]

@erlapso thanks for reporting! Feel free to correct me if I'm wrong. 👍

There is something weird going on between pagespeedinsights and lighthouse.
pagespeedinsights:

lighthouse latest master seems to pass

lighthouse devtools isn't: (v3.0.3)

Actually devtools v3.0.3 is correct 👀 . The site is using critical-css which is great! 🎉 I see lots of font-face declarations in here without font-display. When the stylesheets kick in the font-faces are loaded again which do have a font-display value. Does this make sense?

[blue2blond]

Any news on this? I am experiencing the same. Tried different font-display options als wel als putting it before or after src-property.

version: Lighthouse 4.0.0-alpha.1
url: blue2blond [dot] nl/sitemap.html

[patrickhulce]

Ah thanks @blue2blond your issue is a little bit different, and I can confirm the problem. I'll file a separate issue for this 👍

[paulirish]

Also reported with bombacarta DOT com

[bhargavpjoshi]

Any further development in this thread??? Facing the same issue after deploying all available suggestions from my many of websites.???

for ref. https://www.truecadd.com/

[TheDutchCoder]

I can confirm this is still an active issue.

An audit in Chrome seems to pass just fine, but an audit through PageSpeed Insights still throws this warning.

Chrome audit results:

PageSpeed results:

[patrickhulce]

Current state of this issue:

• https://botsociety.io - passes locally on master, passes locally on v4.0.0-alpha.0, fails on web.dev
• https://www.truecadd.com/ - passes locally on master, passes locally on v4.0.0-alpha.0, passes on web.dev
• https://bombacarta.com/ - passes locally on master, fails locally on v4.0.0-alpha.0, fails on web.dev
• http://blue2blond.nl/sitemap.html - passes locally on master after core(fonts): resolve URLs relative to stylesheet #6782, just needs a roll to latest

I'm going to reassign this to @exterkamp for now as it's a LR-specific issue (seems like it'd be difficult for ward to figure this one out without LR debug access, but feel free to pass on to the appropriate person @exterkamp 😃).

@TheDutchCoder if you have a URL for us to add to this list while debugging that'd be great!

[awran5]

Same issue here: https://gkstyle.net/

Passes locally, fails on PageSpeed Insights.

[Diklla]

Not sure this is the reason for all the above failures, but I had a similar issue, so I checked and turns out that the code that Lighthouse uses to find a declared font-display property is declaration.match(/font-display:(.*?);/);. Please note the semicolon at the end of the regular expression. This means that if font-display is the last line in the CSS rule and does not end with a semicolon, the diagnostic audit fails. Given that this is a rather common practice, it might explain some of the above fails and should be addressed regardless.

[patrickhulce]

Thanks very much @Diklla! Interested in picking up a PR for that? :)

[lubomirblazekcz]

@Diklla good find, adding semicolon at the end of the line fixed the issue for me.

[awran5]

@Diklla Thank you very much! that fixed it for me too.

[paulirish]

fixed by #7191

[simeranya]

same problem is here: https://hastadoktor.com

can you explain the answer for non-coder ?

[maersu]

Did have the same issue with font-display: auto;

Looking at the lighthouse code shows that only (block|fallback|optional|swap) are valid options.

Any reason why auto is missing? According to the Google docs and Mozilla docs auto is valid option

[patrickhulce]

@maersu the audit is all about picking a behavior other than the default behavior. It's not about setting any valid value.

Ideally use optional or swap but there are certain use cases (font icons for example) where the others make sense.

[maersu]

@patrickhulce thanks for the reply and clarification!

I was not aware, that auto is the default.
IMHO it's a bit confusing since the "Learn more" link in the test does not mention it and auto is the example config there:

@font-face {
  font-family: 'Arvo';
  font-display: auto;
  src: local('Arvo'), url(https://fonts.gstatic.com/s/arvo/v9/rC7kKhY-eUDY-ucISTIf5PesZW2xOQ-xsNqO47m55DA.woff2) format('woff2');
}

[patrickhulce]

Hmm, you're right we never explicitly say what font display to be using 👍

[patrickhulce]

Filed #7342

[sdennett55]

I still get this even when font-display: swap; is the last declaration in an @font-face declaration.

[patrickhulce]

@sdennett55 what is your lighthouse version? This was fixed relatively recently.

[sdennett55]

@patrickhulce I'm on the most recent version of chrome, but to clarify, I don't have the issue here https://web.dev/ but I do in the audit tab of devtools.

Chrome: Version 73.0.3683.103 (Official Build) (64-bit)

[patrickhulce]

@sdennett55 stable Chrome runs very far behind current Lighthouse due to its release cadence. This has been fixed 👍

[chrisSowerby]

So how do you set the font-display if external CSS is bringing in fonts and you can't edit the CSS?

[patrickhulce]

@chrisSowerby you have a couple options as outlined by this article, the ideal solution isn't widely available yet but still ways to get the job done :)

[rafiqullah0909]

Not sure this is the reason for all the above failures, but I had a similar issue, so I checked and turns out that the code that Lighthouse uses to find a declared font-display property is declaration.match(/font-display:(.*?);/);. Please note the semicolon at the end of the regular expression. This means that if font-display is the last line in the CSS rule and does not end with a semicolon, the diagnostic audit fails. Given that this is a rather common practice, it might explain some of the above fails and should be addressed regardless.

Hello @Diklla
Here is my Shopify Code for Font Setting. Could you please tell me. Where should I add "SEMICOLON" for solve the "Ensure text remains visible during Webfont load" Issue.

/* Typography */

{{ settings.heading_font | font_face: font_display: 'fallback' }}
{{ settings.text_font | font_face: font_display: 'fallback' }}

{%- assign text_font_bold = settings.text_font | font_modify: 'weight', 'bolder' -%}
{%- assign text_font_italic = settings.text_font | font_modify: 'style', 'italic' -%}
{%- assign text_font_bold_italic = text_font_bold | font_modify: 'style', 'italic' -%}

{{ text_font_bold | font_face: font_display: 'fallback' }}
{{ text_font_italic | font_face: font_display: 'fallback' }}
{{ text_font_bold_italic | font_face: font_display: 'fallback' }}

$heading-font-family : {{settings.heading_font.family}}, {{ settings.heading_font.fallback_families }};
$heading-font-weight : {{settings.heading_font.weight}};
$heading-font-style : {{settings.heading_font.style}};
$heading-font-size : {{settings.heading_size}};

$text-font-family : {{settings.text_font.family}}, {{ settings.text_font.fallback_families }};
$text-font-weight : {{settings.text_font.weight}};
$text-font-style : {{settings.text_font.style}};

$uppercase-heading: {% if settings.uppercase_heading %}true{% else %}false{% endif %};

$base-text-font-size : {{settings.base_text_font_size}}px;
$default-text-font-size: 14px;

Thanks
Rafiq

[antoinerousseau]

I'm still having this issue in web.dev too:
https://lighthouse-dot-webdotdevsite.appspot.com/lh/html?url=https://lebikini.netlify.com
Even though my font-faces all have font-display:swap; (you can see it directly at the top of the page source)
Any clue?

[patrickhulce]

@antoinerousseau those fonts it is flagging are indeed missing font-display on the network request, and I can't find the source you're referring to that has the font-display properly declared.

[antoinerousseau]

@patrickhulce I published an experiment since then, but you can see here what I was talking about:
https://5cbc80f7b4528a0008a0dbad--lebikini.netlify.com/
Look at the source or at the DevTools, it has font-display:swap; in all font-faces.

[patrickhulce]

Ah thanks for the repro URL @antoinerousseau! There's something very different going wrong there, so I've filed #8493 for it.

[quantizor]

Same deal for https://lighthouse-dot-webdotdevsite.appspot.com/lh/html?url=https://sesamecare.com

If you look at the source for the site the font-display property is definitely set:

@font-face{font-family:'Gilroy';src:url('/assets/fonts/Gilroy-ExtraBold.woff2') format('woff2'),url('/assets/fonts/Gilroy-ExtraBold.woff') format('woff');font-display:fallback;font-weight:800;font-style:normal;} @font-face{font-family:'Gilroy';src:url('/assets/fonts/Gilroy-Bold.woff2') format('woff2'),url('/assets/fonts/Gilroy-Bold.woff') format('woff');font-display:fallback;font-weight:700;font-style:normal;} @font-face{font-family:'Gilroy';src:url('/assets/fonts/Gilroy-SemiBold.woff2') format('woff2'),url('/assets/fonts/Gilroy-SemiBold.woff') format('woff');font-display:fallback;font-weight:600;font-style:normal;} @font-face{font-family:'Gilroy';src:url('/assets/fonts/Gilroy-Medium.woff2') format('woff2'),url('/assets/fonts/Gilroy-Medium.woff') format('woff');font-display:fallback;font-weight:500;font-style:normal;} @font-face{font-family:'Gilroy';src:url('/assets/fonts/Gilroy-MediumItalic.woff2') format('woff2'),url('/assets/fonts/Gilroy-MediumItalic.woff') format('woff');font-display:fallback;font-weight:500;font-style:italic;} @font-face{font-family:'Gilroy';src:url('/assets/fonts/Gilroy-Regular.woff2') format('woff2'),url('/assets/fonts/Gilroy-Regular.woff') format('woff');font-display:fallback;font-weight:400;font-style:normal;}

[c0b41]

@probablyup follow up this issue #8493

[friska-nataniel]

Hi,

I encounter the same issue. Lighthouse audit shows 'Ensure text remains visible during webfont load' diagnostic. Right now, I have font-display: fallback on my code.
Here's the snippet of the CSS file per May 28th, 2020:

@font-face {
    font-display:fallback;font-family: effra;
    src: url(https://www.static-src.com/fonts/1.0.0/effra/effra-regular.woff2) format("woff2"),url(https://www.static-src.com/fonts/1.0.0/effra/effra-regular.ttf) format("truetype")
}

@font-face {
    font-display:fallback;font-family: efframedium;
    src: url(https://www.static-src.com/fonts/1.0.0/effra/effraMedium-regular.woff2) format("woff2"),url(https://www.static-src.com/fonts/1.0.0/effra/efframedium-regular.ttf) format("truetype")
}

Here's a few things that my team has tried:

1. Use local overrides to include font-display: swap; into vendor.css and init.css.
2. Check against regex used by Lighthouse to do this font display audit (refer const `fontDisplayMatch`in the Lighthouse code) and verified that font-display: swap; regardless of placement or whitespace should pass this audit.
3. Tested local overrides on LH versions 5.7.1 (in Chrome Stable) and version 6.0.0 (in Chrome Canary). Both have the same issue.
4. Testing on PageSpeed Insights is not applicable since it tests first view which is a different HTML and does not use custom fonts.

Hereby, I attached the lighthouse audit of https://www.blibli.com. (refer to point number 4 where we can't test with PageSpeed Insights / lighthouse-dot-webdotdevsite)

Your help would be really appreciated. Thank you.
www.blibli.com-lighthouse-audit.zip