Hacker News Reader

Comment by _wmd | Hacker News Reader

> Except that a shared CDN which everyone uses results in better performance.

This is thrown around a lot, but very rarely with hard numbers to support it. A cold DNS cache costs at least one roundtrip, a cold SSL session cache costs several, a new SSL connection (presently) costs at least 2.

Meanwhile, all the above is necessary to talk to an origin site anyway, and networking performance for the best part of 10 years has been dominated by latency (i.e. roundtrips) rather than throughput.

Hoping the user had an idle connection to the Google CDN when measuring cold request start is wishful thinking

Meanwhile self-hosted reuses all of the above and enables assets to be combined into a single transaction, which vastly improves the behaviour of TCP cold start

View on HN

From googling: https://www.keycdn.com/blog/web-font-performance/

Skip to "Here is a comparison of hosting Open Sans locally vs Google CDN."

They found it was faster to use a Google CDN. One of the things this article suspects is that CDNs will have better world-wide coverage, and therefore overall latency, than hosting your font yourself.

I'd like to see a comprehensive study of your counter point, though.

This test was performed with a single client based in LA, and concluded the fastest font - Open Sans - downloaded in 476ms. The test fails to measure how much of this is setup time vs transfer time, or account for behaviour of TCP during the transfer. You will find, and I will measure this for you if you really want, that setup time absolutely dominates this cost.

If setup time is amortized across all assets on a site, as it is when self-hosted, the true cost of the 220KiB font download will be vastly lower -- closer to 100ms assuming a sufficiently warm TCP connection over even an 8Mbit link, and significantly less again with faster links.

As for browser-side caching, this is once again wishful thinking and there is no room for it in any kind of engineering discipline

Does Google Fonts even use TCP? It might be HTTP2+QUIC.

> "... hosting Open Sans locally vs Google CDN."

Both of these are still a lot slower than simply installing the font in the OS (or browser) and loading out of the filesystem block cache (or using the already-loaded font in browser memory). Open Sans is Apache License 2.0, so it should be easy for browsers/OS to provide it as a standard font instead of merely the "web safe" set of fonts.

55ms is something, but that chart baseline is not 0ms and makes it look like the difference is waaay more significant :)

The caching happens browser level. Chrome won't bother opening a connection if it sees a URL it knows.

The user's browser often doesn't need to make any request to Google's CDN because the font has already been downloaded and cached for use from some other site. Self-hosting doesn't allow this.

Even if we solve this problem by getting the users permission, or using signatures instead of a URL that points off site, or with a proxy (transparent/hosting at server/tor) then what is the next complaint?

Do we trust the server we're connecting to with their own TLS certificate revocation status? DNS? What about all hops along my network path? Email headers?

I doubt this was the intent. Using the Internet is inherently public. Privacy is hard and needs a clear separation / promise to the user. With that, Governments should have an awareness campaign so people know when they visit their bank website that they may be accessing third parties for fonts and tracking and that only their financial information is private.

Moreover, the browsers have a caching mechanism.

Additionally, it should improve with HTTP/2 because servers can push the fonts immediately and because of connection multiplexing?

Reply on news.ycombinator.com