3 ms·

Is it against the TOS to download the font and host it on your own server? It's very simple to do even though they don't give instructions.

jonknee 13y ago
No: https://developers.google.com/fonts/faq#Download_Fonts https://developers.google.com/fonts/faq#Download_Fonts
putlake 13y ago
I am in the middle of a redesign and the new design uses Droid Serif. I wanted to avoid an extra HTTP request and bundle the WOFF font file in the CSS (using data URIs). The other option was to host the font on my server to avoid the DNS lookup for yet another domain. (CSS is in the critical path for page loads). Both are easy to do but I abandoned both of those ideas after watching this interview http://www.youtube.com/watch?v=sqesm0euf9M http://www.youtube.com/watch?v=sqesm0euf9M Google Fonts makes a lot of optimizations that are platform-specific. e.g. serve smaller files to Macs, larger files to Windows. It is not worth doing all this yourself.
- markdown 13y ago
  Don't put anything more than 10KB into a CSS file as a data URI.
  - Silhouette 13y ago
    Where does this limit come from? IE8 can handle up to 32KB[1], and more recent versions of all major browsers appear to have much higher limits. IE7 and below didn't support data: anyway. [1] See http://caniuse.com/datauri http://caniuse.com/datauri, and confirmed by Microsoft's own technical documentation.
    - markdown 13y ago
      Oh I didn't mean that to be a browser limitation, but that it is generally a good idea performance wise.
      - Silhouette 13y ago
        Why would that be the case? In terms of file size, a naive implementation of replacing reference to image files with data: URIs carries a theoretical overhead of 1/3. However in practice, as long as you're serving the relevant CSS file gzipped, you're likely to see less than 5% overhead on a single file. If you've got several similar image files converted to data: URIs within the same CSS file, you might even see a significant gain because the compression can remove more redundancy. In terms of HTTP requests, generally fewer is better, so it's hard to go wrong here by using data: URIs instead of separate but relatively small image files. The only major factor I can immediately think of that is clearly in favour of separate image files, unless you're really at the level where the decoding performance for data: URIs makes a significant difference, is that the image files can be cached independently, which may or may not be a win depending on how you manage your CSS and how often the various parts of it change relative to each other.
        markdown 13y ago
        Don't forget that browsers will wait for the CSS file to download before rendering the page. Far better to let "unnecessary" image files load later via separate HTTP requests than to delay everything just so that you can save one or two HTTP round-trips. This is a big issue on mobile. I'd advise comparing both methods on https://developers.google.com/speed/pagespeed/insights/ https://developers.google.com/speed/pagespeed/insights/
        Silhouette 13y ago
        YMMV, but we did plenty of testing for one site I currently work on with a heavy mobile access focus, and it wasn't even close. We could have added hundreds of extra KB in a CSS file and still beaten even a single additional image file that needed a whole extra HTTP round trip for a visitor with a typical intermittent mobile connection (poor reception, on the move, etc.). The multiple levels of set-up required in that context can easily dominate the overall time to seeing a useful page. Of course it's less of a dramatic comparison if you don't have all that set-up overhead to worry about, but then the time to download an extra 200K of CSS is negligible on basically any broadband or stable 3G or better connection today, so we don't tend to worry much about that sort of situation. In practice, our decision on how to transmit medium-sized images is often based on cache-related factors.
- bennyg 13y ago
  My least favorite thing about Google Fonts is that they look different on different browsers for each platform too. On my latest site design I had to put them on my server because they actually looked the worst in Chrome.

jonknee 13y ago

No: https://developers.google.com/fonts/faq#Download_Fonts https://developers.google.com/fonts/faq#Download_Fonts

putlake 13y ago

I am in the middle of a redesign and the new design uses Droid Serif. I wanted to avoid an extra HTTP request and bundle the WOFF font file in the CSS (using data URIs). The other option was to host the font on my server to avoid the DNS lookup for yet another domain. (CSS is in the critical path for page loads). Both are easy to do but I abandoned both of those ideas after watching this interview http://www.youtube.com/watch?v=sqesm0euf9M http://www.youtube.com/watch?v=sqesm0euf9M Google Fonts makes a lot of optimizations that are platform-specific. e.g. serve smaller files to Macs, larger files to Windows. It is not worth doing all this yourself.

markdown 13y ago
Don't put anything more than 10KB into a CSS file as a data URI.
- Silhouette 13y ago
  Where does this limit come from? IE8 can handle up to 32KB[1], and more recent versions of all major browsers appear to have much higher limits. IE7 and below didn't support data: anyway. [1] See http://caniuse.com/datauri http://caniuse.com/datauri, and confirmed by Microsoft's own technical documentation.
  - markdown 13y ago
    Oh I didn't mean that to be a browser limitation, but that it is generally a good idea performance wise.
    - Silhouette 13y ago
      Why would that be the case? In terms of file size, a naive implementation of replacing reference to image files with data: URIs carries a theoretical overhead of 1/3. However in practice, as long as you're serving the relevant CSS file gzipped, you're likely to see less than 5% overhead on a single file. If you've got several similar image files converted to data: URIs within the same CSS file, you might even see a significant gain because the compression can remove more redundancy. In terms of HTTP requests, generally fewer is better, so it's hard to go wrong here by using data: URIs instead of separate but relatively small image files. The only major factor I can immediately think of that is clearly in favour of separate image files, unless you're really at the level where the decoding performance for data: URIs makes a significant difference, is that the image files can be cached independently, which may or may not be a win depending on how you manage your CSS and how often the various parts of it change relative to each other.
      - markdown 13y ago
        Don't forget that browsers will wait for the CSS file to download before rendering the page. Far better to let "unnecessary" image files load later via separate HTTP requests than to delay everything just so that you can save one or two HTTP round-trips. This is a big issue on mobile. I'd advise comparing both methods on https://developers.google.com/speed/pagespeed/insights/ https://developers.google.com/speed/pagespeed/insights/
        Silhouette 13y ago
        YMMV, but we did plenty of testing for one site I currently work on with a heavy mobile access focus, and it wasn't even close. We could have added hundreds of extra KB in a CSS file and still beaten even a single additional image file that needed a whole extra HTTP round trip for a visitor with a typical intermittent mobile connection (poor reception, on the move, etc.). The multiple levels of set-up required in that context can easily dominate the overall time to seeing a useful page. Of course it's less of a dramatic comparison if you don't have all that set-up overhead to worry about, but then the time to download an extra 200K of CSS is negligible on basically any broadband or stable 3G or better connection today, so we don't tend to worry much about that sort of situation. In practice, our decision on how to transmit medium-sized images is often based on cache-related factors.
bennyg 13y ago
My least favorite thing about Google Fonts is that they look different on different browsers for each platform too. On my latest site design I had to put them on my server because they actually looked the worst in Chrome.