Lovable のアプリが、変更後に遅くなった
昨日までは普通でした。機能をもう1つ頼んで、公開したら、あるページに数秒かかるようになった — あるいは読み込み中のまま終わらない。エディタ上ではどこもおかしく見えず、エージェントに「もっと速くして」と頼むと、原因ではなかった部分が書き換わります。
なぜ見えにくいのか
Lovable のアプリには自前のサーバーがないので、いつもの答え — サーバーログを見る — には見るものがありません。実際に変わったのはたいていクエリです。エージェントがコンポーネントを書き直したついでに、フィルタが落ちたか、取得処理がリストの内側に移動したか。どちらもエディタでは見えず、どちらも例外を出しません。
見えにくいもう1つの理由は、書かれた時点では遅くなかったことです。プロジェクトに数件しか行がなければ一瞬で終わります。遅くなるのは本物のデータが後ろについてからで、それは原因となった変更よりだいぶ後になるのが普通です。
Sixty は何をするのか
ブラウザエージェントが、そのページの出す Supabase クエリをすべて計測します。何本出したか、そして各クエリが何行返したか。2回公開すれば2回目が1回目と比較されるので、検出結果は日付ではなくバージョンを名指しします。
得られるのは1つの文です — このクエリは30行を返していたが、いまは30,000行を返している。このページで、この公開以降。そして証拠はあなたが使っているエージェントに渡るので、修正は当て推量ではなく差分になります。
できないこと
最初の検出はすぐではなく、次の公開の後に届きます。バージョンが1つだけでは比べる相手がないからです。また、Lovable のプレビュー上で編集するだけでは足りません。プレビューは指紋付きのアセットを持たない開発サーバーで動くため、比較を固定できるバージョンが存在しないのです。
OpenTelemetry
OpenTelemetry をすでに使っていますか？
現在の Collector と exporter はそのまま使えます。Sixty は接続された trace と有用な runtime metric を取り込み、release regression を推論します。対応する native agent があれば、function と DB driver の詳細がさらに得られます。