A bit confused about Gzip compression (for my web app)

user_11494981 0
Viewed 62

first of all please excuse me for my very dummy question, but I could not find an exhaustive explanation on it. I've created a web app with React, and I've used a NPM plugin to generate both standard and Gzip compressed versions of the main.js and main.css files (originally the main.js was 1.2 Mb, with Gzip compression is around 331Kb).

So know in my "dist" folder I have:

  • Index.html (that by default load standard - not compressed - main.js and main.css )
  • main.js
  • main.css
  • main.js.gz
  • main.css.gz

Well, what should I do know?

  1. I thought I had to upload everything on my server, and modify the Index.html, so that it loaded the .gz files in place of the standard ones... but NOT! If I edit the Index.html, so to point to the gzipped files, I get an error "Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "application/x-gzip"

  2. With my big surprise, checking on the Network tab of the Chrome develop console, I can see in the response header of Main.js "Content encoding: gzip", and its size is 343Kb... It's not the same size as "my" compressed file, but it's not too far

So, my big question: what's going on? Does my server is automatically creating gzipped versions of my .js and .css files (it should seem like that...) ? If so, where these versions are stored? Are them created on fly from scratch each time someone request them (??) And, if so, what is the use of creating gzipped versions of the Main.js and Main.css files? What should I do with them?

Many thanks for helping me understand something!

npm gzip javascript
1 Answers

The key thing here is the difference between the Content-Type and the Content-Encoding.

The absolute basics of HTTP are that the browser makes an HTTP request for a URL, and then the server decides how to response to that request.

That decision could be to so all sorts of different things, but the most basic is to look on the hard disk for a path that matches the URL path and give that to the browser along with a Content-Type that says what it is.

So if you ask for /foo.css it — and we're still talking about a basic approach — will give you the content of that file and a Content-Type that says it is CSS. While if you ask for /foo.css.gz then it will give you the content of that file and say it is a GZip file.

A GZip file isn't CSS so the browser then refuses to treat it as a CSS file. It doesn't expect to be able to extract CSS from it.

A slightly smarter approach would be to compress the file. So the browser asks for /foo.css and the server responds with the of foo.css but it compresses it first and it sends the compressed result back with a Content-Type that says it is CSS and a Content-Encoding that says it is GZipped.

The browser then knows that it can decompress it and extract the CSS.

(There's some additional complexity where the browser tells the server if it supports compression or not, but I won't go into detail about that).

Now the next level of complexity is if you want to save the resources needed to compress the CSS file on-the-fly (which would need it to either be repeatedly compressed or cached).

The browser asks for /foo.css and the server sees that there is a foo.css on the disk but also that there is a foo.css.gz next to it. It then sends the latter back with the Content-Type that says it is CSS and a Content-Encoding that says it is GZipped.

The server you are using appears to support and be configured to do the second of those three approaches rather than the most complex.

Dorward_190680
Related