Google Fonts: more than a trillion served • Hacker News Board

Re: Google Fonts: more than a trillion served

#81

Post by DigitalSea » Sun, Dec 01, 2013, 11:54 PM UTC

yen223 wrote: post #69

DigitalSea wrote: post #65

Earlier quoted context omitted.

This. It's worth pointing out that the antialiasing issue only affects Windows PC's. But this is very much a font issue us developers have to hack around. -webkit-font-smoothing and setting the value to antialiased sometimes fixes this issue.

The weirdest part is that, Firefox on Windows renders those fonts fine.

Firefox is fine, yeah. Although, sometimes you do get a weird faux-bolding issue in Firefox for some fonts which cannot be fixed except for not using light text on a dark background and some custom fonts.

Re: Google Fonts: more than a trillion served

#82

Post by markdown » Mon, Dec 02, 2013, 4:02 AM UTC

Silhouette wrote: post #79

markdown wrote: post #78

Earlier quoted context omitted.

Oh I didn't mean that to be a browser limitation, but that it is generally a good idea performance wise.

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 s…

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/

Re: Google Fonts: more than a trillion served

#83

Post by gress » Mon, Dec 02, 2013, 4:34 AM UTC

DannyBee wrote: post #80

gress wrote: post #75

Earlier quoted context omitted.

If Google is not a single cohesive whole, how can you speak for it?

Certain people have certain authority to talk about certain things. I set policy around open source and open source licensing. I can speak officially to open source issues for Google (though at least here, i'm not unless I specifically say I am) This does not mean it's a cohesive whole however. In particular, a small team Of 3-4 people in the middle of a random non-android product area is not going to have the androi…

Since executives such as Eric Schmidt are happy to quote numbers about Android or Google+ in opaque and misleading ways, it seems entirely reasonable to believe that some other teams within Google may act to preserve the general message out of esprit-de-corps, whether or not they have android team members breathing down their necks.

Re: Google Fonts: more than a trillion served

#84

Post by Silhouette » Tue, Dec 03, 2013, 12:14 AM UTC

markdown wrote: post #82

Silhouette wrote: post #79

Earlier quoted context omitted.

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 s…

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/

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.