FF Real Font Family
Sheron Kernan
OpenSUSE is one of best linux versions I ever tried. I love openSUSE because of its stability, sponsor and YaST. The only concern I had with is the font rendering, here what i tried and worked well on my desktop.
Getting fonts right is a real sticking point for new users and likely to tip them from one distro to another, or even get them to return to Windows, which did get font rendering right with their ClearType technology years ago. OpenSUSE is still struggling to keep up, if this thread is anything to go by! Blurry fonts or fonts with colo(u)r fringes are tiring on the eyes!
Yes, that is correct. The Muzlocker repo has not yet been updated for 12.2, at least as of today. However, there is another subpixel font repo that you can implement for OpenSUSE 12.2 based on Infinality here:
I can confirm that this gives superb results on openSUSE 12.2 (with XFCE, in my case, should work with virtually any other desktop as well). The Namtrac repo is the one officially blessed by the Infinality project, which is what REAL font afficionados use.
In the last few weeks, because of a combination of various things at work, and in side-projects, I've been learning a lot about web fonts and also a lot more about Google Fonts specifically. Through that I've come up with a more nuanced answer to the question, that in the past I thought was easy: should you self-host Google Fonts?
Now, to be totally up front, I'll admit that fonts are not my strong point. I'm much more practical than design-y (look at this website for evidence of that!) and have never totally got the need for fonts. Sure they look a bit nicer, and can understand they make a message seem more on-brand, but for the main body of text at least they seem more of a nice to have - I've never read an article more or less (or treated the contents any differently) because it had a pretty font. However, I've also been acutely aware of the performance implications of them so maybe that's clouded my view of them.
Still, many feel differently, and fonts are here, whether I appreciate them or not, and many developers aren't given a choice whether to use them or not. So let's look at what we can do to minimise the performance impact, but also give the designers what they want - win win!
A few years back it was all the rage to use a CDN to serve common assets (e.g. jQuery from - and yes jQuery is still very much a thing!). To be clear when I say CDN here, I mean where you are loading some assets from someone else's domain, rather than a CDN fronting your domain.
The theory behind this was that browsers limited the number of connections to each domain (typically to 6 connections) so using another domain gave you 6 more connections. While that may have been true in the past (particularly when browsers limited it to less than 6 domains) and before HTTPS became the norm, now connections are expensive to create. Additionally HTTP/2 actually benefits from one connection (mostly!) so using other domains is often a performance cost rather than gain.
Another way of doing this was by sharding your domain with one or more assets subdomain (e.g. assets.example.com) so again the fonts are not hosted on your main domain where your web page is loaded from. However, it has the same connection issues so again this is not the performance benefits it may once have had.
The other supposed benefit of using a public CDN, was from leveraging the fact that visitors might already have that version of jQuery loaded in their HTTP cache, but again I'm convinced that's over-egged. There are so many libraries and versions, and browser caches are smaller than you think, so for you to be lucky enough to gain from this seems unlikely. Additionally Safari has a unique HTTP cache per domain visited, for privacy reasons (called a double-keyed cache) and Chrome soon will have too, ending any argument there.
That leads nicely into the privacy implications of using third-party CDNs. You have no idea what sort of tracking they are doing to your users by using them, rather than self-hosting. And recent legislation means a lot of sites have to explicitly list all the cookies used on the site, which gets more complicated when using a third-party.
I've been convinced for a while now that third-party CDNs, or even sharding your own domains, are not the performance boast they are thought to be. All too often you see the main domain serving the index.html, and then that connection not being used for anything else as time is instead wasted setting up new connections.
This is not to mention the security implications of loading assets from another domain. Yes there is SRI but that can cause unexpected issues, and I honestly don't see the point. If it is a static asset (where you can use SRI) then self-host, and if it is not static (because the contents are liable to change) then you can't use SRI.
On a related point, using a third-party, also introduces the risk of them becoming a single point of failure (SPOF) and taking down your website if it goes offline for any reason. This has been recognised for a long time and while it may seem unlikely that Google Fonts will go down, it can be blocked by company proxies or whole countries.
All in all, more and more have been advising to self-host your static assets, ideally on the domain you serve the web pages from. Fonts are static assets, so they should also be self-hosted right? Well it turns out it is not quite as simple as that because fonts have their own peculiarities and performance optimisations that might make self-hosting a little trickier...
Google Fonts is an amazing resource for those of you that are into your fonts. It has 977 open-source fonts for anyone to use completely for free. Commercial fonts are ridiculously expensive for those of you that have ever looked into them and they are also usually licenced rather than bought, and are charged based on expected number of page views - like they will run out through use! To have so many free fonts in one collection and so easy to use is therefore very useful.
Google Fonts, however, takes it one step further. Like many providers of website assets (see jQuery example above), they also provide a CDN and host the fonts for you to use directly from them. This means you can start using fonts just by adding one line of code to your website to pull in the style sheet, like this:
The downside to this is in performance (the upside is also in performance but that side is not as obvious - we'll get to that). The problem is that your website (say www.example.com) loads the stylesheet from fonts.googleapis.com, which returns some CSS made up of font-face declarations. Using the first example above, returns this then I view that URL in Chrome:
However this means you have to connect to fonts.googleapis.com, download the CSS, then connect to fonts.gstatic.com to download the actual fonts (why Google can't host both the CSS and the fonts on the one domain I really don't know!).
Fonts are often discovered late by the browser when loading a page (as you need to download the CSS to see the font references) but Google Fonts are discovered extra late, as you need to download the CSS from another domain, then the fonts from a 3rd domain and, as discussed above, making an HTTPS connection takes time. This can be seen in the following waterfall diagram generated by WebPageTest (note all tests were run with Chrome - 3GSlow):
You can see on line 1 we are downloading the HTML then, once that's downloaded and read at just under 2 seconds, the browsers sees the need for the Google Fonts CSS and downloads it on line 4. This takes a second just to make the connection, and then at 3.5 seconds we download the stylesheet, and we see the actual font we need and download that on line 6 - which takes about another second and a quarter to make the connection to fonts.gstatic.com, before we can actually start downloading the font.
We can mitigate some of this performance hit of downloading the CSS and then the fonts from two different domains. The first domain (for the CSS) should be fairly high up your index.html so hopefully will be seen early enough, but the second domain is not seen until later. However we know what that domain will be (fonts.gstatic.com), so we can use a preconnect resource hint to ask the browser to open the connection in advance to save some of that second connection time later:
Here we can see the connection on line 5 is set up in advance, before we download the CSS. This leads to over a second of improvement (downloading the fonts at 4 seconds, rather 5.25 seconds) as we do not pay that connection set up penalty, but instead can download the fonts as soon as we've read the Google Fonts CSS.
You might think you could take it to the next stage and preload the whole font, rather than settle for just preconnect-ing to the domain, but Google Fonts creates unique hashes for their font names. In above example the font downloaded is S6uyw4BMUTPHjx4wXg.woff2 rather than lato.woff2, so preloading is not possible, unless you want to leave your site open to breakage if they ever change that hash.
Anyway, if you are using Google Fonts and do nothing else after reading this post, at least add that preconnect hint if it's not there already - it's one line of code and should improve the performance of your page.
In a lot of cases, this won't really help as by this point the browser now knows you want to connect to this domain to download the fonts, so you are still better specifying this in your HTML to get the preconnect started earlier (it doesn't matter that it's in both and the second hint will just be ignored). However if your page is still processing by the time this comes in, and the DOM is not ready (a sign of too much JavaScript on you page maybe?), then this can help improve the performance when it finally does figure out which of those fonts it needs.
b37509886e