I believe that one form of "compression" is being overlooked and it's available in all editions of SQL Server... if the Clustered Index has no temporal-like key to match thee order of inserts of the key columns of the Clustered Index are updated on a regular basis, there will be a huge number of page splits. In such cases, simply rebuilding or reorging the Clustered Index (and the non-clustered indexes, as well. It's amazing how much empty space they can contain on systems that have no regular, proper defragmentation jobs going on.

So my first question before any other consideration would be...

Do you have properly written index defragmentation and stats update jobs running? If not, set one up, run it, and then look again.

As for the 20GB size of the table, that's actually pretty small, nowadays. I wouldn't worry about the actual size of the table unless, as I said, it has a huge amount of free space in the table caused by page or extent splits.