If I understand correctly, you would like to try this in order to have the update packets flow faster and prevent race conditions that would lead to conflation.
BTW, did you try the experiment with the <sendbuf> setting?

I confirm that compressing the values may have an effect and, in fact, in the case of your data, according to your logs, it seems quite redundant.
But perhaps, instead of compressing it, you may try to remove the redundancy at the origin.
In fact, I see many \\u003d parts in your update values. This is a unicode representation of the = symbol.
It is not clear to me how they are quoted, but perhaps they can be quoted in a shorter way.

Lightstreamer itself uses several techinques to reduce the bandwidth needs.
If you leverage different fields to separate the various parts of your updates, then you can take advantage of the delta delivery feature, which, in many cases, reduces the size of the updates.
On the other hand, if you use the json representation and cannot leverage fields, you could take advantage of the support for sending deltas in the jsonpatch format.
For big fields of generic type, there is another kind of reduced delta, based on the "diff-match-patch" algorithm.
These jsonpatch and diff-match-patch diffs require Server version 7.3 or higher and also compliant client SDKs.
Note that they can be more or less effective depending on the form of the various updates.
For this reason, they are not applied by default, but by configuration. We can expand if needed.

Only if deltas cannot be used, there is the possibility to apply a zlib compression to the whole data in transit.
At the moment, this is not available for websockets, but only for http streaming, which, hence, should be enforced.