0

I followed suggestions in a post regarding eliminating render blocking on Google fonts and this is the result from https://pagespeed.web.dev/ and its buddy Lighthouse.

I added the following to the fonts:

<link
    rel="stylesheet"
    href="https://fonts.googleapis.com/css?family=Open+Sans:300&display=swap"
    media="print"
    onload="this.media='all'"
/>
<noscript>
    <link
        href="https://fonts.googleapis.com/css?family=Open+Sans:300&display=swap"
        rel="stylesheet"
        type="text/css"
    />
</noscript>

  1. The "First Contentful Paint" improved from 3.1 sec to .9 sec

  2. The "Cumulative Layout Shift" shat the biscuit moving from 0.006 sec to 0.933 sec

  3. The "Largest Contentful Paint" did not change much from 3.3 sec to 3.4 sec.

BUT the Total Lighthouse (for Mobile) score dived from 86 to 68.

Any ideas about restoring the "Cumulative Layout Shift"?

Note the display=swap was there for the first test.

UPDATE

On further testing it turns out its loading materialize.css that was damaging the cumulative layout shift that used a similar scheme coming from filament group

<link
  href="https://mysite/materialize.css"
  type="text/css"
  rel="stylesheet"
  media="screen,projection"
  charset="utf-8"       
  onload="this.media='screen,projection'"/>

In a broader way how to improve the FCP and maintain a decent CLS. I suppose break materialize.css into lil bits.!

A Boston
  • 151
  • 1
  • 8
  • BTW, strictly speaking [the ampersands](https://stackoverflow.com/q/2366260/159145) in your `href=""` attributes should be encoded as `&` (and methinks it's a good idea to URL-encode the colons too), so so both URIs should look like this in the raw HTML: `https://fonts.googleapis.com/css?family=Open+Sans%3A300&display=swap` – Dai Apr 23 '23 at 04:38
  • Not a fix but note that the [](https://html.spec.whatwg.org/dev/embedded-content.html#the-link-element) tag does not use and does not need a closing slash and never has in any HTML specification. – Rob Apr 25 '23 at 07:42

0 Answers0