Railsアプリでボトルネックになっている処理をajaxを使って改善した話

今日もRailsネタです。

私が運営している上場企業サーチ.comでは、各社のページを表示する際に非常に時間がかかることが課題になっていました。

ボトルネックになっている箇所はわかっており、これまではフラグメントキャッシュを使って対応していたのですが、 冷静に考えると、そのページに最初にアクセスしてくれるお客様(ユーザ)に一番失礼な対応(遅い!)をしてしまうという、サービス業としてあるまじき行為をしていることに罪悪感を感じましたので、サービス品質向上のため、実装を見直すことにしました。

改善前の実装

下の図が、改善前の実装です。 とはいっても、ごく普通のWebアプリの通信構造です。

f:id:boost-up:20171216173531p:plain

APの処理、DBの処理いずれもボトルネックがあり、最初のユーザにレスポンスを返すまでに1秒(1,000ms)以上かかることもありました。 キャッシュの有効期間中であれば、2人目以降はそれほどストレスなく表示できていたはずですが、 最初のユーザは遅さに耐えられず、途中で離脱してしまってるケースも多かったのではないかと思います。

改善後の実装

下の図が改善後の実装です。 ポイントは、最初のリクエストの際に重い処理を除いた状態で処理した結果を返すことで、ユーザは早期に画面操作を開始することが可能になる点です。

f:id:boost-up:20171216174129p:plain

今回はAP、DBの処理自体には基本的に手を加えていませんので、①~⑧までの処理全体に要する時間は殆ど変わらないのですが、 これまでと違い、④が終わった時点でユーザは操作を開始することが可能になるため、体感的に「遅い!!」というストレスは緩和されるはずです。

ユーザがページの閲覧を開始している裏側で、追加の情報を取得しに行くため、 ④の処理の完了をトリガーにajaxによるgetリクエストを発動させるようにしています。

ユーザには処理が完了するまでの間、モーションgifのぐるぐるを見ながらお待ち頂き、 処理が完了したらモーションgifを削除し、取得したデータに差し変わるようになっています。

f:id:boost-up:20171216175636g:plain

ユーザビリティは、まだまだ改善の余地がありますので、これからも継続的に対応を進めたいと思います。 抑々、今回の対応ではAP、DBの処理自体の課題はそのまま残っているため、これはこれで調査と対応を進めたいと思います。

今回は実装部分は記載しませんが、興味がある方がいらっしゃるようであれば追記したいと思いますのでご連絡ください。

おまけ

画面読み込み中の時によく見かける今回のモーションgifについて、今のようなITリテラシを持っていなかった頃は、このモーションgifが表示されている間は「処理中である」と信じて疑っていませんでした。

もちろん、そう思わせることでユーザのストレスを抑えることが狙いなのですが、実際のところは、正しい結果が返ってくる保証がない中で、結果が返るまで1つの画像ファイルを表示しているに過ぎず、来ないかも知れない相手を待ち続けているような状況だと知ったときには、少しだけ裏切られた気持ちになったのを覚えています。

「もう少し待てばきっと来るはず」

相手(ユーザ)の期待を裏切ってはいけませんね。