Shrinkdb is a lot of I/O. It moves a page from the end of the file to a free space. Then all pages with references to this page must be updated, and the allocation table must be updated. All these page changes must be logged. If the database is in use locking can stall it.
After shrink db all indexes are fragmented and should be rebuilt.
removing from AG should have little impact on the shrink, but the shrink causes lots of log records, network traffic and the secondary may fall behind.
you can speed up a shrink by dropping as many indexes as possible, and of course single user mode would prevent any blocking.