Just to clarify, super computing on server side can benefit download speed by finding optimum compressed form, while on client side typical processing power is needed to decode. The more times people download the same thing the more useful a good compressed form becomes.

This is just a mini example:

By default this string of data reserves an introduction, even if encapsulated by typical internet jargon. The first bit, says yes this is encoded or no this is pure data. Then the next 7 bits, signify what encoding to use. Then based on this various groups of formulas, functions and data forms can be selected to encode broken up pieces of the data in question.

Here is a sample data string:
10101110001111010011010101011100010010011100011111001000101111010110010010100101110001

Here is the encrypted form:
1 1001 01101 1011 0010 0110 / 110 100 111 101 100 101 (11000111) 001 010 110

(Ok, I'm doing this by hand and I have not changed the original data string. I also am trying to consider likely algorithms, when only 512 are available. So far I have not had time to hand create some formulas that will work. But with ingenuity I bet I could condense the above data string to this shorter one, or shorter.)

1 yes encode
1001 super method 9
01101 use break-method 13 (other codes may have other schemes)
1011 variable, 4 bits = 11 (total of 10 bits so far)
0010 m is 2 a = func(var) where var is next 3 bits
0110 n is 6 b = (pos) mod 4

Don't even bother reading thru this, but it shows my thinking

We choose (scheme 13, of super 9):
3 at time (8 for pure data)
l=126 sized sub-section
x*x-8x-4 are pure data/rest use variables
use functions/schemes based on section n
where n = 11 (four bits)
Section 11, has 16 formulas
Section 11, assumes two are wanted (next, 8 bits)
function m(n(var))
if var is 111, then
use last val plus 1, do again + 2, again + 3

What function m and n might look like

Function m = var * 7 + (var^2+2*var mod 3) + b, where b is secondary function, var is compressed data
Function n = x mod 4, position is x

This process has taught me about the math involved. Basically in the beginning, one chooses between millions of algorithm groups (having more smaller groups), possibly more than once, and then takes each group and combines them indexed, then chooses in smaller sections of the original data which groups and then inner-groups to use. The more data one begins with, the more likely to find a somewhat random combination of compression algorithms, which will match cascading ever smaller sections.