Normally UX designer, I'm currently also product manager for a range of web tools but my dev skills aren't very strong at all, so forgive me if this is a silly question. We're building a range of Bootstrap pages for a set of corporate tools, and at the moment we're using the Google Fonts API for our fonts. I'm a bit worried about load-time, and we think it may be Google Fonts gathering data. Before we unpick our current designs and install the font files on the server, I was wondering if anyone else noticed any load time when using Google Fonts and whether uploading the fonts themselves was a solution - or whether that's just going to make it even worse?
-
Hi caztec, welcome to GDSE and thanks for your answer. If you have any questions, please see the help center or ping one of us in chat once your reputation is sufficient (20). Keep contributing and enjoy the site!– VincentMar 31, 2015 at 12:06
-
1This is more a question for Stack Overflow than GD.SE I think.– PieBie ♦Mar 31, 2015 at 12:21
-
Yes, this is a SO question. Not a GD question.– DA01Mar 31, 2015 at 16:48
-
Also be sure to only grab the font weights you need (vs. the entire font family)– DA01Mar 31, 2015 at 18:09
-
You're on an intranet? I suppose you better don't pull anything from anywhere then.– tillinberlinApr 1, 2015 at 16:27
4 Answers
Short answer: Google is much faster than you hosting it yourself.
Long Answer: Putting it on your own server might seem like a good idea to improve load times. After all, the files are closer to your webpage. But, no. After all, when a user goes to your website, initially they just get some HTML. Here we have references to other files: Images, JS, CSS, and, in your case, Fonts.
For each of these external resources, the client will make a new call to the webserver where the file location is provided. So wether you host files yourself or reference google, the call to that resource will happen at the same time.
However, unless you are an exceptional company, googles server wil respond much faster. It will also use googles bandwith, rather than yours, saving you (maybe, a little bit) of money on that.
-
1We have to go outside the corporate network to fetch files, i think this was my worry - there are a couple of barriers we have to go through to reach Google and back again. You're probably spot on though - thanks!– caztecMar 31, 2015 at 12:22
-
@caztec is this an intranet? If so, then this is a rather moot issue as hopefully the internal network is already plenty fast.– DA01Mar 31, 2015 at 18:09
-
And if it is an intranet, meaning you likely have a fairly controllable, relatively small number of machines that will visit the pages, having the font installed on the machines so you don’t need to fetch them from anywhere will of course be the fastest of all. Mar 31, 2015 at 18:24
-
@DA01 it is yeah, it's super fast. We're just getting this odd delay on all the pages we're using with Google Fonts, really odd– caztecApr 1, 2015 at 15:14
-
1@caztec that sounds like a firewall issue of some sorts. The answers in here are rather broad and can't address specific issues with your internal network. So, keep that in mind. In your particular case, it probably does make sense to host the files yourself to keep everything in your own network.– DA01Apr 1, 2015 at 15:37
Loading files from third party servers (google) can slow down loading time since the browser has to make a request to a different machine. Basically loading everything from one domain should be faster than loading files from different webservers.
However – chances are that the google font is already in the visitor's cache file. This again would speed things up since the browser would not have to load it again.
The same applies to other assets like jquery libraries etc. as e.g. described over here: "Why you shouldn't use external javascript files" (http://www.elxis.org/de/blog/external-js-files.html)
-
3This isn't really true. Whether a request goes to one server or many is mostly irrelevant. What's a bigger issue is concurrent connections...most servers will limit the number of concurrent requests meaning hitting 3rd party servers is usually a faster solution.– DA01Mar 31, 2015 at 16:41
-
1@DA01 Right. Especially since CDNs (Content Delivery Networks, such as googles hosted libraries) are optimized for he fastest possible response. But yeah - which server your request goes to is irrelevant. Mar 31, 2015 at 18:04
-
1As for the linked article:
1) Target domain not available
: Non-issue with CDNs which have massive amounts of backup servers. Of course you shouldn't load your js from grannysknittingwear.com.2) Speed reduce
just not true as of now. The time at which the request begins is always the same - and a CDN-Server responds faster than yours. 3) and 4) are, again, not an issue with actual CDNs. They won't delete the versions you use for a long time and you can bet a lot that your own hosted files are comprimised and changed much sooner than theirs. Mar 31, 2015 at 18:09 -
Can anybody please support their suggestions at least with links or quotes or anything the like? I mean – not google links? Here's two links to people explaining, why third party webfont hosting is (can be) technically slower: feedthebot.com/pagespeed/web-font-options.html and bdadam.com/blog/loading-webfonts-with-high-performance.html But as I said above: If you're dealing with (popular) google fonts, chances are that the font is already in the user's browser cache – and that can make it actually load even faster. Cheers. Mar 31, 2015 at 22:07
-
@DA01 At some point I see your point – the limit of 'concurrent requests' can become a problem. But pointing to 'concurrent requests' in the context of webfonts (or other 'simple requests') just doesn't fit the problem. Feel free to read on over here: stackoverflow.com/questions/5017392/… or here: serverfault.com/questions/75054/… Mar 31, 2015 at 22:33
When you request a web page, you request more than the web page. You are requesting the HTML file, all images, all CSS files, all JS files, all Font files, etc.
Your server will rarely let you request all of those items at once. It will instead limit the number of concurrent requests and ask you to queue up the rest. This isn't a huge deal, but the more requests, the more likely something is going to be queued. In addition, many servers will block all requests while a JS file is being downloaded.
This is why it's better to request 1 100k CSS file rather than 10 10k CSS files. The data is all the same, but you lose efficiency by having to make all those separate requests.
So, at least for CSS, one recommendation is to simply combine all your CSS into one CSS file.
You can't do that with fonts, though.
The recommendation there is to load them from 3rd party servers. There are a few reasons for this:
- if the 3rd party server is popular and the file requested is popular, chances are it's already cached in the end-user's browser
- if it's a large 3rd party (aka Google) they likely have a huge infrastructure with plenty of bandwidth
- if it's a CDN (Content Delivery Network...which I believe Google Fonts is) then you have the added bonus that the data is hosted on multiple servers world-wide and the request is routed to the location closest to the person requesting it.
So, in general, always load common assets from large 3rd parties whenever practical.
You should put 'em on your server :-)
Reason:
1) It will be faster, even if they have it cached from a prior site that uses Google, it will create the cache 1st time anyway so it would only affect the 1st experience.
2) say the google server goes down and you haven't put them on your server.. then those fonts disappear and are replaced by whatever their browsers default is.
Definatly should upload to server, calling the Google API is quicker to set up and what not but there is always the chance of it going down without you even knowing..
-
"It will be faster" isn't necessarily true. And while server downtime is always a concern, I'd hazard a guess that Google is in the top fraction of a percentile in terms of up-time.– DA01Mar 31, 2015 at 16:47