7 ms·

I could add another point: A software should be self-sufficient (at least to a degree). When user opens the page, the page should not require an external servic

by nirui 7y ago

I could add another point: A software should be self-sufficient (at least to a degree). When user opens the page, the page should not require an external service to function. Imagine a user who can access your page but cannot access Google, the user then has to wait a long time looking at a blank page before the web browser stopped trying, that is some really really bad experience. And your users won't blame Google for been too slow, they will just simply close your page, and try another search result instead.

yathern 7y ago
> Imagine a user who can access your page but cannot access Google, the user then has to wait a long time looking at a blank page before the web browser stopped trying, that is some really really bad experience. Not quite how web fonts work, usually they just swap in for the system fonts once loaded.
- nirui 7y ago
  Yes, a well-designed system can minimize the impact by for example lazy-load the font file or even `Font Face Observer`[0] them for manual hot swap. But that is not the main point. The main point is: You are the one who's in charge of the user experience, not Google. Don't shift the responsibility to somebody (external service) you don't have control of. The software works the best when all it's parts are predicable, and make it more self-sufficient can help. [0] https://fontfaceobserver.com/ https://fontfaceobserver.com/
- swiley 7y ago
  Google’s own pages don’t do that, they intentionally hide the text until the font loads to prevent a “flash of unstylised content.” (It’s quite a bit longer than a flash on many connections, plenty long enough to start reading.)
spookthesunset 7y ago
The odds of google being down / slow instead of your site are pretty bad. Unless you build your own data center, pull in all the fiber yourself, make the network switches yourself, build the servers yourself, etc... you are always going to be dependent on a third party or external service.
- polyphonicist 7y ago
  Google has a reputation of shutting their services down. What if they shut their fonts CDN down or change their URLs without redirects?
  - spookthesunset 7y ago
    Than a hell of a lot of sites lose their fonts until they update.
    - onion2k 7y ago
      To be fair, lots of people being affected hasn't stopped Google in the past. In the case of Fonts though, it's a good source of user and browser data, so it's not likely to be shut down any time soon.
  - mewpmewp2 7y ago
    This might not be end of the world. In a lot of cases convenience is worth the risks. There is no golden rule that one should never depend on third parties. It is always balancing pros vs cons. Self hosting introduces extra code, resources and assets that you as a developer must introduce and maintain. This is not free. Especially if worst thing that happens is a wrong font loaded.
- adrianN 7y ago
  It's not instead of, it's an additional failure mode.
- pmlnr 7y ago
  Google is blocked in some parts of the world, so chance of "being down" is actually non zero if you think of the whole world.
  - kube-system 7y ago
    Also, some webpages don’t even run on the internet.
allenskd 7y ago
I usually just download and self-host for this reason. A software should never rely or be dependent to content delivery networks/repositories like Google Fonts. There's nothing wrong with Google Fonts as a service and repository (tracking stuff aside), but I've never felt comfortable at the idea that we just link, lets say, jQuery or Angular through CDN and call it a day. I should add that most of my work is through intranet applications with servers only accessed through VPN and I've seen the firewall disrupt Microsoft services one too many times so... it's more of a "yea, it's just a save-as or copy file to my app assets folder" versus users sending me emails that the pages stopped working.
- Havoc 7y ago
  > A software should never rely or be dependent to content delivery networks/repositories Not sure that's viable in today's cloud-y world
  - pmoleri 7y ago
    Isn't that like not trusting AWS and have your own reliable data center for website hosting? Edit: Removed cache statement.
    - Havoc 7y ago
      Pretty much. I'm really starting to doubt whether it's competitive to do your own thing anymore. And this seems to be getting worse. Hard to compete with the combo of features & scaling that cloud provides. Attempting it pretty much guarantees you a gnarly trade-off somewhere (reliability, complexity etc).
    - sideshowb 7y ago
      You have to accept that a server may fail to be accessible, whether it's yours or Amazon's. If this is an issue you add redundancy. When you load lots of resources from God knows where in a way such that any single failure takes the page down, you are reducing the reliability that you could have had if the resources were all in the same place which you concentrate on keeping available.
lazyjones 7y ago
Very important point. A major Austrian newspaper's web site currently doesn't work for me because I block FB's SDK. My choice in this case, but as a user I'm also at risk when FB can choose to block my browser and disable some (badly designed) web pages in the process.
butterthebuddha 7y ago
On the other hand, self-hosting everything doesn't let you take advantage of caching. What I mean is, if two sites use the same resource, and if both sites fetch the resource from the same URL, the resource will likely be cached by the browser once and reused again and again. This can be huge for load times when users visit a website for the very first time. Or at least, this was the argument that was floating around in the community, when I used to do web dev. It's been a few years since, and I'd be interested to see if people have other arguments for/against this.
- throwaway777555 7y ago
  These are good points, but there are a few things to consider. First, as the article points out, self-hosting may result in a faster experience for your users due to the slowness of Google's font delivery. Secondly, your site is likely already serving up other assets which are not nearly as large as the fonts themselves (CSS, logos, other images, JavaScript, etc), so the savings is really not that large in comparison. Third, you can make use of cache-control headers that will ensure that all of these assets don't expire on the client's side for as long as you'd prefer. One of the benefits of a CDN is the "N" part. If you host on a single server and you start getting requests from across the globe, those users will have a slightly more fluid experience if they can download the assets from a server that's physically closer to them than if they have to wait for packets to hop across dozens of nodes.

