どうも、サイボウズのサーバー側の処理が遅いためのように思うのですが。。

えっと、「1レコードに、約30フィールドをもつテーブルがあり関数も設定している」ということであってますか？

西村さん、ありがとうございます。ご認識の通りです。
正確には、関数ではなく以下のプラグインによる計算式を設定しています。
https://qiita.com/rex0220/items/ae83c6d5ce50ff7a9a73
テーブル以外にも、150フィールド程度あり、そのうちの30フィールド位に計算式を設定しています。

まんじねこさん

なるほど。プラグインなのですね。たしかにプラグインは汎用性を持たせるなどの理由でオーバーヘッド（主処理以外の処理）がかかる可能性はあります。ので純粋な関数利用よりは処理時間がかかるかもしれませんね。

しかしながら、テーブル以外にも150フィールド程度あるとの事ですので、プラグインを用いた関数が原因とも言い切れないなと思います（それもひとつの要素ではありますが）。

ジャッカルさんのおっしゃるように描画速度についてはクライアントＰＣの処理能力も一因として考えられます。

ただおそらくkintoneでは、1レコード内で150フィールド+30x30のテーブルを標準的な使い方としては考えていないからではないかと思います。特に描画のあたりは大量のフィールド表示を想定したつくりにはなっていないようですね。

私なら、まずアプリ自体のフィールドを減らせないか運用や仕様の見直しを検討します。
それがなかなか難しい場合は、落としどころを探るためにも、そもそものボトルネックはどこかを順番に詰めていきます。

関数（プラグイン）が原因と思うのであれば一旦すべての関数を外して改善されるかを確認します。すべて外しても速度に変化を感じなければプラグインが原因の可能性は低いですよね。

大量のフィールドもしくは30x30のテーブルが原因であると思うのであればフィールドなどを減らしていってどれくらいレスポンスが改善するのかを確認します。ちょっとづつ減らしていくと、どっかのタイミングで実運用に耐えうるスピードになるはず。

以上の作業を色々試して原因の大きなものを見つけたらそれについて対策を講じる感じですかね。ちょっと手間ですけど。^^;

例えばもしプラグインが原因であるのなら（あきらめるを含めて）その対策を考えるか、その処理が運用や仕様上必須であれば相応の処理をJSカスタマイズするかもしれません（JSカスタマイズしたら必ず早くなるというわけでもないですが^^;）。

またフィールドの個数が原因であればその代替案を考えるか、もしかしたら、一定条件におけるその両方の複合要因、またはそれ以外の要因があるかもしれませんので、そのあたりも含めてちょっとづつ調べるかなーという感じです。

う～ん^^;。まんじねこさんのアプリ自体を拝見しているわけではないですので、結局一般的な回答になってしまって恐縮ですが、なにかのヒントになれば幸いです。^^