I have a meteor website which uses SSR. The html output is quite large and I want this gzipped.
Atm we are hosting the website on GCE with a Nginx server in front of the website which does the gzipping.
But now I really want to host this website on Galaxy, and having the html gzipped is really important.
Is there already a possibility to do this on Galaxy? Or is there another way to do this in Meteor?
Pingdom is advising me to “compress components with gzip”. I was just searching the Galaxy docs for a way to do this and didn’t yet find it. Is there a way to do this yet with Galaxy?
I’ve read about this before, because I was looking for gzip compression gains myself, and I remember reading this post on StackOverflow:
This is an easier to read copy/paste of the code:
// in your package.js, need to also add
var compression = require('compression')
//always compress
WebApp.rawConnectHandlers.use(compression({filter: function(){return true}}))
//or only compress files under the images folder
WebApp.rawConnectHandlers.use('/images',compression({filter: function(){return true}}))
I’ve not yet tried this myself, so let us know if you give it a try.
Basically the WebApp package in Meteor handles all the network traffic of your app, so that’s why it’s probably the place to add extra compression.
Meteor’s WebApp package also in a well done wrapper for the connect package on npm so if you want to read more about what is happening with gzip & connect, there is more documentation there.
var connect = require('connect');
var http = require('http');
var app = connect();
// gzip/deflate outgoing responses
var compression = require('compression');
app.use(compression());
The connect package is a great package.
Galaxy Support got back to me (thanks @filipenevola!) and showed that the Chrome devtools>>Network>>Headers report that my site is gzipped already:
I asked what Pingdom could be looking at, and he advised following the directions posted here by @mullojo to see what it changed if anything. So I tried it. I ran meteor npm install --save compression, and then on server startup, ran:
import compression from 'compression';
WebApp.rawConnectHandlers.use(compression({filter: function(){return true}}))
Checking with the --production flag on, using bundle-visualizer with and without WebApp.rawConnectHandlers.use(compression({filter: function(){return true}})), showed no difference in the app size – 1.34 mb total.
So I’m not yet sure what Pingdom is looking at. I’m even questioning Pingdom a bit, because looking at their report, I see they show each file request, and the “encoding” attributes, and it looks like the potential culprits are gzipped already:
The good news is that most file requests appear to be automatically gzipped by Meteor / Galaxy. 
