SSRで大量のデータを扱う際、レスポンスを早くする方法

Question

実現したいこと

大量のデータ(4000行、8列)をDBから取得しViewに渡したとき

• tableタグで1秒以内に表示できること。
• メニューを開いたりしたときのアニメーションが重くないこと
• ブラウザが固まらないこと

前提

業務で発生している問題ですので、環境や
gridレイアウトで表示したらは無しでお願いします。

言語等

• C# asp.net(.aspx)
• Javascript(JQuery)
• SQL Server

発生している問題

全てSSRで実施するとブラウザ実現したいことに記載した通り
ブラウザが固まり更新ボタンすら押せなくなってしまいます。
ですが、ページングは他で実装してないからという
謎理由で却下されているので、tableタグで実現する必要があり、
Jquery tablesorterも使っているのでその動きも
担保する必要があります。
(重さ具合:
250msで動くはずのアニメーションが3秒くらいかかります
約15フレーム(60fps換算)のはずなのに2フレームくらいです。
）

試したこと

OFFSET, FETCH NEXTを用いて初回アクセス時,重くならないくらい取得する
避けていた、InterSection Observerを用いて、一番下の要素が見つかったら
再フェッチすることで無限スクロールを実装

初回が重く固まることは解消できた

下の方にスクロールして読み込み完了すると結局重くなる問題発生

すべての行にobserverを設定し非表示要素に
インラインスタイルでVisibility : hiddenを設定
(display noneだとスクロールがおかしくなるため)

多少マシになったかな、まだ重いけど(現在、ここです）

※ 引用ではないですが多少見やすいかなでこの形にしています。

もし他にいい方法あれば教えていただきたいです。

また、本題とは関係ないですが、一度発火したobserverのコールバックが
何回も実行されてしまう謎も教えていただけるとありがたいです

Comments

[winterboum]

データが今後ふえていくのかもうこれ以上増えない性格なのか にもよるかとはおもいますが、
PCのメモリーが足らなくなったら遅くなるし止まるしクラッシュするし、がおきます。
思いつきですが
逆方向の無限スクロールも仕掛けたらどうでしょう。
下にスクロールして上に消えていった tr は消してしまう。下に無限スクロール
上にスクロールして下に消えていったtrはけしてしまう。上に無限スクロール

[REIA]

trを消すまたはdisplay:noneにするとスクロールバーがおかしくならないでしょうか？
また、スクロールバーが短くなり上の要素があることをユーザーが認知出来なくなります

[winterboum]

スクロールアウトしたものを全部消すのではなく、メモリに負担がかからない程度に消すということをかんがえていました。上下２画面分くらいを残すとか。スクロールバーがどうなるか、は済みません、その辺り(CSS周り)は詳しくないので。CSS は「上下溢れたらスクロール」という設定になっていると思うので大丈夫だろう とは思ってました
display:none ではだめですね。メモリから消えないから。

Answer 1

業務(機密情報)なので情報を殆ど出せないのは仕方ない話ですが、
情報が足りなさ過ぎるので問題を切り分ける努力をしてください。

流れとしては

• そもそもHTTPアクセス→レスポンスまでの時間は？
  • これで1秒以上待たされているのであれば、DBのインデックスが正しく張れてないなどの問題の可能性が高いです
  • ブラウザのF12でデベロッパーツールを開き、ネットワークタブを開きましょう
    • docの項目内でページを描画する本体のHTMLを受け取るまでの時間がわかるはずです
• レンダリングに時間が掛かっている
  • HTMLやCSSの描画へのダメージがでかいです

当てずっぽうで行きますが
CSSのtable-layout設定がautoになってるからじゃね？

table-layout: auto;は複数行の文字数を確認して、
「このカラムの横幅はこの程度が適切かな？」と空気を読んで自動的に調整する機能です。
これが100行を超える巨大なテーブルだったらどうなるか？
ブラウザが半ばパニックになってくっそ描画が遅くなります。

巨大なテーブルをHTMLで表現する時は
必ずtable-layout: fixed;を指定してあげましょう。

ただし、これはテーブルの横幅を空気読んで決めてくれる機能が動かない事を意味するわけで、何もせず等幅で表示してしまいます。
なので、thead th.name {width: 200px} 等の指定を行って自力で調整してあげてください。
横幅の狭いブラウザはメディアクエリと併用してレスポンシブ対応も頑張りましょう。

なんでgridレイアウトがNGなのか知らんけど、
table-layout設定も弄れないならお手上げです。

Answer 2

ページング禁止縛りはかなりきついものがありますね…
dom描画は量多いと時間かかるので、無理やりやるならcanvas描画でやると速く描画できます。

OSS利用ありならcheetar-gridや、canvas-datagridなどあるのでもしこちらのご活用でもよろしければ方法の一つとして検討してみてもよいと思います。

必ずtableタグのみで、の場合は可視範囲だけ描画するにしても、正直あまり現実的でないと思います。。必ずこれらの技術で解決させる、ではなく理由を上長や、責任者に明確に伝えたほうがよいとは思いますが、もしcanvasでもよければ上記方法など検討の一つに入れていただけますと幸いです。

追記：一応サンプルでJQuery＋仮想スクロールで4000行*8列で恐らくそこまで描画速度遅くならずに以下のような形で書けますが、ページネーション・もしくはcanvasの方がサクサクできるかなとは思います。（ソートはtablesorter入れると全てレンダリング後見る必要ありそうだったので、SortBy関数作成して、実装入れております。）
https://codepen.io/masanori0209/pen/WbvJajw