If I do an INSERT, UPDATE or other dml out of an application and immediately after the result with a SELECT, the newly updated entry is not displayed correctly.
That is correct. If the most up-to-date data is required, then you'll need to query the primary replica. This also goes for transactional replication in whatever form you're using (strict TR, P2P).
My suspicion is that the replication on the secondary is simply too slow.
Could it be slow? Maybe. However it's also "by design", whether people like that design or not, that there is latency in the process. Maybe one day I'll write something walking through it, but until then, I've been consistently updating the docs.
Specifically, the anchor linked to above was put in a while ago in response to these questions. We've had a few requests for a new type of synchronization which would be "don't move on until the transaction is replayed on the/all secondary replicas". You can imagine the insane amount of latency for that in any cloud environment and most if not all on-prem environments as most I see are using slow SANs, underwhelming networking, and undersized cpu/memory.
Implementing read-only access to secondary replicas is useful if your read-only workloads can tolerate some data latency. In situations where data latency is unacceptable, consider running read-only workloads against the primary replica.
Can it be because of the latency for hardening the log?
Shrugs. Could be.
There are a plethora of factors here. A simplified overview of the workflow is the first link that @Aaron Bertrand has in his comment (which is a great link). Hardening and Redo are decoupled. This also doesn't take into account version of SQL Server, load, hardware, serial/parallel redo, etc., and thus it'd need data to be captured which is also non-trivial for a Q&A site. Additionally you'll need to cut the data up, which is also non-trivial, it's why there isn't an easy right-click menu in SSMS to do it.
How can I speed it up completely?
Accept that it's not possible to "completely" speed it up. Depending on the size of the transaction and various other items I've eluded to previously, you might be able to get it redone and visible within 10s of milliseconds, but it wouldn't be instantenous.
