実装(4):パフォーマンス向上のための工夫

 連載第18回以降では家計簿アプリを題材に開発サイクルを回しながら、参照系アプリケーション開発で役立つ要素技術や、使い勝手向上のための観点について解説をしています。これまで実装したアプリの画面は図のようになっています。

図1●これまでに実装したアプリの画面
[画像のクリックで拡大表示]

 業務システムの場合は毎日何千、何万というデータが発生します。今まで作ってきたアプリがこのデータ量に耐えうるかどうか確かめてみましょう。ロジックの「明細一覧取得処理」のURLを下記のように書き換えてください。

getAccount: function() {
	return h5.ajax('http://localhost:8080/api/gethugedata');
},

(account-logic.jsのソースコード抜粋:明細一覧取得)

 この状態でアプリにアクセスしてみましょう。いかがでしょうか。表が表示されるまでに数秒の待ち時間がありました。表示された画面を見ると分かる通り、ロジックを経由して取得したデータの量が非常に多いために、パフォーマンスに影響が出てしまいました。

 毎日使う業務アプリにこそ、スムーズな操作が重要です。Webのユーザービリティ研究者であるヤコブ・ニールセン博士は、研究の中でWebページの反応時間について次のように述べています。

  • 心理的・感情的な違和感を覚えない限界は0.1秒まで。
  • 思考の流れが妨げられないのは1秒まで。
  • 注意力を維持する限界は10秒まで。

Response Times: The 3 Important Limitsより筆者訳)

 ユーザーが一般のWebサイトを見ている場合なら、サイトの反応が遅いと感じてもユーザーがページを閉じてしまえばそれまでですが、ユーザーがアプリを使って一日中作業をするような場合は、数秒のわずかな遅れでも、それが積み重なれば著しいユーザービリティの低下を招きます。

 さらに業務システムの場合は毎日何千、何万という処理が発生します。取り扱うデータ量が多くなるほど、その可視化処理のパフォーマンスには特段の考慮が必要です。

 「パフォーマンス」というとソースコードを極限までチューニングするようなイメージを持たれるかもしれませんが、過度なチューニングはソースコードの可読性を下げるため禁物です。ただし、クライアント側の処理がアプリ全体の性能のボトルネックとなることを避けるために 守るべき鉄則があります。

 今回のサイクルではパフォーマンスの問題に対処し、大量のデータを扱う際にも使いやすさを損なわないようアプリに改善を加えていきます。

この先は会員の登録が必要です。今なら有料会員(月額プラン)が2020年1月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら