Archived topic
Local fonts defaulting to bold or system stack fonts after updating to WP 5.8
11 replies · Started by Dan on July 28, 2021
Hello,
I have Open Sans (for body fonts) and Raleway (for titles/navigation) hosted locally on my website. I recently updated to WordPress 5.8 with GP Premium 2.0.3 and GP 3.0.4 and all fonts now seem to appear as bold when signed in (see screenshot of homepage) or default to system stack fonts and link colors (see screenshot of homepage) when in incognito window. I have not made any changes to the CSS or Customizer settings.
There are also some other odd behaviors like the way the logo loads (big and then to the correct size) and we had to remove the search in the navigation in GP customizer as it was appearing as a bar on the left below the logo instead of the microscope icon on the far right.
Any advice on how to troubleshoot these issues? Not sure if it's connected to the GP Premium and WP updates.
Thanks in advance.
Hi Dan,
I'm not sure I'm seeing the same thing. - https://share.getcloudapp.com/jku421BK - but the site is serving a cached version of the CSS so I can't be sure if I'm just seeing a cached version of your site prior to 5.8 update or if this is the latest iteration.
That said, can you disable caching and let us inspect the page? To be sure it actually goes bold or not on 5.8.
Perhaps you sorted it out? Let us know. :D
Hi Elvin,
I've disabled page caching now so please go ahead and inspect the page. The page no longer defaults to system stack fonts (what you saw in the screenshot with the blue navigation bar items), but the body text (Open Sans 400 Regular) is still defaulted to bold on all pages and posts (an example of a post here).
Once we fix the font issue, we'll try and tackle the navigation bar & search issue in another ticket.
Thank you.
Thanks,
I've checked the home page again and it doesn't seem to be bold, although the color changed as shown here - https://share.getcloudapp.com/z8urDnp2
As for the paragraph font-weight. It indeed does look like its bold but I think that's just the way Open sans 400 looks like.
I've checked here - https://fonts.google.com/specimen/Open+Sans - and looking at 400, you can see that it really does look like it's bold compared to other fonts of the same 400 font-weight.
I've also checked the exact file involved here - https://share.getcloudapp.com/Apu9KONK - and it looks the same bold-like weight.
And it does indicate that it's using 400 - https://share.getcloudapp.com/X6ulqDzx
Not exactly sure what the issue is. Do you have a backup/clone of the site prior to updating to 5.8? For reference? Let us know. :)
Thanks for checking, Elvin. It is not only the Open Sans 400 that appears bold, but also the H2/H3 headers, which are also Raleway. It’s as if all non-italic fonts in the content/body section of pages/posts are now bolded — including text, headers, photo captions, etc. You can see an example post here.
I’ve set up a backup site with a snapshot before updates. You should be able to see the difference there in font appearance. Note that in that site, Open Sans 400 is used, but the site did not have the issue with non-italic text being in bold.
Thank you for your continued help.
Hi there,
very odd - there is no CSS that is changing the font weights and i can see the regular version of Open Sans is being requested.
Shot in the dark, but it looks like the Font may have got messed up.
What happens if you download new copies of the Fonts and replace the existing ones ?
Thanks, David. We are getting there, I think. I uploaded new copies of the fonts, updated the corresponding SimpleCSS -- and the font bolding issue seems to have been resolved.
However, each and every page now does a FOUT/FOIT text flash thing where all the page text is flashed in what looks like a system/base font before displaying the font set in the theme. By the way, I'm on a fairly quick connection and the flash is noticeable, happening on both Chrome and Firefox. Example page here or any you click, I think.
The issue directly related to FOUT is the font-display: swap; property in the @font-face CSS.
Its a weigh up between having the 'Ensure Text is displayed on load' ( No Swap ) in a Google PSI report and there being FOUT.
But the other issue i see regularly is the use of WP Rocket Optimized CSS delivery and Used CSS features. Both of which you have enabled. If you leave WP Rocket to its own devices it commonly generates CLS issues. To get round that takes manual configuration for your specific needs or suffer the Render blocking hits with those options disabled.
Thanks, David. Where are you seeing the font-display: swap;? It's not in our Simple CSS and we don't see it in the viewing source code.
We'll examine the WP Rocket settings separately.
Right click > Inspect. And in the Network tab ( CSS filter on ), selected the used.min.css and searched for swap. Theres a few instances of it.
It may be being injected by WP Rocket as i believe there are some font optimization options in there.
Thanks, David. Think I've found the cause and the font issue is resolved.
There are two remaining issues regarding the header/navigation bar after the WP upgrade and re-enabling search. I've turned off caching again.
1. A search bar + search icon + "X" flashes in the top left and the navigation bar is below before the logo loads and everything falls into place. See an example here or on any page.
2. On mobile, the logo appears very tiny at first (see screenshot) and then becomes big and pixelated after scrolling or engaging the page (see screenshot). Mobile menu is turned on and adjusting the settings in the Customizer don't seem to solve the problem.
Any thoughts on what's happening with the header & navigation?
All those issues look related to the WP Rocket Critical / Used CSS options and how affects the loading order of the CSS.
Not sure if this will help but lets try to move the viewport meta higher up the chain to see if that helps WP Rockets critical CSS to load mobile first.
Add this PHP Snippet to do that:
add_action( 'after_setup_theme', function() {
remove_action( 'wp_head', 'generate_add_viewport' );
add_action( 'wp_head', 'generate_add_viewport', 1 );
} );
Its a shot in the dark....
If the issues still persist you should speak with WP Rocket, they should be able to help exclude the necessary styles from the critical CSS so they get loaded in the correct order.