No--you have it backwards. The problem comes from delayed clicks, it won't be cured by delaying clicks. You click the spot you want and something more loads causing the control to move before the click is processed.

I'm not sure how to do it but the clicks need to be processed against the state of the display when the click was done rather than against the state when the click was processed. The only way to do this that comes to mind is to snapshot the hot zones on the screen before doing anything that will disrupt the screen and any click received during or within 300ms (configurable, I'm figuring a minimum reaction time) after the screen update should be processed against that map, not against the current state.