Code review that improves rather than delays
Size
A merge request of two hundred lines gets real comments; one of two thousand gets “looks good.” Split. If you can't split, write a recommended reading path in the description.
What to comment on
Correctness, edge cases, security, performance in sensitive spots, and clarity for whoever reads it in a year. Style, spacing and import order — for an automated tool, not a person.
Phrase comments as a question or suggestion, and mark what's a blocker and what's just opinion. “Blocker: this allows access to another user” is clearer than a polite hint.
Response time
A review that waits two days stops people and produces long branches. Set a norm — say, respond within half a day — and treat it like any team commitment.
Going deeper
Add to the review checklist items hard to enforce automatically: was a test added, is the change backward-compatible, was documentation updated, and what happens on failure. Those four questions catch most of what's forgotten.