![firefox text encoding firefox text encoding](http://www.alanwood.net/unicode/firefox-encoding-default.png)
The server then responds with the `Content-Encoding` header specifying what form of compression was used, if any at all. The server might not even support any form of compression. It’s up to the server to decide which encoding to choose. Just because the client supports these encodings doesn’t mean that’s what they’ll get.
![firefox text encoding firefox text encoding](https://i0.wp.com/www.betterhostreview.com/wp-content/uploads/disable-css-page-style-firefox-browser.jpg)
Let’s see what such a header might look like in Firefox 43 (prior to Brotli support) dev tools. The way the User Agent, client, or Web browser signals to the server what kinds of compressed content it can decompress is with the `Accept-Encoding` header. Adding compression improves transfer times when the content is large, isn’t already compressed (reapplying compression doesn’t buy you anything, unless you’re Pied Piper), and the cost to communicate is relatively large. This is due to bandwidth constraints over the wire. Somewhat unintuitive, doing extra work to compress an HTTP response server side, and decompress the result client side is faster than not doing the additional work. When serving content over the web, an easy win or low hanging fruit is turning on server side compression.
Firefox text encoding how to#
In this post, we’ll show you an example of how to set up a simple HTTPS server that takes advantage of Brotli when supported by the client. Support for Brotli content encoding has recently landed and is now testable in Firefox Developer Edition (Firefox 44). It can be used to compress HTTPS responses sent to a browser, in place of gzip or deflate. Brotli is an open source data compression library formally specified by IETF draft.