[system2]

Loading a font can cause multiple things including load time delay. For example, connecting to Google and downloading a Lato font is around 4-5 requests + js + CSS files + 500kb added download.

Processing the font itself also is at least 500ms to a second depending on the device type.

We keep the total requests under 25, which cannot be done after multiple 3rd party fonts are added.

Additionally, some fonts can introduce CLS (content layout shift) after the font is loaded. Especially H tags because they shift a lot. CLS = your SEO is dead.

For speed purposes, especially mobile, using a 3rd party font is SEO suicide.

The sites we build for our clients are below 1.2 second mobile and 0.2 second desktop load time which gives these sites an enormous SEO advantage. These load times are complete loads, not initial draws or TTFBs. (results are provided by Google page speed insights - https://pagespeed.web.dev/) These load times change when we use the client's own fonts or the ones they pick from Google fonts. We have this discussion almost every time we onboard a new client.

[inferiorhuman]

  Processing the font itself also is at least 500ms to a second
  depending on the device type.

I think that's off by quite a lot.

On my MacBook Pro I can dump one of the Helvetica Neue faces in one second with ttx (fonttools). If a python script can parse a font, create an XML representation, and write a pretty printed version of that to disk in a second then yea 500 ms seems really slow.

Hell, typst (rust) can render a PDF with two subsetted fonts (Apple Color Emoji + Cambria Math) in about 750 ms. I certainly hope Harfbuzz is at least that fast.

[system2]

Google's crawl emulation is based on this:

Emulated Moto G Power with Lighthouse 12.2.0 - Slow 4G throttling.

With slow download and rendering it is probably more than 500ms in my opinion. Either way, I won't leave money on the table and sacrifice 1% better-looking fonts, even if it is for 10ms. Mobile load time is the #1 SEO signal these days and will stay #1 for a long time.

[inferiorhuman]

Right, but your claim was that just processing the font would take 500 ms. No idea what a Moto G Power is or how fast it is, but 500 ms for processing still seems like a pessimistic estimate.

I've no idea what sort of overhead Google adds to font downloads either, but assuming WOFF2 format the font itself should be well under 100k. Granted WOFF2 is fairly new (2018), but it's fairly well supported these days. I'd expect Google Fonts to support it as WOFF2 was Google's attempt at wringing out a bit more optimization out SFNT fonts.

[system2]

Alright, sorry to make it sound like that. Either way, it adds overhead (local or Google) but CDN-loaded ones cause more issues. Google Fonts is the web's standard for non-system fonts and indeed it adds CSS, JS, additional requests, and the font itself, including wait times due to download and load. SEO is a competitive environment, even a single request, and ms counts. Small blogs might not care but if your website gets traffic, those little millisecond differences rank your posts differently.

Our pages are around 80kb in total (yes you are reading correctly, not 800kb but 80kb including images of the blog posts, including the WebP images, javascript, CSS, and the HTML file itself. Imagine doubling or quadrupling it just for a font. That would be insanity. 100kb font size is absurd if you want your mobile speed (#1 SEO factor today) to be better.

Core Web Vitals scores us 100% for everything. This drops to 80%~ when we use external fonts. We tried 100s of different metrics. The font is a major factor (again, doesn't matter local or Google). Added overhead is going to sink your ranks like a rock.

For anyone reading this, do not use Google fonts if you want your SEO to be better.

[lofaszvanitt]

Well, subset the fonts, remove unnecessary flavors, move the font to your own cdn. Problem solved. If this affects SEO... oh dear god, the internet became a sh*thole.