Bubbleアプリが「重い」と感じても、最初の表示が遅いのか、検索が遅いのか、保存後の処理が遅いのかで原因は変わります。場面を分けて記録し、検索とワークフローを順に点検しましょう。
01再現条件を揃える
端末、ページ、操作、データ量を記録します。体感だけで設定を変えると、改善したかを判断できません。まず同じ条件で処理時間を測り、遅い箇所を絞ります。
02検索の回数と量を点検する
Bubbleの公式文書では、件数の多い検索、複雑な検索、頻繁に繰り返される検索が負荷につながり得ると説明されています。画面表示時に不要なデータまで読み込んでいないか、一覧の各行で別の検索をしていないかを見ます。絞り込み、読み込みのタイミング、データ構造の見直しに改善の余地があります。
03バックエンド処理も見る
APIワークフローやデータ変更をきっかけに動く処理は、利用者の画面が開いていなくても実行されます。再帰的な処理や重複するトリガーがないか、ワークロードの記録を見ながら点検します。ただし、負荷を減らすために権限確認や必要な処理を削るべきではありません。安全性と利用体験を保ったうえで改善します。
04改善の順番を決める
体感が遅い画面を一つ選び、表示までの時間、検索対象の件数、発生するワークフローを記録します。次に、不要な検索や繰り返し処理を一つずつ見直し、変更前後を同じ条件で比べます。複数の箇所を一度に変えると、何が効いたか分からなくなります。
利用者の待ち時間とワークロードの消費量は別の指標です。片方だけ改善しても運用上の問題が残ることがあります。データ件数が増えた場合や複数人が同時に使う場合も想定し、定期的に記録を確認できる体制を作りましょう。
05具体例：案件一覧だけが遅いときの切り分け
架空の案件管理アプリで、100件のときは速かった一覧が3,000件になってから遅くなったとします。まず同じ端末・回線・権限・検索条件で、画面を開いてから一覧が使えるまでを数回測ります。「詳細画面は速く、一覧だけ遅い」なら、一覧の検索対象と各行で呼んでいる検索を優先して点検します。たとえば各案件の行で担当者の別検索をしているなら、表示件数が増えるほど呼び出しが重なる可能性があります。
変更案は一つずつ試します。最初に利用者の部署や状態で検索対象を絞り、次に初期表示で不要な項目や件数を読み込まないようにします。変更前後で表示時間とBubbleのワークロード記録を同じ条件で比べます。単に表示件数を減らしても、裏で全件を取得していれば効果は限定的です。検索の制約とPrivacy Rulesが意図したデータだけを返すかも確かめてください。
「保存後だけ遅い」場合は別の原因です。保存をきっかけに動くバックエンドWorkflow、通知、外部APIを順に数えます。重複実行や再帰があれば止める条件を見直します。速度だけでなく、処理の失敗率と利用者の待ち時間も同時に記録すると、負荷を減らしたつもりで業務を壊すことを避けられます。
参考資料
内容は公開時点の公式資料をもとに構成しています。仕様は変更されることがあるため、導入時は最新の公式情報をご確認ください。