buenas.
hay que analizarlo en varias partes, pues muchas cosas pueden pasar desde la compresion, envio, y recuperacion de los datos.
lo primero que tienes que comprender es el algoritmo de compresion en si y la naturaleza de javascript. los algoritmos de compresion (cualquiera que sea) juegan mucho a nivel binario. inicialmente, javscript no fue diseñado con la habilidad de manipular binarios de forma amena. de modo que la unica forma de poder visualizar el contenido binario son con los strings (cadenas).
segundo, no es lo mismo medir la longitud de caracteres en un string que la longitud de bytes que esta compuesto ese mismo string. por ejemplo, el string 'ካ' esta compuesto de un solo caracter, pero en realidad consume dos bytes. esto ultimo se debe mas bien porque internamente javascript maneja los string en UTF-16.
Código:
console.log('ካ'.length); // 1
console.log('ካ'.charCodeAt(0).toString(16)); // 12ab, cada dos digitos hexadecimal es un byte. 0x12, 0xAB
tercero, la forma como transfieres el string de un lugar a otro. diferentes mecanismos de comunicaciones tienen diferentes limitaciones. HTTP tiene dos formas (al menos son las unicas que conozco) de como codificar la informacion antes de ser transferrido al servidor: urlencoded y multipart. esta codificacion son necesaria debido al metodo de envio (GET y POST). comunmente, la data se envia formando una URL que a su vez tiene que cumplir por las normas de cómo se construye una URL. si un caracter de la data conflige con la sintaxis de la URL, ya sea porque hay un caracter especial o porque se sale del rango del charset, se tiene que transformar a un equivalente. esa transformacion implica que la longitud de bytes final sea mayor al original y por ende resulta impractico para datos realmente grande. por ese motivo existe multipart, la informacion binaria se envia tal cual es utilizando un esquema distinto (payloads). para efectos tuyo, desconozco si se puede enviar el string comprimido como multipart en ajax.
cuarto, la data en el servidor puede sufrir otra manipulacion dependiendo lo que hagas con el. mas aun, el metodo en que solicites ese dato en el cliente puede sufrir otra transformacion. por ejemplo, si haces una peticion ajax con GET, el string puede resultar mas largo. nuevamente por las limitaciones en la sintaxis de URLs. de modo que la compresion en el lado cliente perderia sentido y utilidad. en este caso quizas sea conveniente que en el servidor apliques algun metodo de compresion a las respuestas de las peticiones, por ejemplo gzip o deflate.