Minify and GZIP responses automatically

[Amy Boyd]

I wanted Play to GZIP/minify responses, so I coded that and made a
pull request on GitHub:
https://github.com/lights51/play/tree/response-optimization
http://play.lighthouseapp.com/projects/57987/tickets/861-play-should-automatically-gzip-responses-and-minify-htmlxmlcss-github-pull-request

Bandwidth use is down 66% across my sites. I'll commit more "response
optimization" code soon.

[Erwan Loisant]

There's already the greenscript module for compression, not sure if we
want to have that in the core?

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Erwan Loisant

[abp]

Why not? It's one of the most missed things in web development.
For example: http://www.stubbornella.org/content/2010/07/01/top-5-mistakes-of-massive-css/

Also there already were complaints about whitespaces, generated by the
template engine when using loops or conditions.

This looks, at a first glance, like a better integrated solution then
greenscript, too.

On 23 Mai, 11:35, Erwan Loisant <elois...@gmail.com> wrote:
> There's already the greenscript module for compression, not sure if we
> want to have that in the core?
>
>
>
>
>
>
>
>
>
> On Sun, May 22, 2011 at 14:00, Amy Boyd <a...@amyboyd.co.uk> wrote:
> > I wanted Play to GZIP/minify responses, so I coded that and made a
> > pull request on GitHub:
> >https://github.com/lights51/play/tree/response-optimization

> >http://play.lighthouseapp.com/projects/57987/tickets/861-play-should-...

[abp]

Also, it was requested by you?

https://github.com/playframework/play/wiki/Google-Summer-of-Code-2011-ideas

"Implement support minifying and concatening Javascript/CSS files"

On 23 Mai, 12:24, abp <adr...@needful.de> wrote:
> Why not? It's one of the most missed things in web development.

> For example:http://www.stubbornella.org/content/2010/07/01/top-5-mistakes-of-mass...

[Guillaume Bort]

For now it is better as an external module.

--
Guillaume Bort, http://guillaume.bort.fr

[Dirk]

These are different things. What greenscript (and press) do is minify javascript and css. Gzip compression is a separate process that in my opinion is best done by the web server, rather than the web application.
I'm not sure about greenscript but press will actually break if template output is gzipped by the web application.

On the other hand Play is designed to act as both web app and web server, and it would be nice if the web server part supported gzip compression. I think it would be best if this were independent of the modules so that it doesn't interfere with their operation (for example press searches the response for certain special tags, which will be garbled if the response is gzipped).

So I think if it is added, it should be part of the core, not a module.

[Tony Nelson]

As an alternative, I frontend my app with Apache and use mod_pagespeed

http://code.google.com/speed/page-speed/docs/module.html

[indrek]

Any advancements in this? As I can see on github, it was proposed that
it should be created as an external module.

Any suggestion for now how to implement gzip compression and also
cache the compressed data for a few seconds? I've got a single large
landing page that would be nice to have compressed, but on
playapps.net the frontend proxy is not configurable...

Indrek

[Erwan Loisant]

Hi,

On Wed, Jun 1, 2011 at 20:43, indrek <ind...@gmail.com> wrote:
> Any suggestion for now how to implement gzip compression and also
> cache the compressed data for a few seconds? I've got a single large
> landing page that would be nice to have compressed, but on
> playapps.net the frontend proxy is not configurable...

This is actually something we should fix on playapps.net, not in the
Play Framework: we should configure all frontends to gzip by default.
We'll do it eventually but I don't know when.

--
Erwan Loisant

[Amy Boyd]

> This is actually something we should fix on playapps.net, not in the Play Framework

I'm genuinely curious why you don't want to add GZIPing to the framework. The pull request I made allows you enable/disable GZIP in applicaion.conf, so surely no harm is done by including it. 

[pablo72]

I agree that it would be an useful feature implemented by the framework or as an external module. 

Cheers,

Paolo

[si]

Hi Amy,

I think the problem is not the initial commit, but the responsibility
of maintaining the code in time (kicked to play developers) as
Guillaume said before in a similar thing. I think this is the reason
why they want as a module.

My Best
Serdar

[R. Rajesh Jeba Anbiah]

Anyone knows if it's available as external module? (Looking for good gzip solution for 1.2.4)

On Saturday, 4 June 2011 00:16:18 UTC+5:30, si wrote:

Hi Amy,

I think the problem is not the initial commit, but the responsibility
of maintaining the code in time (kicked to play developers) as
Guillaume said before in a similar thing. I think this is the reason
why they want as a module.

My Best
Serdar

[Marcel Klemenz]

I now this topic is really old, but high rated on google, so i want to add an answer.

For everyone looking for htmlcompression and gzipped responses have a look at minifmod.
Next version will add support for transparently gzipped and minified assets, too.

[Guillaume Bort]

It's also way easier to do that at the reverse proxy level.

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/VvkIhE3F8fEJ.

[Marius Soutier]

Could you please elaborate on how to do that for Play 2.0? I've enabled compression on lighttpd but it only compresses static files, not content served by Play.

[Marcel Klemenz]

You are right but please consider that some people would like to do this with play itself. I use a reverse-proxy and like you said gzipping is faster this way.

[Eric Jain]

On Thursday, September 6, 2012 9:05:31 AM UTC+2, Guillaume Bort wrote:

It's also way easier to do that at the reverse proxy level.

I'm running Play on several machines behind an EC2 Load Balancer (ELB). ELB doesn't do gzipping, so you'd have to set up a reverse proxy on each machine just for the gzipping... Same problem if you want to serve assets via a CDN like CloudFront.

Having good support for things like this is just as important when building Internet-scale applications as Play's async features are.

[Sean Brady]

I'm running the same configuration, so +1

:-)

--
You received this message because you are subscribed to the Google Groups "play-framework" group.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/FkwXj19KFEEJ.

[Ike]

You may consider replacing Amazon's ELB with and modest EC2 instance running HAProxy or nginx. It's not as simple as setting up ELB but much more powerful.

On Friday, September 7, 2012 11:11:33 AM UTC-4, Sean Brady wrote:

I'm running the same configuration, so +1

:-)

On Sep 7, 2012, at 9:48 AM, Eric Jain <eric...@gmail.com> wrote:

On Thursday, September 6, 2012 9:05:31 AM UTC+2, Guillaume Bort wrote:

It's also way easier to do that at the reverse proxy level.

I'm running Play on several machines behind an EC2 Load Balancer (ELB). ELB doesn't do gzipping, so you'd have to set up a reverse proxy on each machine just for the gzipping... Same problem if you want to serve assets via a CDN like CloudFront.

Having good support for things like this is just as important when building Internet-scale applications as Play's async features are.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/FkwXj19KFEEJ.

To post to this group, send email to play-f...@googlegroups.com.
To unsubscribe from this group, send email to play-framewo...@googlegroups.com.