Next.js: Serve .gz versions of static files in production

Created on 17 Mar 2017 · 9Comments · Source: vercel/next.js

Compression Plugin allows you to pre-compress your bundled assets. It'd be nice if next.js automatically served those compressed bundles if the browser accepts gzip encoding.

Source

phallguy

Most helpful comment

The reason is simple. There are multiple types of compressions algos we can choose. And they have different settings as well. So, we need to support it some day.

Anyway, most of the time you'll route your traffic with a proxy like nGinx. So, they can do a better job with compression. And we've a ton of CDNs to that as well.

Even that's not the case, you could do it yourself.

We removed it because this will add more options to Next.js. But we could easily do those stuff outside of Next.js.

arunoda on 17 Mar 2017

👍4 😄1

All 9 comments

This feature was removed (https://github.com/zeit/next.js/issues/984)

sergiodxa on 17 Mar 2017

Seems like an odd choice given that the server is already serving static assets. We're running in a docker cluster and we could put an nginx proxy in front of it but that seems like a bit of overkill for what should be a few lines of code. Totally get the desire not to do it on the fly but whats the motivation for removing support for already compressed assets?

phallguy on 17 Mar 2017

👍1

I think the static server is for development usage, in production the recommended way is to use a CDN to serve statics and you can use it to send your assets gzipped 🤔

sergiodxa on 17 Mar 2017

For sure, CDNs are great solutions for many. In our particular build pipelines the container is the source of truth and represents the entire app - self contained. We may look into CDNs down the road but for now its more infrastructure than we want to support and automate. One of the draws to next.js is that it just works and requires minimal setup. Would love to be able to just put the node server behind a load balancer (HA proxy in our case) and let it run. I've done the nginx proxy before but really don't want to go through the hassle for the scale of project we're working on. Lack of support isn't a deal breaker but something that seemed natural and was surprised to find it wasn't already supported - even more so that it was intentionally removed.

phallguy on 17 Mar 2017

👍1

Maybe @arunoda can explain you better the reasons to remove the gzipped files 🤔

sergiodxa on 17 Mar 2017

The reason is simple. There are multiple types of compressions algos we can choose. And they have different settings as well. So, we need to support it some day.

Anyway, most of the time you'll route your traffic with a proxy like nGinx. So, they can do a better job with compression. And we've a ton of CDNs to that as well.

Even that's not the case, you could do it yourself.

We removed it because this will add more options to Next.js. But we could easily do those stuff outside of Next.js.

arunoda on 17 Mar 2017

👍4 😄1

I agree with @arunoda compression is out of the scope of this project, booting a nginx proxy in front of node is really really simple, probably only twice the time it took you to write that post. More so in a Docker environment. Also you should be running a forward proxy in front of node anyway.

andrewmclagan on 7 Apr 2017

Hi,
I think issue about compressing on file system is ligitimate. Next.js doens't allow any way how to extract assets and compiled app.js file outside its structure.

Anyway all request handled by middleware are gziped on-demand with every request. Better and more performant way is to have prepared and gziped files already in filesystem (JS, CSS, HTML, SVG, JSON and other string based files).

This great webpack plugin.
https://github.com/webpack-contrib/compression-webpack-plugin
It takes all builded sources and what is able to gzip it could be gziped. On file system, no need to overhead CPU.

Then we can serve it from file system faster than they could be generated on-the-fly. CDN systems are complicated and often for medium-sized pages from 30 000 to 100 000 visit per month not necessary if is everything prepared as should be.

After pregenerating static assets with gzip compression we should use very easy directives defined in middleware like:

Nginx

location /static/ {
  gzip_static on;
}

or another solution is using https://github.com/tkoenig89/express-static-gzip

Issue about this is NEXT.js serving static files two different ways. Compiled app.js file is moved into distribution builded directory and served always with unique path (eg /_next/2dbe35280fd609034099731f9be7e91e/app.js) no way how to send pre-compressed file. On the other hand static files are routed from original directory. There is no way how to pre-gzip them outside static directory.

Possible solution: In distribution directory should be common folder for all assets (scripts, styles, images etc) and all of them could be server within one path.
This path can be handled easily by any middleware.