Serving gzip'ed static files when hosting on Heroku

fullofcaffeine · August 23, 2013, 5:18am

When using the native gzip feature (activate :gzip), what is the best way to serve them when hosting on Heroku using Rack::TryStatic?

I’m having a bit of a headache trying to come up with a solution for that, everything out there seems to consider Rack::Deflater as the defacto way, but I’d like to just serve the pre-generated gz files, instead of zipping them on the fly, like Deflater does.

Any suggestions appreciated!

Aupajo · August 27, 2013, 2:17am

You could always write a small Rack app that serves the pre-generated .gz files.

What’s the problem with Rack::Deflater? I don’t think you’ll find much difference in speed.

Aupajo · August 27, 2013, 3:25am

Here. I wrote a Rack app that works with Middleman’s .gz files. It probably needs to check the request headers include the right Accept-Encoding before serving a GZipped response, but I’ll leave that as an exercise for the reader.

gist.github.com

https://gist.github.com/Aupajo/6349315

config.ru

class StaticGZip
  DIRECTORY_INDEX = "index.html"
  attr_accessor :root_dir

  def initialize(root_dir)
    @root_dir = root_dir
  end

  def call(env)
    request = Rack::Request.new(env)

This file has been truncated. show original

tmaier · October 16, 2013, 9:12am

Hi @Aupajo,

your StaticGZip looks great.

I just found a gem which seems to have a similar feature set as yours:

But your class design looks much cleaner.

You could improve the existing gem with your class design or you could release your class as a gem as well.

Aupajo · October 16, 2013, 10:06pm

Hi @tmaier,

Thanks! I would love to do something like that, but I’m a little reluctant to dive in. Using this approach isn’t something I would ever use personally, so I worry that I wouldn’t have much motivation to keep it well looked-after.

The truth is, I think people should stick to Rack::Deflater or handle the gzipping at a higher level (e.g. nginx/Apache). Both will not introduce any noticeable delay to server processing time.

If it’s performance anyone’s concerned about, they should measure it. I suspect anyone who tries won’t find any significant impact. There are far better places to optimise server load times.

Gzipping is not CPU intensive and the response is streamed, so it’s not as if the whole file has to be gzipped before it can start being sent to the client or anything.

Here’s a nice StackOverflow response addressing this: