API呼び出しなど、ネットワークを通じてリクエストを投げる・レスポンスを受け取るなどはコストのかかる処理で、呼び過ぎるとユーザーの回線に余計な負担を与える。また時間がかかるため、反応が遅いと感じられUXに悪影響を与えることがある。そのためどこでどう呼ぶかを考える必要がある。
呼ぶAPIの数の制限
例えばアプリなどで一画面で呼ぶAPIが多すぎると遅くなってしまう。そのため、1画面で呼ぶAPIは２〜３個までなどある程度基準を設け、一度に呼ぶAPI数が多くなり過ぎないように設計する。
回線状況の考慮
できれば、ユーザーがそのアプリ等を使う状況を考慮に入れ、通信回線がどのくらい良いかも念頭に置いておくと良い。例えば、電車の案内のアプリであれば、電車内とりわけ地下鉄など電波状況の悪い場所で使う場合もあることから、そのような場面であまり時間のかかる処理を入れるのは好ましくない。
APIを呼ばなくて済むのではないか検討
同じデータを取ってくるだけなのに何度もAPIを呼ぶのは無駄である。そのため、一度取ってきたデータをデバイスのメモリに一時保存、あるいはストレージに恒久保存して対処する事ができないかを検討する。
また一部のデータが欲しいだけなのに、多くのデータを取ってくるAPIを呼ぶなどもやはり無駄となる。
なるべく通信を節約しようとすれば、何度もAPIを呼ばずに既に呼んだAPIの結果をある程度使い回すなどの動作をする必要があり、プログラムが複雑になってくる。どこまでそうした動作をするかはプロジェクトの状況によって違うが、普段からそういう状況でどうコーディング・デバッグするか知見を積み重ねていく事が重要。
APIを呼んでいる最中の対応
APIを呼んでいる最中、UIまでも止まってしまう（タップとかクリックとかユーザーの反応を受け付けなくなる）とフリーズしたかのような印象をユーザーに与えてしまう。そのため、通信処理とUI処理のスレッドを分けるなどして対処する。
また、通信処理が終わるまでの間、100ms~200ms程度異常かかるようであればローディングの表示（グルグル回るアイコン、またはゲージが徐々に満タンに近づくバーなど）をするのが望ましい。この場合、通信の開始時にローディング表示を開始する。そして通信が成功しようと失敗しようと、通信が終了すればローディング表示を止めることになる。
参考
MdN Design -［優れたUXを目指して］アプリの性能について：第３回
Android Developers - Keeping your app responsive