slow wal replay in backup postgres12 server
There must be a replication conflict with a query that prevents applying the changes to the data files.

Look into pg_stat_database_conflicts on the standby for details.

You probably have max_standby_streaming_delay set to a value greater than 0 and long running queries on the standby. Now if some action on the primary server causes WAL entries whose application would conflict with the running query, replay of these data modifications gets delayed.

You can try to minimize conflicts by setting hot_standby_feedback to on (at the risk of bloating your primary server's tables), but you'll never totally get rid of them.

It is difficult to have a standby that is both never delayed and supports long running queries at the same time. Better use two standby servers with different max_standby_streaming_delay if you need both. Of course, if you want the standby for scaling reads, you want both at the same time, and you are in a difficult position. Streaming replication is not very good for that.

You could also experiment with setting vacuum_defer_cleanup_age to a value greater than 0 to reduce the number of replication conflicts caused by VACUUM.