Enable gzip compression

[saivann]

This pull request adds support for gzip compression in order to increase performance and reduce load on the server (thanks to @louisjc and @harding for the idea on issue #916).

This single line change allows the build script to generate a .gz copy of all files for which compression offers a measurable improvement. This is done right after the website has successfully built, and before transferring files to the live server.

I have tested the build script and nginx locally with the following configuration and everything seemed to work as expected. Only compressed files are sent using gzip as the Content-Encoding header. The website also remains compatible with IE6 as expected.

    gzip_static on;
    gzip_disable "msie6";

@harding sha256sums.txt is already generated before files are compressed, so unless I am missing something, it should still work fine with that change.

[harding]

Untested LGTM up to 42cef24. @saivann thanks!, and I'm glad sha256sums.txt still works. :-)

[saivann]

@harding Thanks!

In the absence of critical feedback, this pull request will be merged on June 26th.

[louisjc]

@saivann LGTM, Should save a lot of bandwidth. By the way I didn't find the info: who is paying for this bandwidth and where is it hosted? (EDIT: Also, not the right place to ask, but why did this repo leave the bitcoin github organisation?)

[harding]

@louisjc the server is hosted by Block Lotus, for which we currently pay $590 a month from the sponsorship money given to us by the Bitcoin Foundation.

Details about the repository move can be found in #912, let me know if you have any questions after reading that thread.

Thanks again for your suggestion! I think it'll be a major improvement!

[saivann]

Gzip compression is now enabled and everything seems to be working fine. Many thanks again for submitting the idea!

[louisjc]

Ran some tests: 123,5 kB before and 62,3 kB after.
(subtracting the 498,9kB from google for the Youtube player)
Working great :)

[saivann]

@louisjc Great! That'll be especially helpful for HTML and JS content, which have much less aggressive caching policies (if any, I don't recall right away).

(subtracting the 498,9kB from google for the Youtube player)

Ah, not for long then! See #923

Many thanks again for your insightful suggestions :)