Row Compression in AlwaysOn Availability Groups
Compression is not listed as a restriction in the documentation at Prerequisites, Restrictions, and Recommendations for Always On availability groups, so that is the official reference that indicates it is supported with availability groups.  There are no special considerations for configuration, and it does not matter whether synchronous or asynchronous replication is used.

Row and page level compression will have no direct impact on availability groups as far as functionality is concerned, but there will be a small increase in CPU utilization on the primary server to compress the data when written, and uncompress when read, so it's possible that extra resource usage could impact availability group replication as it also requires CPU.  In general, though, if your system has adequate CPU this will be of no concern.  Additionally, if the secondary is used for reading, additional CPU will be used to uncompress the data.  Again, the CPU required to do this is quite minimal and will only be of concern if there are other factors causing the CPU utilization to be excessively high.

The replication process is simply copying transactions from the transaction log to the secondary servers (to oversimplify it a bit), so it really doesn't know or care about what data is actually in that transaction.  When the log record gets to the secondary, it is placed in the transaction log there and committed to the database just as if the transaction had originated locally.

If the replication process had to understand the contents of every transaction that is replicated, whether the data is compressed, encrypted, or whatever, it would be far slower.