• Resolved Thomas Jarvis

    (@thomasjarvisdesign)


    Hi,

    I have been trialing Jetpack Boost to add the one function that is not included within my current optimisation stack – Critical CSS.

    This is the second trial using a simple website based on a premium theme with heavy customisations for performance.

    The Critical CSS generator causes a CLS shift because Jetpack Boosts CSS is inserted BEFORE my Font Preloads.

    I normally add font preloads via wp_head hook in functions.php with a priority 1.

    In order to get them to load first. I had to add them manually to header.php before WP_head.

    I also had to add @fontface critical CSS manually above Jetpack Boost.

    This still is not quick enough to prevent the shift but minimises it.

    Is there a better way to insert code before Jetpack Boost from functions.php instead of using header.php?

    You can see the modified version live on the link attached to this post.

    The page I need help with: [log in to see the link]

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter Thomas Jarvis

    (@thomasjarvisdesign)

    I’ve looked at the waterfalls it appears the font swap is still occuring. Even with fonts stored locally in WOFF2 with preload and @font-face occuring before jetpack critical CSS.

    Any idea what might be causing the layout shift?

    Plugin Contributor Mark (a11n)

    (@thingalon)

    Hi there,

    Thanks for writing in. I’ve taken a look at your site, and hopefully I can help.

    I normally add font preloads via wp_head hook in functions.php with a priority 1.

    Our wp_head hook uses a priority of 0 because we generally want to get in first. Technically WordPress supports negative priorities, so you can use a hook with -1 to force yours to run first.

    I’ve looked at the waterfalls it appears the font swap is still occuring. Even with fonts stored locally in WOFF2 with preload and @font-face occuring before jetpack critical CSS.

    The problem appears to be the “font-display” property in your @font-face blocks. Your font blocks specify “font-display: swap”.

    This tells the browser to display your site using alternate fonts first, then swap with your preferred fonts once they have finished loading. If you switch that to either “fallback” (i.e.: block for up to 100ms then show your fallback fonts), or “block” (i.e.: do not render text until your font has finished loading), it should prevent the flash of incorrect fonts from showing.

    • This reply was modified 3 years, 2 months ago by Mark (a11n).
    Thread Starter Thomas Jarvis

    (@thomasjarvisdesign)

    Hi Thingalon,

    Thanks for the tip about priorities in functions.php. I have reinstated it and set it to -1.

    I’ve found the problem.
    There were a few items shifting on the page. CLS is calculated from the top down. So the text elements identified were not wrong but were also affected by the menu/header shifting.

    Jetpack Boost critical CSS had adjusted the load order of the CSS slightly. This is because I use a page builder like many other users.

    I have added a bit more to my critical CSS:

    Font swap changed to fallback – Made no difference
    Then added body and h1-h6 font sizes to critical css – slight improvement
    Discovered the header bar was shifting – Added min-height:80px to critical css.
    Added min-height to header image to critical css

    The actual cause was the header shifting. But the fonts were also shifting. Both solutions combined have reduced the CLS to around 0.011.

    Given how tight the margins are on page speed insights at the top. getting 100/100 on CLS just helps creep the overall score upwards.

    Plugin Contributor Mark (a11n)

    (@thingalon)

    Hi again,

    I’m glad you found a solution that works for your site. Sometimes the best thing you can do really is to set specific sizes for things in CSS as early as possible.

    I’m marking this as resolved, but please do let us know if you need any more help with Jetpack Boost

    Thread Starter Thomas Jarvis

    (@thomasjarvisdesign)

    Thanks @thingalon for your help.

    The CLS issue is almost gone. I think all that remains is adding line-height and weight to the critical css as this would explain a small jump now font-swap is not occuring.

    I am hoping to roll this out to other sites now I understand the problem.

    I have been working with the theme developer on the LCP issue. It appears that in practice field data shows a clear PASS but under testing the LCP is just over the ‘Green’ theshold in most test runs. It is actually a fundamnetal problem with the way pagebuilder elements are placed on the page. Not too worried about this it does not really affect field data.

    Wp-Rocket has an option that solves the problem – But all it does is NOT load the images on pageload creating a janky unrecorded CLS shift when the user interacts with the page. I’d rather see a >2.5s LCP than a weird re-load on interaction so I am happy with the results.

    The only area I have not implimented is a CDN and this is because most customers operate in one country. Ironically this may help make the LCP more consistent and improve TBT.

    The TBT score which has worsened since I now use EWWW Webp Plugin with JS and <picture> method to serve WebP images. It adds extra script executions. But the overall score improves with this turned on due to file size reductions and improved lazy load implimentation.

    • This reply was modified 3 years, 2 months ago by Thomas Jarvis.
Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Bug Font Swap issues’ is closed to new replies.