Closed Bug 1080174 Opened 5 years ago Closed 5 years ago
Do not send Accept-Encoding:gzip,deflate when requesting WOFF or WOFF2 webfonts
When looking at webfont requests and responses in bug 1077312, I notice that in some cases, we receive WOFF fonts served with Content-Encoding: gzip (presumably deflate may also occur, although I didn't happen to see it). But the WOFF file is already compressed (with zlib) internally, so applying gzip or deflate to it will have almost no further effect. (I suspect this is usually a result of over-broad deployment of Apache mod_gzip or similar configurations, where the compression is applied to everything without regard to the type of data being served.) If the font were a "raw" OpenType font (.ttf, .otf) then gzip or deflate would make sense as a content-encoding, often giving a 30-40% decrease in size. So we should accept this for a "generic" font request when we don't know the format of the resource we're going to get. But in many cases, we already know (from the CSS format hint) what kind of font file we're requesting. So when we know it to be a WOFF or WOFF2 resource, we should send Content-Encoding:identity to tell the server NOT to try and "re-compress" what we know to be already-compressed data. This will make a negligible difference to the number of bytes sent over the wire (I tried a few tests, and saw differences of a few dozen bytes on typical WOFF files of 40-50K), and will reduce processing requirements at both the server and client ends.
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Comment on attachment 8502063 [details] [diff] [review] Do not send Accept-Encoding:gzip,deflate when requesting WOFF or WOFF2 webfonts. Review of attachment 8502063 [details] [diff] [review]: ----------------------------------------------------------------- fair enough..
Attachment #8502063 - Flags: review?(mcmanus) → review+
Target Milestone: --- → mozilla35
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Is this optimization already implemented for other compressed types, like .png, .jpg, .mp3, .avi?
(In reply to Alexandre Folle de Menezes from comment #5) > Is this optimization already implemented for other compressed types, like > .png, .jpg, .mp3, .avi? It was done for audio/video in bug 614760. I haven't investigated image types. Care to check, and file a bug if appropriate?
You need to log in before you can comment on or make changes to this bug.