Home/ Questions/Q 6182211
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T01:09:40+00:00

I sniffed some packets off my Google Chrome browser – and I found out

  • 0



I sniffed some packets off my Google Chrome browser – and I found out that:

  1. HTTP requests are send as text – actually sending ‘GET BLABLABLA’
  2. JS is received as text
  3. HTML \ images etc is transferred in some compressed method.

My question is – Why HTTP and JS is transferred without any compression ?

I think that a fully form HTTP request can be compressed to about 3 ~ 5 bytes not including cookies and given that page picking is also compressed (e.g site.com/thisisanicefile.html > site.com/ABC)

Also – why is JS transferred as plain text and not as an array of Tokens (programming languages are converted to an array of Tokens before execution – same goes for scripting languages) ?

Thanks – Mark

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    For HTTP: well, that’s how the protocol is defined. The protocol is text-based. Makes it simple to implement without having to worry about things like endianness.

    Contents (html, javascript, images, …) can be sent compressed, that’s a matter of encoding “negotiation” between the browser and the server (both need to support it). See the HTTP Compression page on Wikipedia for a run-down on how it works.

    Transferring JavaScript in a pre-processed form (some kind of bytecode) would require that bytecode form to be standardized and implemented in all browsers, and would provide very little benefit. The size difference versus compressed, minified JavaScript would likely not be stellar (after all, you’d be sending the same quantity of information, so a good compression algorithm should make the size of both practically identical).

    You’d also need to compile the JS code before you make it available on your webserver (one more build/deploy task), or compile it on the fly (CPU waste), and that wouldn’t prevent the need for a full-blown source code interpreter on the browser without restricting the language (no more eval / code generation on the frontend if it cannot process JS source).

    • 0