Incorrect rendering of fonts from google fonts

Report Bugs
1

Hi,

I saw this problem a long time ago, but now it stings my eyes terribly. :smiley:

The thing is that the wizard incorrectly renders fonts from Google Fonts.

An example is your website - divhunt.com and any other website made in the divhunt creator.

Not every time, but very often. It doesn’t look good when you enter the site.

The point is that when I go to www.divhunt.com the subtitles are in a random font and then they load and the font changes.

Is there a chance to improve this? I had a situation a few times where clients told me that I made a wrong page, and then there was the same story. The wizard just didn’t load fonts from google fonts well.

I will be very grateful for correcting this error. :blush:

2

I wanted to take a screenshot, but the site is running so fast that I can’t make it on time :smiley:

3

Hey,

This is because we load a website without waiting for google fonts to load, so you see that ‘glitch’ for a 50ms, where your browser shows you default font.

We will try to create an option for users to choose if they want to wait for fonts to be loaded before loading a website.

4

Ok,

thanks for reply.

Could the choice you mentioned cause the website to run slower?

5

From user perspective, no. Google fonts load in under 100ms usually. But from perspective of GTMetrix and similar tools, it will slow down initial load by that time.

6

So, this is called FOUT (Flash Of Unstyled Text), and it’s there on almost any website you visit if you refresh enough times :slight_smile: It’s not incorrect, it’s just reflective of how long it takes for even the fastest websites to grab the font file and style it for you.

I can’t guarantee a response from your client, but this nifty hack worked for me thanks to the Custom Code area and actually makes a slick little animation that looks super intentional.

Let me know if it works for you?

In Site Settings > Custom Code > Body Start, drop the following snippet:

<style>
body { 
  opacity: 0;
  transition: all 1000ms 0ms linear;
  background: (match whatever your main site background color is)
}
body:has(.dh-body) {
  opacity: 1;
}
</style>

What this does is hijack the way Divhunt loads sites. They first load a basic wireframe of just:

<!DOCTYPE html>
<html lang="en">
    <head>
        // all of your styles and scripts get loaded here, including your CSS and fonts. However, Divhunt is SO fast that it loads everything simultaneously. So while it's going and getting those fonts, it's still loading in the rest of your content at the same time. Usually the content gets there first (unless the CSS is cached), so that's why you see the unstyled text first.
    </head>
    <body>
        <style>
            // THIS is where that custom code goes, because it loads with the page itself

            body {
                opacity: 0;
                transition: all 1000ms 0ms linear;
                background: rgba(64,77,166,1.00);
            }

            body:has(.dh-body) {
                opacity: 1;
            }
        </style>
        <window id="dh-window"></window>
        <div id="dh-website">
            // your content will be dropped into this element via the script below
        </div>
        <div id="dh-modal"></div>
        <script id="divhunt-load">
            // this is where all your CONTENT is dynamically loaded via script
        </script>
    </body>
</html>

So it gets that opacity on the body itself, as well as the background, so there’s something to look at when it first loads. If you published a blank page, that’s what it would look like, basically.

Then when the script brings in elements, your main content will be nested under .dh-body, so once the CSS clarifies that the body insert exists, it will use that transition property to bring the opacity back to 1!

So you can play around with the values, but I think at 1000ms it looks slick and actually solves the issue nicely and looks intentional.

Maybe I’ll make a plugin for this called “No FOUT Google Fonts fix”?? :smiley:

7

@rneary

Nice fix! :slight_smile:

Would be awesome if you make a plugin for this :slight_smile: I can help you with even cleaner solution to achieve similar results if you want to build a plugin.

Let me know.

1 Like
8

Cool cool!

So yeah, it would have to be something slightly different than this, because apparently Firefox STILL does not support :has!?! :upside_down_face: