Right now, CPUs are fast enough that LZMA is a realistic prospect. It boils down to what the extra CPUs will cost vs the cost of the storage saved (incl. the "cost" of space in the datacentre, the administrative overhead of more hardware, etc).
This could be achieved by using Javascript and fetching data as JSON, but it seems to be something that would be very useful and beneficial if it were standardized.
The server supplies a pre-created dictionary (template) which gets cached, and further requests get a diff to that dictionary as a response.
I've only found Google search using it on the server side, and the browser penetration is fairly low, but it seems promising. It makes requests very fast.
I've also noticed that Google search serves image thumbnails as data:// URLs directly in the original response. They are going a long way to ensuring each page loads entirely in one request.
Really expensive algorithms aren't that much better to offset cost of sending template logic to the client.
You could probably save some processing time by integrating compression directly into server-side templating - take advantage of the fact that some parts never change and keep them pre-compressed or at least cache some statistics about them to aid compression.