Gzipping uncached content

Comments

3 comments

  • Justin

    You're correct: we only gzip content that we can cache. Or in other words we don't gzip content that is not stored by us.

    No, there's no way to force gzip for those requests. The responses just come straight from the origin server and we don't alter them.

    0
    Comment actions Permalink
  • Chaim Klar

    @justin

    No, there's no way to force gzip for those requests. The responses just come straight from the origin server and we don't alter them.

    we do have a need to gzip such "uncached content" how can we go about it?

    0
    Comment actions Permalink
  • ryantownsend

    It's a shame Fastly can't just handle the GZIP in these scenarios, provided the Cache-Control header doesn't contain no-transform, because I'm sure their stack will be much more optimised for this than most client's origin servers.

    That said, we've managed to work around this.

    I'm not sure what your back-end technology is, but we implemented GZIP at the origin for any non-idempotent request methods (e.g. POST/PUT/PATCH/DELETE) and any idempotent requests which respond with a Cache-Control header containing private (neither are cached by Fastly, by default). This might put a little additional load on your origin, but does solve the problem – we saw a huge reduction in bandwidth utilisation from this.

    0
    Comment actions Permalink

Please sign in to leave a comment.