Tom: The ratio of total pageviews to non-cached requests (i.e. the cache hit ratio) will most certainly not stay the same from site to site, user to user, or even font to font. The measurement depends on what kind of site the fonts are on, how it’s structured, user behavior, and which fonts are popular for which types of sites. Imagine a site where you click through many pages in under five minutes vs. a site with a single page that you visit once a week and then leave. The only way for us to be accurate is to measure the actual metric in question.

There are a few separate issues in here that I’ll address individually.

First, you mention caching. Currently, we have to balance between kit updating speed (how long before published changes to show up) and longer cache times. This work moves us closer to being able to use much longer cache times for our fonts and improve caching in other ways. Stay tuned.

Second, you mention a delay caused by additional HTTP requests. The image loading is kicked off by the JavaScript, but it happens asynchronously. It shouldn’t significantly increase the time it takes the JS to execute, and the image request itself shouldn’t affect when the DOMReady event fires. DOMReady fires once the page is parsed and all non-async scripts are executed. The image request happens asynchronously and in parallel with requests for other assets on the page.

(this is a reply to Mandy Brown, because that button is unavailable)

you don’t need to do that. ratio of pageview counts between different fonts will most certainly stay the same (statistics ftw) no matter if you count caching or not, because it’s equally distributed among websites/browsers/users/fonts.

that’s a bit dishonest imo. the only effect this will accomplish is higher prices for your users, and you know that..

The price for a web font does not only cover the bandwidth and other technology costs; it also compensates the foundries and type designers who work hard to bring these fonts to the screen. We have always maintained that pricing for fonts should be connected to use: a large commercial site with lots of traffic should pay more for the same font than a small blog with only a few visitors a day. That has been — and continues to be — one of the reasons for our tiered pricing.

This change only affects the mechanism for that measurement, not the underlying rationale.

Yes, the foundry stats page will start to reflect this new measurement over the course of the next few weeks. Stay tuned!

I’m not sure what relationship exists, if any, between how many pageviews a webfont gets and how much its owner should get paid. I don’t believe it’s common for traditional typeface purchase licenses to restrict, for example, the circulation of the magazine in which it will be printed. Am I mistaken about that? Why adopt this model for webfonts?

Will font foundries that license webfonts to be hosted on Typekit be able to view now montly page views per website using their typefaces? Would be a huge help!

A

The goal here is not to increase prices (which would have been much easier to do); the goal is to fairly compensate our foundry partners for the use of their fonts. I believe our policies have always been transparent and fair, and this change continues to reflect that.