デバイス上でアプリによって取得または更新されたデータは、AppSheet サーバー経由でクラウド プロバイダに送信する必要があります。変更は（正確を期するために）連続的に行う必要があるため、この処理は同期プロセスの中でも特に時間を要するものとなり得ます。概念的には、このような同期パフォーマンスの妨げを改善する方法として以下の 4 つがあります。
- 更新の回数を減らす
- 各更新で送信するデータ量を減らす（たとえば、行ごとにキャプチャする画像など）
- 各更新で行う必要がある計算量を減らす
- 変更をバックグラウンドで同期して、ユーザーが同期の完了を待つ必要がないようにする
1. 更新の回数を減らす
アプリの設計により、作成される更新の数が増えることがしばしばあります。たとえば、同じ行内にある異なる 3 つの列の値を Quick Edit で変更した場合は、3 つの異なる更新が作成されます。一方、行を編集してこれら 3 つの変更を行うフォームを使用すれば、作成される更新は 1 つだけです。
同様に、多数の行に変更を加えるアプリ操作を使用する際は注意が必要です。変更自体は瞬時にアプリユーザーに反映されるものの、すべてバックエンドへの同期が必要となります。
2. 送信するデータの量を減らす
行に画像が含まれている場合、各更新で送信されるデータの量が著しく増加します。各行の列に 10 個を超える画像を入れてアプリを構築しているお客様もいらっしゃいますが、これは最初の Add Row 操作の効率が下がるだけでなく、その行に対する後続の更新のパフォーマンスにも影響を及ぼします。
アップロードする画像の解像度は [UX] > [Options] ページのオプションで管理できます。アップロードする画像の解像度が高いほど、同期中のデータ転送量が著しく増加します。
3. 計算量を減らす
更新を同期する際、2 つの計算要因があります。1 つ目は任意のスプレッドシート数式の使用です。たとえば Google スプレッドシートでは、更新のたびに影響するすべてのスプレッドシート数式が再計算されます。高価な数式（スプレッドシート内のエントリ全体を対象とした合計値の計算など）がある場合には、著しい遅延が発生する可能性があります。
計算のオーバーヘッドが生じるもう一つの要因は自動処理です。更新のたびに、アプリ内の自動処理の評価が必要になります。条件と操作のロジックによって、オーバーヘッドは些細にも重大にもなり得ます。特に、他の行のデータを変更する自動処理があると、同期されている各更新へのオーバーヘッドがかなり大きくなります。
これらの遅延は一度の更新への影響は大きくないかもしれませんが、アプリの実際の使用パターンとオーバーヘッドの蓄積によるインパクトを考慮すべきです。たとえば、Delayed Sync を有効にしている状態で 1 日の間に多くのデータ変更を収集し、その後オフィスに戻ってすべての変更を同期するといった使い方がされる場合、同期の完了にはかなりの時間を要する可能性があります。
4. 変更をバックグラウンドで同期する
自動更新を有効にできます。自動更新を有効にすると、ユーザーがローカルで行った変更がサーバーに送信されるようになります。他のユーザーによる変更後の最新のデータを読み取るには 30 分ほどかかります。