Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

webpack gzip vs express gzip

I really wanted to know differences between webpack gzip and express gzip

I've used only express gzip by using compression package. Like this,

app.use(compression());

But seo analyzer says that I can compress javascript files more, although I can see Content-Encoding:gzip at chrome devtools console of my homepage. So I started to search ways to compress files and I found compression-webpack-plugin package which makes gzip files. I already use webpack but not compression-webpack-plugin. I'm thinking about adding this plugin if it helps compressing my files more.

The questions are

  1. Do I need both express and webpack gzip packages, or just one?
  2. What's the difference between webpack gzip and express gzip?
like image 785
ZeroCho Avatar asked Jul 26 '16 10:07

ZeroCho


1 Answers

The difference is that Webpack compression will compress your files one-time - during your build run. Those compressed versions are then saved to disk.

Express plug-ins, on the other hand, will compress your files at the point of request. Certain packages may have caching built-in so that the performance penalty occurs only once (or infrequently), but generally the difference is that this will occur in at the point of responding to the HTTP request.

For real-time zipping, it's usually more performant to let an upstream proxy (such as Nginx) handle gzip and caching, because they're built specifically for that and don't suffer the overhead of the Node runtime (many are written in C).

Another solution is to let Webpack compress your files and create .gz versions of your uncompressed files. A package such as express-static-gzip can then serve those pre-compiled versions, so you're not taking the performance hit of gzipping at the point of request. This is useful if Node.js is directly responding to your HTTP requests and you're not using an upstream proxy/load balancer.

The benefit to using Webpack is that you can use maximum compression settings (or an algorithm that takes longer to crunch the files) because you probably don't care about a few extra seconds on your build process, yet that same time tacked on to serving your HTTP visitor by enabling more complex compression would be a bigger deal.

like image 196
Lee Benson Avatar answered Sep 30 '22 10:09

Lee Benson