Hacker News Reader

Comment by scrollaway | Hacker News Reader

Web fonts are a big one in terms of making various websites feel fast because, when implemented incorrectly, they massively slow down initial text paint.

With that said, they're a fantastic feature but are also way overused. You don't need web fonts unless your website is either heavily type-centric, or has font-related dependencies (such as embedded content of some kind). Icon fonts are also a neat use of web fonts, but they don't make the page "feel slow" when their rendering is slow, because icons loading slower affects our perception of a page's loading time less than its text.

View on HN

On multiple projects I've used a tool [1] to closely match a built-in font to a web font in order to present content faster and avoid avoid FOUC (Flash of Unstyled Content/Text). In one case, I replaced webfonts entirely with native platform fonts, purely for speed.

With this approach you can be more practical with your goals. If the design cannot be compromised, you can still get to initial paint quickly and let the WOFF files load in as needed.

Edit: If anyone is looking for more information about this, the post [2] from this tool's author from 2016 does a good job of discussing the tradeoffs.

[1] https://github.com/notwaldorf/font-style-matcher

[2] https://meowni.ca/posts/web-fonts/

In addition, not all users are going to want to use whatever font you (the web designer) decided on. I have my preferred fonts on my system, and I expect my browser to use them. How arrogant of the web developer to override the user's preference!

I remember when the browsers even allowed the user to configure a background image for content. You could have all your web sites render over a tiled picture of a brick wall if you wanted. Year after year, we give up end-user configurability and simply hand it over to nameless web designers who decide what is good for us.

> How arrogant of the web developer to override the user's preference!

I imagine this is partly tongue-in-cheek, but I think the real difficulty here is that CSS doesn't differentiate between "user-configured sans-serif font" and "the system fallback sans-serif font". As a result, you can't allow users to override your font choices without disregarding custom fonts entirely.

Use Stylus, for example I do not like StackOverflow left menu and sticky menu:

    .left-sidebar { display: none }
    #content { width: 100% /* calc(100% - 164px) */ }
 
    .top-bar { display: none }
    body { padding-top: inherit /* 50px */ }

its no script experience cluttered by warning and GDPR consent:

    #noscript-warning { display: none }
    body { margin-top: inherit /* 1.9em */ }

    #js-gdpr-consent-banner { display: none }

Users can extend, overwrite and even discard authors styles, but they have to either understand web layout or use userstyles.org.

I've sped up sites before by using inline svg rather than icon fonts - downloading an entire icon font for a few icons is inefficient when the actual SVG needed for those icons is < 1Kb and is waaay faster as inline SVG.

Remarkbox does this with the default profile avatar, just-in-time dynamically rendered and inlined SVGs.

I've considered storing each default SVG into the user table and then inlining in the HTML but decided to wait on that optimization since inlining dynamic SVGs itself was such a significant speed boost, especially on threads with hundreds of comments.

Without inlining, each profile image or SVG would be a separate request parallel HTTP request and often at least a couple requests would be slow.

https://www.remarkbox.com

It's only faster on the first load. On all subsequent loads its slower and consumes more bandwidth. I find this irresponsible.

That surely depends on context; for a lot of pages I'll never make a second load at all.

Only if your html is dynamic and can't be cached. I find this irresponsible.

1. If you use, say, 5 icons and there are, say, 250 icons in the full font, then you would need to download the page 50 times to just equal the bandwidth. That's assuming the cache doesn't expire, or it's not an incognito session, or you're not loading it from a CDN where it won't get cached anyway.

2. If you do find this irresponsible, then by all means create a small SVG file with the 5 icons in it and allow that to be cached, or even 5 small individual SVG files if it comes to that.

In my experience it's not about a website being "heavily web-centric" (which I'm not sure I understand to be honest - surely websites are by definition "web-centric"?) it's more about being able to match brand fonts. If sites didn't do that they'd end up feeling pretty weird because the crossover of installed desktop fonts is pretty low: http://www.ampsoft.net/webdesign-l/WindowsMacFonts.html (There used to be a better site with fonts listed by what percentage of Windows and MacOS systems had them installed, but the last time I saw it was a while ago and I can't seem to find it again.)

> which I'm not sure I understand to be honest

Uh yeah, I lack sleep. I meant type-centric (such as a newspaper).

Unless your font shares (exactly) metrics with the ones the user has installed there's no way to implement this correctly. This is something you can't know so there's no way to implement this correctly.

> when implemented incorrectly, they massively slow down initial text paint

What are you thinking of in terms of "implemented incorrectly", do you happen to have an example?

I can't recall without looking into it, but there's a lot of gotchas when implementing web fonts. You have to ensure it's using fallbacks, that it can use them before the target fonts have loaded, that the fallbacks are close to the web font in style, and there's a bunch of CSS tricks you can use so that a repaint doesn't end up reflowing everything.

Reply on news.ycombinator.com