Cloudflare is missing the current WOFF media type in the default compression config

[Nathan2055]

What is the name of the domain?

nathan2055.com

What is the issue you’re encountering

WOFF 1.0 font files are not properly compressed because Cloudflare’s backend only has the pre-RFC 8081 media types configured as automatically compressing

What steps have you taken to resolve the issue?

While updating the font configuration on my website, I noticed that the WOFF 1.0 files that I was using were not being compressed by Cloudflare. Looking into this led me to Content compression | Brotli · Cloudflare Speed docs, where I noticed that while font/x-woff and application/font-woff are included on the list of valid media types for compression, the currently accepted font/woff media type is not. RFC 8081 (RFC 8081 - The "font" Top-Level Media Type) officially defined and registered the font/* prefix for media types, replacing and deprecating the previously registered application/font-* tree in the process. Based on some research, it appears that application/x-font-woff and font/x-woff were briefly used in the early 2010s prior to the IETF and IANA getting things standardized, but both were always considered unofficial “vendor” media types.

I wouldn’t drop any of the existing types for compatibility reasons, but would it be possible to get font/woff added to the list of compressible media types, since that’s the one that’s currently standardized by the IETF and IANA? If you want completeness, you could also add application/x-font-woff to the list, since it looks like that was briefly recommended by the Chromium team back in 2011 (see Chromium) and is the only other non-standard WOFF 1.0 media type that isn’t already on the list, but that’s not really as critical as getting the standardized font/woff media type added.

(If anyone is reading this who isn’t aware of the history and difference between the web font formats and why they should and shouldn’t be compressed: WOFF 1.0 was standardized between 2009 and 2012 and added a number of useful web features on top of the existing SFNT/TrueType/OpenType font format, including most notably zlib/gzip compression. WOFF 2.0 was standardized in 2018, with the only substantial change being replacing zlib/gzip compression with the newer Brotli algorithm. This is why WOFF 1.0 (and TTF/OTF) should be recompressed at the edge but WOFF 2.0 shouldn’t: WOFF 2.0 files are already Brotli compressed, so recompressing them at the HTTP level will likely only add more overhead; however WOFF 1.0 files are zlib compressed and can still often get a decent additional savings from applying Brotli on top of it (and TTF/OTF aren’t compressed at all, and so should always be compressed in some way). The Cloudflare team might want to evaluate adding WOFF 2.0 to the list if and when they ever add zstd support to their compression functionality, as zstd offers even better space/time savings than Brotli in some scenarios.)

What are the steps to reproduce the issue?

1. Serve a WOFF 1.0 file through Cloudflare with a RFC 8081-compliant font/woff media type.

2. Notice that it is not being compressed by Cloudflare.