Firebase共通でFlutterFlow・Flutter・Bubble・ReactのCRUD応答時間を比較してみた

FlutterFlowやBubbleを使った場合と、FlutterやReactでコード主体に実装した場合で、データ操作の体感速度はどの程度変わるのか。

実案件ではバックエンドやデータ量、画面構成がそれぞれ異なるため、そのまま比較することはできません。

そこで今回、Firebaseを共通バックエンドとして簡易的な検証用アプリを作成し、操作応答時間を比較しました。

この検証は、micomiaで実施した「UI/UXを軸としたアプリ開発方式の比較調査」の一部です。

調査全体では、処理速度だけでなく実務9事例の検収記録や運用時の課題なども分析しています。

詳細な調査レポートは以下から資料請求できます。

調査レポートの資料請求はこちら

比較した開発方式

今回比較したのは以下の4方式です。

• FlutterFlow
• Flutter
• Bubble
• React

比較の考え方としては、

モバイルアプリ

• FlutterFlow
• Flutter

Webアプリ

• Bubble
• React

という組み合わせです。

クライアント側でどの開発方式を採用するかによって、同じバックエンド・同じデータ操作でも利用者が体感する速度に差が出るのかを確認しています。

バックエンドはFirebaseで統一

すべての検証用アプリでFirebaseを使用しました。

検証用アプリは一画面のみのシンプルな構成です。

実装した機能は、

• テキストの登録
• 登録済みデータの一覧表示
• 編集
• 削除

です。

今回計測したのは以下の3操作です。

• Create
• Update
• Delete

Readについては、表示完了のタイミングを4方式で完全に同じ基準にすることが難しかったため、今回の測定対象から外しています。

計測条件

項目	条件
バックエンド	Firebase
ネットワーク	同一の会社Wi-Fi
計測対象	Create / Update / Delete
計測回数	各方式・各操作5回
計測方法	手動

今回はあえてすべて手動計測としました。

FlutterFlowやBubble側にも計測用のコードや処理を追加することはできます。

ただし、それぞれの環境へ独自の計測処理を実装すると、

そもそも計測処理自体が同じ条件になっているのか

を検証する必要があります。

今回は方式間で計測条件を揃えることを優先し、すべて同じ方法で計測しました。

そのため、本検証は厳密なベンチマークではなく、簡易的・探索的な比較として見てください。

計測結果

各操作5回の計測を行い、中央値を比較しました。

方式	Create	Update	Delete
FlutterFlow	0.96秒	1.03秒	0.98秒
Flutter	0.106秒	0.085秒	0.086秒
Bubble	0.86秒	0.89秒	0.88秒
React	0.128秒	0.122秒	0.102秒

今回の条件では、

• FlutterFlow / Bubble：おおむね1秒前後
• Flutter / React：おおむね0.1秒前後

という結果になりました。

FlutterFlowとFlutter

モバイルアプリ側では以下の結果でした。

操作	FlutterFlow	Flutter
Create	0.96秒	0.106秒
Update	1.03秒	0.085秒
Delete	0.98秒	0.086秒

今回の条件では、すべての操作でFlutterの方が短い応答時間になりました。

BubbleとReact

Web側では以下です。

操作	Bubble	React
Create	0.86秒	0.128秒
Update	0.89秒	0.122秒
Delete	0.88秒	0.102秒

こちらも、今回の条件ではReactの方が短い応答時間となりました。

同じFirebaseでもフロントエンドによって差が出た

今回確認したかったのは、Firebaseそのものの処理速度ではありません。

すべて同じFirebaseを利用した状態で、

フロントエンド側に何を採用するかによって、操作開始から画面へ結果が反映されるまでの時間が変わるか

という点です。

今回の簡易的な検証では、その差を確認することができました。

CreateやUpdateを1回だけ行うサービスであれば、1秒程度の待ち時間が大きな問題にならない場合もあります。

一方で、

• 記録アプリ
• チャット
• 業務システム
• EC
• SNS

など、ユーザーが何度もデータ操作を行うアプリでは、小さな待ち時間が積み重なります。

その結果、

機能としては動いているけど、なんとなく重い

というUXにつながる可能性があります。

この数値だけで各プラットフォームの性能は断定できない

今回の結果にはいくつか注意点があります。

• 各操作5回のみ
• 手動計測
• ネットワーク環境は1種類
• 簡易的な一画面アプリ
• 端末・ブラウザ条件を広く比較していない
• Readは対象外
• 初回接続などの影響を完全には除外していない

そのため、

FlutterFlowはFlutterより必ず○倍遅い

あるいは、

BubbleはReactより必ず遅い

という一般化はできません。

あくまで、

同じFirebase・同等の簡易機能という条件でも、フロントエンドの実装方式によって操作応答時間に差が生じるケースがある

という一つのデータです。

なぜこの検証を行ったのか

micomiaでは、FlutterFlowやBubbleなどで開発されたアプリを、Flutterやコード主体のWebフロントエンドへ移行する案件にも関わっています。

実際の案件では、機能面だけではなく、

• 操作時の待ち時間
• データの反映
• 状態管理
• エラー処理
• 外部サービス連携
• 保守性

などが移行理由になるケースがあります。

ただ、実案件だけでは条件が異なるため、

単純に開発方式の違いなのか

を比較できません。

そこで今回、Firebaseと機能をできる限り揃えた簡易アプリを作成して検証しました。

実務9事例についても調査しています

今回の処理速度検証は、より大きな調査の一部です。

micomiaでは、実際に開発・移管・保守・改修に関わった9事例について、

• ノーコード・ローコード
• コード主体開発
• AI支援型コード主体開発

を比較しました。

調査では、

• 検収時の不具合
• UI/UX
• 運用品質
• コード主体への移行
• 保守・追加開発
• 操作応答時間

などを整理しています。

詳細な調査結果について

調査内容は、

「UI/UXを軸としたアプリ開発方式の比較調査」

としてレポートにまとめています。

レポートには今回の記事では省略した、

• 実務9事例の分析
• 検収時不具合の集計
• 不具合カテゴリ
• ノーコード・ローコードからコード主体へ移行した事例
• AI支援型コード主体開発
• 操作応答時間の全計測データ
• 開発方式の判断基準
• 調査上の限界

なども掲載しています。

顧客案件に関する内容を含むため、全文は一般公開していません。

詳細をご覧になりたい方は、以下から資料請求をお願いします。

「UI/UXを軸としたアプリ開発方式の比較調査」を資料請求する

micomia株式会社
https://micomia.com/