Hosting own fonts and speed?

built

built

//
BuSo Pro
Boot Camp
Joined
Jan 23, 2015
Messages
1,677
Likes
1,442
Degree
4
Will it make much of a difference if I host my own fonts (2 files around 50kb) in terms of speed?
 
built said:
Will it make much of a difference if I host my own fonts (2 files around 50kb) in terms of speed?
Click to expand...

Static assets such as CSS, Images, JS files, Icons, and fonts are things people normally use a CDN for, either a 3rd party service or implemented in-house. An example is using Google's CDN to use Google Fonts or Jquery (best practice is to have a local file to fall back on). If you self-host these assets, everything comes from your server. In the case of regular HTTP, a separate connection is opened for every static resource, which means that those 2 files will each need their own connection. If you use a CDN, these assets aren't being pulled from your server and being that CDN servers are (supposed to be) optimized for static asset delivery, you're better off in many instances not self-hosting static assets.

No matter which route you take, you'll want to ensure your server is set up for HTTP2, which uses just 1 single connection per origin to multiplex many HTTP requests, where each resource is turned into a frame and assigned a stream id to keep track of it. By doing this, resources aren't blocking each other as each frame is sent asynchronously. Combine HTTP2 with a CDN and you're a few steps ahead of many sites I see in the wild.
 
TL;DR Version:​
  1. Third Party CDN first
  2. Self-hosted when speed becomes a measurable issue
Click to expand...


@built, what I'd recommend for the average use case, and I think would probably be best is simply use the default third party CDN hosting offered by the resource creator/developer (Bootstrap, FontAwesome, etc.). I'm a speed fiend, so it may seem questionable why I would say that. I say it in the interest of quick implementation and minimal dev time. Yeah, it's not really a big deal to self-host stuff like fonts. That being said, it only takes a second to throw another <link> tag in your code to reference another third party resource, and you're off and running.
​
So I think with the outlook of minimizing dev time to focus on more productive marketing efforts (content creation, ad optimization, testing, etc.), start with third party hosted, and then if you reach a point where speed becomes much more of a concern, then convert to self-hosted in whatever highly-optimized manner you prefer. Speed is relative. Yes, it is a ranking / UX / engagement factor, however the real question is relative to what? If the rest of the competition is all slow, like say 10 second load times, imagine this

⇓​
Let's say the "Pareto" is, a few simple efforts could get you to 5 seconds. Well, that may be "slow" in the grand scheme of things but, you already beat the competition.

If you think about it, all things being equal, if the competition is good quality, then it stands to reason that our G overlords might want to be selective with the degree to which absolute speed advantages are favored, at the niche level, relative to the competition.

In other words, if one competitor had a significant advantage, true, this will probably be valued. However, imagine the detrimental effect on rankings and quality of the SERP if the value "modifier" for speed was extremely high in a niche with high variances in speed. It would be extremely volatile.

What I mean by that is, it stands to reason that this value is variable, based on the competition within the niche, as with any other ranking factors. If this was not the case, then you could simply go find any niche where page speeds are ridiculous, create a static page that's 10x faster, and dominate every niche instantly.

It unfortunately doesn't always work like that. There have been times I've expended significant effort to remove even the last 10ms of unnecessary load time from a page, cutting things down to the bone....only to find out that ultimate speed just wasn't a big deal in a particular keyword niche. In other niches yet, I've seen where 25-50ms is literally make or break for success.

So in many cases, the "Pareto" may be "good enough", and going significantly beyond that, especially if it involves significant time and resources, may not net you the same degree of improvement in ranking potential for a particular niche. With development in general, I think it's important to keep those principles in scope and judged based on the needs for the niche/industry/marketplace.

This makes much more sense when you see the range of speed in some niches, on page 1, and often within the top 5 results.
 
I started messing with this, and then saw the old problem of FOUT happen. The Flash of Unstyled Text is when the fallback system fonts are seen before the intended font is loaded. I actually went back to using a 3rd party font and made it load first without async so that there was no possible way for anything to appear without the font first. It's a dangerous move but I like living on the edge. If that font fails to load, my entire site won't load. I need to change that really though.

I hate the FOUT more than I love speed and hate the risk of the site not loading. There needs to be a decent solution for this at some point.
 
@Samwise89 I have learned to like to FOUT. It lets people know that my site is loading, ugly as it may seem. Add 2017 seems to have a trending love for retrofuturistic aesthetics and design makes it a wee bit more acceptable.
 
You must log in or register to reply here.
Back