heroku-buildpack-php
heroku-buildpack-php copied to clipboard
Any reason Gzip is commented out in nginx config?
I'm looking to serve static assets with compression on a PHP site via nGinx, and I noticed that the gzip: on
setting is commented out, any particular reason for this? I can't find any comments online or anything via git blame.
Any help would be appreciated, thanks in advance
+1 on this,
we've seen a significant increase in transfered content after migrating to Heroku from a server that did have GZip enabled yesterday 10-02-2016:

PS, yeah we know, still got to reduce the overall amount of transferred content like scripts, but that is a different issue ;)
@dzuelke any comment on this ?
Is it a problem to enable it in the custom config that 99% of Nginx users on Heroku need anyway? :)
(it's not enabled in Apache either)
In case it is not enabled by default, it might be useful to extend the current documentation a bit? Maybe with examples?
On the otherhand, it might save Heroku considerable amount of data transfer by enabling it by default, so why not enable it? And it is 2016, right? :smile:
Like those docs say, it's the responsibility of each application (and those docs are language agnostic, so no PHP specific stuff will go in there). So the normal Nginx or Apache configuration for compression applies.
Right now I see many customers only compressing JS/CSS/images, not page content. What would the default be? gzip_vary on;
? What level? gzip_disable
or not? Are all customers fine with gzip_proxied any
? Will existing gzip setups break?
The defaults in Nginx are not enough. I can't just throw gzip on;
into the default config; you need to set a whole bunch of directives...
ok, guess that would be a justified reason as was requested by @redroot then...
Yeah :) I'm leaving this open as a reminder; not saying we can't do it by default, but it needs to be done carefully. I should have bandwidth to tackle this in a few weeks.
I am looking to have a solution for this as well. Maybe I have missed it or am new to this, but can I just specify my own nginx.conf?
@hekaldama you can in your Procfile
:
web: vendor/bin/heroku-php-nginx -C etc/heroku/nginx.conf web/
In your nginx.conf
:
gzip on;
# ...
That didn't appear to work for me.
I still find it a little weird that gzip isn't enabled by default for both Apache and nginx.
Are you open to changing that default?
@dwightwatson You could take a try this. It's work for me. https://github.com/pmvc/heroku-config/blob/master/nginx_app.conf#L30-L37
Test it on: https://react-pmvc.herokuapp.com/hello_app/ttfb
The minimum config you need:
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_types …;
Is there some magic trick to make this work?
Been trying to get gzip working with Apache with no success. Then I tried nginx and it doesn't work either. I can't figure why.
I added this from @HillLiu's comment above:
location / {
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_min_length 1k;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_comp_level 9;
gzip_types text/plain
text/javascript
text/css
text/xml
application/json
application/javascript
application/atom+xml
application/rss+xml
application/x-javascript
application/xml
application/xhtml+xml
application/x-font-ttf
image/svg+xml
;
}
This is my repo: https://github.com/cenobitedk/aphasia-site Deployed here: http://beta.aphasia-records.com/
@cenobitedk Some case it affect by try_files and let it not apply " location / {} "
you have two options,
- move gzip outside location.
- use try_files fallback, and move gzip to fallback section.
About fallback you could refer. https://github.com/heroku/heroku-buildpack-php/blob/960199a978308c75926fd9bb4775f7113bf1d777/conf/nginx/heroku.conf.php#L32-L47
If you just want rewrite to index.php You could check what I write. https://github.com/pmvc/heroku-config/blob/master/nginx_app.conf#L24-L26
And add location ~ ^/index.php/ { { gzip xxx }
It should also work.
Thank you @HillLiu!
Option 1 seemed to do the trick!