Most accurate way to measure the replica lag in RDS Postgres

I have an RDS instance with Postgres 13 as the DB engine. I also have a read replica created with the same instance class as that of the source database and configured my application to route the read traffic to the replica. Now when I see 'ReplicaLag' parameter in CloudWatch, it shows a delay of anywhere between 5 to 10 seconds, which is too high and is impractical for our solution. But if I insert a record in primary and do a select on that record within a second from the replica, I could successfully fetch the record. This means that the lag is not really 5 to 10 seconds? Then I came across this article from AWS where they state the following:

If no user transactions are running on the source DB instance, the associated PostgreSQL read replica reports a replication lag of up to five minutes. The replica lag is calculated as currentTime - lastCommitedTransactionTimestamp, which means that when no transactions are being processed, the value of replica lag increases for a period of time until the write-ahead log (WAL) segment switches. By default RDS for PostgreSQL switches the WAL segment every 5 minutes, which results in a transaction record and a decrease in the reported lag.

So this means 'ReplicaLag' metric is not trustworthy all the time. And yes, my use case does not involve too many writes, so it is a possibility that the replica lag I'm seeing with the above metric is not really a 'lag'. And the same article suggests me to rather monitor the lag from the DB level with the following SQL: SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";. But I always get NULL as the output and I am confused if it means that there is no lag or there's something wrong with the query.

I also came across OldestReplicationSlotLag in CloudWatch and that is always shown as zero.

I am in search of a straightforward and reliable metric that can give me a realistic picture of lag between my source and replica database.