press.js - yet another javascript compressor
in [JavaScript]
|
From: Stefan Weiss on 24 May 2010 14:03 On 24/05/10 19:39, Johannes Baagoe wrote: > David Mark : >> You can't just plop GZIP files on the server. You have to do content >> negotiation and would need two copies of each static file (one >> compressed, one not). I know how to do it, I just choose not too. > > http://httpd.apache.org/docs/2.0/mod/mod_deflate.html IIRC, they were discussing the case where the web server wasn't equipped or configured to do this automatically. But since you mention mod_deflate - do you know if there is a reason why neither this module nor the older mod_gzip will cache the compressed files? It seems wasteful to compress the same JS library over and over again for every new visitor. A pre-generated gzipped version could potentially take some of the load off the server. -- stefan
From: David Mark on 24 May 2010 14:41 Johannes Baagoe wrote: > David Mark : > >> You can't just plop GZIP files on the server. You have to do content >> negotiation and would need two copies of each static file (one >> compressed, one not). I know how to do it, I just choose not too. > > http://httpd.apache.org/docs/2.0/mod/mod_deflate.html > Thanks, I know about that (and other similar scripts) but my host does not run Apache. It is an on-the-cheap hosting service that I set up mainly to post examples to. I'm going to be switching soon now that I actually have something up there I want to promote.
From: Andrea Giammarchi on 24 May 2010 15:22 On May 24, 7:11 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > You can't just plop GZIP files on the server. You have to do content > negotiation and would need two copies of each static file (one > compressed, one not). > again, there is nothing to set up. The browser send the header if present (Accept-Encoding), the server read if it accepts deflate and/ or gzip, the server serves the raw binary file using binary transfer with length and all the necessary for a basic HTTP request as is a get over a *whatever* file ... end of the story, when the UA finishes the download it will decompress locally using the right algo provided by the server. The server in this case has *nothing* to do except send right headers, something it has to do in any case ... than if you have a single example that does not allow you to serve a binary file I'd love to see it 'cause to me there is no such case with all I have tried so far (but hey it's IT, you never know what people use). Finally, as Stefan Weiss already pointed out, there is no reason to compress over and over the same file and for each request, libraries are up to 1mb and more uncompressed, this means stress and this is why the project I have talked about is fast in the server almost like a plain text, and 2 up to 10 times or more faster than whatever handler you use (if you can) since there is *no* runtime compression plus the Etag is not generated runtime over a compressed version (again, no reason to compress runtime, *easy*, *simple*, *faster*, until somebody demonstrates it is not true with benchmarks, those I have already provided there ... but of course if somebody skip things ... Br, Andrea Giammarchi
From: David Mark on 24 May 2010 15:31 Andrea Giammarchi wrote: > On May 24, 7:11 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> You can't just plop GZIP files on the server. You have to do content >> negotiation and would need two copies of each static file (one >> compressed, one not). >> > > again, there is nothing to set up. Sounds like magic! > The browser send the header if > present (Accept-Encoding), Uh, yes... > the server read if it accepts deflate and/ > or gzip, the server serves the raw binary file using binary transfer > with length and all the necessary for a basic HTTP request as is a get > over a *whatever* file ... end of the story, when the UA finishes the > download it will decompress locally using the right algo provided by > the server. And you have to configure the server to do that, which my host does not allow. End of story (I hope). > > The server in this case has *nothing* to do except send right headers, > something it has to do in any case ... And you have to configure it to do the negotiation and send the appropriate headers. Additionally, for my host's setup, this would require using a CGI script for every static file. Again, I choose not to do that (and in fact, my host's setup would make this quite a mess to do). Instead, at some point in the future, I will simply move my static files to a host that supports GZIP negotiation out of the box. > than if you have a single > example that does not allow you to serve a binary file I'd love to see > it 'cause to me there is no such case with all I have tried so far > (but hey it's IT, you never know what people use). What the hell are you talking about now? > > Finally, as Stefan Weiss already pointed out, there is no reason to > compress over and over the same file and for each request, I never said there was. In fact, I mentioned that you would need two *static* files (one compressed and one not). A lot of the tools out there (as mentioned) inefficiently compress the file over and over. And I couldn't use any of them with my host account anyway.
From: Andrea Giammarchi on 24 May 2010 15:46
On May 24, 9:31 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > And you have to configure the server to do that, which my host does not > allow. End of story (I hope). > I stopped here ... hey ... psssssssssssssssss, the link you have skipped, provides everything via PHP, easy to reproduce the same serving logic with whatever other server side programming language, JS included. Have Fun skipping things setting up your server when it's not necessary ;-) Br, Andrea Giammarchi |