GoogleChrome / lighthouse

Automated auditing, performance metrics, and best practices for the web.
https://developer.chrome.com/docs/lighthouse/overview/
Apache License 2.0
28.4k stars 9.38k forks source link

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

Closed erlapso closed 5 years ago

erlapso commented 5 years ago

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 commented 5 years ago

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

erlapso commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

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

lighthouse latest master seems to pass image

lighthouse devtools isn't: (v3.0.3) image

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 commented 5 years ago

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 lighthouse-font-display

patrickhulce commented 5 years ago

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 commented 5 years ago

Also reported with bombacarta DOT com

bhargavpjoshi commented 5 years ago

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 commented 5 years ago

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: image

PageSpeed results: image

patrickhulce commented 5 years ago

Current state of this issue:

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 commented 5 years ago

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

Passes locally, fails on PageSpeed Insights.

Diklla commented 5 years ago

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 commented 5 years ago

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

lubomirblazekcz commented 5 years ago

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

awran5 commented 5 years ago

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

paulirish commented 5 years ago

fixed by #7191

simeranya commented 5 years ago

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

can you explain the answer for non-coder ?

maersu commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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

patrickhulce commented 5 years ago

Filed #7342

sdennett55 commented 5 years ago

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

patrickhulce commented 5 years ago

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

sdennett55 commented 5 years ago

@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 commented 5 years ago

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

chrisSowerby commented 5 years ago

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

patrickhulce commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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. image

antoinerousseau commented 5 years ago

@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 commented 5 years ago

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

quantizor commented 5 years ago

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 commented 5 years ago

@probablyup follow up this issue https://github.com/GoogleChrome/lighthouse/issues/8493

friska-nataniel commented 4 years ago

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