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

Preload key requests #5471

Closed
wildpow opened this issue Jun 11, 2018 · 6 comments
Closed

Preload key requests #5471

wildpow opened this issue Jun 11, 2018 · 6 comments

Comments

@wildpow
Copy link

wildpow commented Jun 11, 2018

Light House is suggesting that I preload key requests, specifically the two google fonts that I'm using in my React app. Currently I'm just importing them like this:
@import url('https://fonts.googleapis.com/css?family=Open+Sans|Roboto:700')
I've been looking for an example of how to do this but, everything I've tried doesn't seem to work. Any suggestions would be much appreciated.

@patrickhulce
Copy link
Collaborator

This audit will actually change a bit for 3rd party requests in future version of LH, but basically you want

<link rel="preload" as="style" href="https://fonts.googleapis.com/css?family=Open+Sans|Roboto:700" crossorigin>

for extra good bonus points you can also preconnect to the origin it's going to connect to :)

<link rel="preconnect" href="https://fonts.gstatic.com/" crossorigin>

@wildpow
Copy link
Author

wildpow commented Jun 11, 2018

Thank you for such a quick response! Unfortunately I've tried this but, I figured I was doing something wrong because the fonts now don't display. I know it's making the request because I see it in the waterfall and I get this console warning:

"The resource https://fonts.googleapis.com/css?family=Open+Sans|Roboto:700 was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate as value and it is preloaded intentionally."

I apologize for getting a little off topic but, do I need to define these font-families in my CSS with @font-face or something before use? Also, thank you again

@wildpow
Copy link
Author

wildpow commented Jun 12, 2018

Well I got it to work with this bit of code:

<link rel="preconnect" href="https://fonts.gstatic.com/" crossorigin>
<link rel="preload" as="style" href="https://fonts.googleapis.com/css?family=Open+Sans|Roboto:700" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Open+Sans|Roboto:700" rel="stylesheet" crossorigin>

Without adding the crossorgin property to the second link tag I get a render blocking stylesheet warning from LightHouse but, this whole endeavor to preload font fonts per Light House's suggestion as upped my first meaningful paint to 3620ms from 2650ms and lower my lighthouse score from 88 to 79. Not sure if the preload suggestion is general and doesn't work with the way Google serves their fonts or if I'm still doing something wrong. Just frustrating to follow these optimization guide-lines and end up with a slower product.

@patrickhulce
Copy link
Collaborator

This should definitely not make your page slower if it's being done correctly. From your steps it sounds like there's some confusion about how preload works. You might find this article on preload helpful.

@wildpow
Copy link
Author

wildpow commented Jun 12, 2018

That's true I may not fully understand preload and thank you for the link. Here are two screenshots of the lighthouse audits and the zip contains both reports. The only changes to my code was adding those 3 link tags and removed the font @import in my CSS.
screen shot 2018-06-12 at 3 36 44 pm
VS
screen shot 2018-06-12 at 3 35 34 pm
Here is the two reports

Archive.zip

@patrickhulce
Copy link
Collaborator

Sorry I missed this reply @wildpow thanks for sending over the reports!

This is a very interesting case, the successful preloading improves First Contentful Paint as expected, but First Meaningful Paint gets worse because of a quirk in its implementation (the same quirks that were the rationale for decreasing its priority/weight in v3 and promotion of FCP in its place). The regression in the other metrics seems to be unrelated to the preload change and looks like natural variance. If we had been tracking FCP in v2, the incremental improvement from preloading would have been reflected there.

Thanks for bringing this up and sorry for the confusion! Hopefully these cases are addressed in v3 with the new prioritization/metrics :)

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

3 participants