Improved caching for kits: Opt for longer cache timeout

We often get questions about the cache time for our kit JavaScript. These requests often include a screenshot from Google’s PageSpeed Insights, which recommends increasing the cache time to a day or more.

We use a short cache time for the kit JavaScript so that you can update your kit (for example, adding fonts, or changing the list of allowed domains) and have your changes live in a reasonable amount of time.

pagespeed-insights

However, we know that many of our customers use kits differently. It is common to edit a kit often while designing a site, and not make any changes to the kit once the site is live. There isn’t much benefit in the short cache time for this use case.

For this reason, we’re introducing a new setting in the kit editor. This new setting enables a longer cache time of one week for the kit JavaScript. This feature is specifically made for kits that do not change once they are live. You can find this setting in the kit editor, under “Kit Settings.”

optimize

After ticking the checkbox, you’ll need to click “Save Settings” and then republish your kit for the changes to take effect.

A word of caution: though this will increase the cache timeout, it will also make it more difficult to make quick changes to your kit. It may take up to a week for changes to be visible to all your visitors when this option is enabled, and disabling the option won’t take effect until after a week either. Use this option only if you do not plan to make any changes to your kit.

With these changes, the following caching rules apply to Typekit:

  • Standard kit JavaScript is cached for 10 minutes.
  • If you select the Optimize Performance option for a kit, JavaScript is cached for one week.
  • CSS and font files are always cached for one week.

Let us know at support@typekit.com if you have any questions about this change or web font loading performance in general. We’re happy to help.

9 Responses

  1. Sebastian says:

    Thank you! This is just perfect.

  2. Errol says:

    I just switched to the Asynchronous/Advanced JS and now have the load Flicker effect on my site. If i were to use the standard JS and use this extended cache option would this solve load time/flicker issues?

    1. Bram Stein says:

      It will definitely help, but it won’t completely eliminate it, because the asynchronous CSS loading will make the browser render much earlier.

  3. xcession2k says:

    If you need to bust the cache of a kit on which you’d set “Optimize Performance”, could you just do //use.typekit.net/xxxxxxx.js?cachbuster ?

    1. Bram Stein says:

      That would work for busting the cache of browsers, but the kit will still be cached by our CDN for at least one week. If you disable the “Optimize Performance” option and republish the kit will be purged from our CDN. Combining that with the cache busting mechanism you described should get you quicker updates (though it kind of defeats the point of this feature). It might be easier to create a new kit if you want to make changes and update your HTML.

    2. Ramanan says:

      Bram,

      I don’t think a new kit creation is needed. If a Typekit user makes changes in the kit and wants to make it live to his/her users, he/she should append a query string to the javascript file in his/her code.

      I don’t know about Edgecast, but Cloudfront respects query strings if the user sets it. Perhaps Edgecast also has this option.

    3. And unlike other speed tests online, Google *rightly* doesn’t complain about query strings.

    4. Bram Stein says:

      Ramanan: Normally that would work, but our CDN does not cache query strings, so I would still recommend creating a new kit (or republishing with the feature disabled, and using a query string to bust the browser’s cache).

Comments are closed.