Font loading update: All HTTPS, all the time
If you opened up the kit editor today, you may have noticed that the default and advanced embed codes have changed. Instead of the protocol-less URL we recommended for years, we now recommend a HTTPS URL only. We’ve also changed our kit JavaScript to load all resources over HTTPS.
We’re updating the protocol-less embed code (top) with HTTPS by default (lower).
We’ve made this change as a response to the recent vulnerabilities and exploits in the OpenType and TrueType font formats. A malicious attacker could use these vulnerabilities to modify a Typekit font while it is being transmitted from our servers to your browser. Serving fonts (and other resources) over HTTPS ensures that the communication channel between your browser and our servers is not compromised and fonts are delivered in a secure way.
Changing to this new embed code won’t affect your website negatively. You can safely replace (or update) the protocol-less URL with the secure version and your site will continue to get fonts — only in a more secure way. You can also do this if your site only supports HTTP; it is no problem to load secure resources on a HTTP-only website.
We actually switched over all our font and CSS loading to HTTPS about a month ago. We’ve been monitoring our performance metrics since then and haven’t seen any significant change in performance. We won’t be shutting down (or redirecting) our HTTP endpoints for the foreseeable future, since many old kits and web pages still rely on them. However, we strongly recommend that everyone update their embed code for a safer web.
Please let us know at support@typekit.com if you’re concerned about this change or if you have any questions.
2 Responses
Comments are closed.
Many improvements in recent times! Great work.
There’s a potential source of improvement. Since the JS file loaded by Typekit has a low max-age, there’s a high chance of an X-cache miss and your CDN has to request the origin server for the file. You could instead have something like a high TTL (or an “s-maxage”) for your CDN and invalidate the object on the CDN if the Typekit user makes changes in the Kit.
In that light, it is weird (though sadly not entirely unexpected) to see this blog still use the old protocol-relative URI.