When you await a task on a UI thread, this blocks the UI thread from processing new tasks I.E. returning back the response to the caller (in this case the Browser).
[Rule of Thumb]: Do less on the UI thread mainly in the Controller Function that returns a View. This is your bread and butter in terms of performance and responsiveness.
If you are writing App Level Code DO NOT USE ConfigurerWait(false). This might cause problems when the tasks run a little longer than expected, as the Task will not return to the caller Awaiting the result or the Task will be scheduled to be run on a different thread but will not report back to the caller's Main Thread (UI thread) which might cause a bug.
On the other side, if Code does not need to be called back on and bind data to the UI component then it is safe to use the ConfigurerWait(false). This way, you are telling the RunTime to process the Task on a different Thread and never mind reporting back to the caller.
ConfigurerAwait(false) makes the code execution run faster as it is the same as Fire and Forget. In some cases, ConfigurerWait(false) might not be processed on a different thread, it might end up getting processed on the Main Thread (UI) considering how fast or overloaded the UI Thread is. In this case, then you should be okay to use ConfigurerWait(false). However, make sure you understand what it does before using it which might introduce a bug.
On the brighter side, use ConfigurerWait(false) in the Library (UI Agnostic) project that does not know of the Caller. This way the IO or Database bound request can be processed using an Async Await and even ConfigurerAwait(false) added to the request call.
I followed this programming paradigm and my code started to run faster. Leave a comment below if this is of any help to you.
https://www.ernestech.com/articles/details/1743
+1 888-688-2939 