by nirui 7y ago

yathern 7y ago

> Imagine a user who can access your page but cannot access Google, the user then has to wait a long time looking at a blank page before the web browser stopped trying, that is some really really bad experience. Not quite how web fonts work, usually they just swap in for the system fonts once loaded.

nirui 7y ago
Yes, a well-designed system can minimize the impact by for example lazy-load the font file or even `Font Face Observer`[0] them for manual hot swap. But that is not the main point. The main point is: You are the one who's in charge of the user experience, not Google. Don't shift the responsibility to somebody (external service) you don't have control of. The software works the best when all it's parts are predicable, and make it more self-sufficient can help. [0] https://fontfaceobserver.com/ https://fontfaceobserver.com/
swiley 7y ago
Google’s own pages don’t do that, they intentionally hide the text until the font loads to prevent a “flash of unstylised content.” (It’s quite a bit longer than a flash on many connections, plenty long enough to start reading.)

spookthesunset 7y ago

The odds of google being down / slow instead of your site are pretty bad. Unless you build your own data center, pull in all the fiber yourself, make the network switches yourself, build the servers yourself, etc... you are always going to be dependent on a third party or external service.

polyphonicist 7y ago
Google has a reputation of shutting their services down. What if they shut their fonts CDN down or change their URLs without redirects?
- spookthesunset 7y ago
  Than a hell of a lot of sites lose their fonts until they update.
  - onion2k 7y ago
    To be fair, lots of people being affected hasn't stopped Google in the past. In the case of Fonts though, it's a good source of user and browser data, so it's not likely to be shut down any time soon.
- mewpmewp2 7y ago
  This might not be end of the world. In a lot of cases convenience is worth the risks. There is no golden rule that one should never depend on third parties. It is always balancing pros vs cons. Self hosting introduces extra code, resources and assets that you as a developer must introduce and maintain. This is not free. Especially if worst thing that happens is a wrong font loaded.
adrianN 7y ago
It's not instead of, it's an additional failure mode.
pmlnr 7y ago
Google is blocked in some parts of the world, so chance of "being down" is actually non zero if you think of the whole world.
- kube-system 7y ago
  Also, some webpages don’t even run on the internet.

allenskd 7y ago

I usually just download and self-host for this reason. A software should never rely or be dependent to content delivery networks/repositories like Google Fonts. There's nothing wrong with Google Fonts as a service and repository (tracking stuff aside), but I've never felt comfortable at the idea that we just link, lets say, jQuery or Angular through CDN and call it a day. I should add that most of my work is through intranet applications with servers only accessed through VPN and I've seen the firewall disrupt Microsoft services one too many times so... it's more of a "yea, it's just a save-as or copy file to my app assets folder" versus users sending me emails that the pages stopped working.

Havoc 7y ago
> A software should never rely or be dependent to content delivery networks/repositories Not sure that's viable in today's cloud-y world
- pmoleri 7y ago
  Isn't that like not trusting AWS and have your own reliable data center for website hosting? Edit: Removed cache statement.
  - Havoc 7y ago
    Pretty much. I'm really starting to doubt whether it's competitive to do your own thing anymore. And this seems to be getting worse. Hard to compete with the combo of features & scaling that cloud provides. Attempting it pretty much guarantees you a gnarly trade-off somewhere (reliability, complexity etc).
  - sideshowb 7y ago
    You have to accept that a server may fail to be accessible, whether it's yours or Amazon's. If this is an issue you add redundancy. When you load lots of resources from God knows where in a way such that any single failure takes the page down, you are reducing the reliability that you could have had if the resources were all in the same place which you concentrate on keeping available.

lazyjones 7y ago

Very important point. A major Austrian newspaper's web site currently doesn't work for me because I block FB's SDK. My choice in this case, but as a user I'm also at risk when FB can choose to block my browser and disable some (badly designed) web pages in the process.

butterthebuddha 7y ago

On the other hand, self-hosting everything doesn't let you take advantage of caching. What I mean is, if two sites use the same resource, and if both sites fetch the resource from the same URL, the resource will likely be cached by the browser once and reused again and again. This can be huge for load times when users visit a website for the very first time. Or at least, this was the argument that was floating around in the community, when I used to do web dev. It's been a few years since, and I'd be interested to see if people have other arguments for/against this.

throwaway777555 7y ago
These are good points, but there are a few things to consider. First, as the article points out, self-hosting may result in a faster experience for your users due to the slowness of Google's font delivery. Secondly, your site is likely already serving up other assets which are not nearly as large as the fonts themselves (CSS, logos, other images, JavaScript, etc), so the savings is really not that large in comparison. Third, you can make use of cache-control headers that will ensure that all of these assets don't expire on the client's side for as long as you'd prefer. One of the benefits of a CDN is the "N" part. If you host on a single server and you start getting requests from across the globe, those users will have a slightly more fluid experience if they can download the assets from a server that's physically closer to them than if they have to wait for packets to hop across dozens of nodes.