Check out a free preview of the full Responsive Web Typography v2 course

The "Loading Web Fonts" Lesson is part of the full, Responsive Web Typography v2 course featured in this preview video. Here's what you'd learn in this lesson:

Jason talks about the first rule of web design and methods to achieve the desired aesthetic without blocking page rendering. Jason introduces code that implements these concepts, and also instructs on how to approach @font-face support versus JavaScript support by tuning for the loading process rather than assuming either is present.


Transcript from the "Loading Web Fonts" Lesson

>> Jason Pamental: We're gonna review a couple of quick points, and then, we'll actually go about copying one of the sample pages, and adding in everything that we need to load web fonts, and walk through all of the code that's in place there. So in implementing web fonts, don't block page render.

That is the most important thing, because you have to deal with that. 53% of users on mobile or desktop, are gonna bail out on a site, if it takes more than three seconds to see content on the screen. Now, that happens to coincide with every single browser, now, standardizing on waiting for three seconds to see if those web fonts load.

And after 2.9 seconds, do you wanna gamble? So that's where using things like these font loading techniques, and font display swap where it's supported, I know that was a comment in the chat room. They're all layers to this, ways to get content on the screen quickly, and then, make sure that things come in behind it, and then, complete the experience.

So in making these kinds of choices, we don't wanna just check all the boxes. Likewise, we don't wanna do the same thing on Google fonts. Of course, this is now willfully out of date screenshot of the Google fonts interface, but you get the idea. If you start to customize it, it's gonna give you a little indicator that tells you how terrible a person you're being by loading too many font files.

There are a little aggressive. If you select more than two, it's gonna start to tell you that you're doing bad things, but you really need to be mindful of what is a reasonable payload, in order to get a good experience. So if you remember that little bit, we've seen a couple of times now, wanting to make sure that that's the kind of experience that people have.

We use something like this. So this is more complete view of calling font face observer, and then, creating the initial construction of how we're handling the class switching, looking for a session storage variable. In this case, we're only loading in one web font, so that's defined as font A.

And there's a promise that's constructed when it links together all of those different assets, and once they are all true, then it will switch those classes around, and reset the session storage variable. And the important thing being here that, well there's two things, one, is it's getting the class switching done for you, and this script should be in line in the head section of the page.

As soon as you call your CSS, then have this JavaScript in. That's going to give you the fastest performance in having this stuff just work quickly. And that session storage variable is faster to access than checking the browser cache itself, so that's gonna tell the browser, just go get it, I know it's there already.

So that avoids some of the repaint issues that you see in Chrome. Then, going in and setting our h1, and balancing that out with, when the .wf-inactive class is present, don't call the web font, you get the stuff on screen right away. That can make a several second difference.

So it's between no content, and all the content, and you can just make that problem go away. It's tremendously powerful. And the reasons why we want to keep all these things in mind, is there's a gap in support for @font-face and JavaScript. Now, it's not that browsers can't, so Opera Mini, which is in place on about 400 million handsets.

Maybe more now around the world. It supports JavaScript, but doesn't support @font-face. More browsers going back further into the depths of time support @font-face, than support all the JavaScript. They're not the same thing, so you can't conflate them, you really shouldn't conflate them. You wanna make sure that you lean towards, I'm going to say JavaScript has to work in order to give the web fonts, or I know you're gonna get the web fonts, I'm going to use JavaScript to make that experience better.

One way or the other depending on your own users, you wanna lean into that, and optimize for that use case. So in some parts of the world, you might wanna optimize for web fonts simply not being there. But use JavaScript to make sure that you can provide that fall back.

You can also tie things into bandwidth detection. It might be a little extreme for web fonts, but I've done that with the decision to put a photo or a video on a home page, and that can be really effective, too.
>> Student: So do you know if your users have the JavaScript by the developer tools?

So how you would go about knowing if, for example, in the UK how [INAUDIBLE].
>> Jason Pamental: Well that's the trouble, is that you can't really know objectively. You have to structure you code to work, you just kinda have to make inferences. So that's why one of the things that a lot of frameworks will do, is you write your HTML with a node JS class in the HTML element.

And then, use JavaScript to replace it with the JS class. So if no JavaScript ever fires, then you have a no JS class present, and you can use that to scope CSS. And you could then do things like make decisions about wrapping the @font-face declaration, and scope it with the absence or presence of that class.

So something like that, you could then decide if you wanted to lean into, okay, if there's no JavaScript, no web fonts. So you could then just write your CSS, wrap the @font-face declaration in a JS class, so that way, it would only load the web fonts if JavaScript has already processed that one thing.

So It's not that you can be absolute, but we can layer a few checks in place to see, is it a reasonably performant browser? Are these things behaving as we might expect? If they are, then, yes, I want to build up this experience. The truth is, though, JavaScript may never fire, you can still give somebody a good experience with the web fonts.

It might take a couple seconds longer for stuff to load, and show up onscreen. That's where you have to weigh what's most important, ultimate performance, or experience. So you have to make a little trade off there, because we can't know. It's not possible given the nature of the web right now.

So like I said, you want to choose what's right for your user base, your project, your purpose with whatever it is that you're working on to decide which way you want to lean in structuring your CSS, and JavaScript loading.
>> Jason Pamental: But by and large, I think making sure that you have the fallback stuff, and trying to lean into using the JavaScript for the class switching, will make sure that for all those devices that aren't going to get the web fonts, they'll still get a good experience.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now