«« シティーハンターフランス版は日本テレビでは放送できないだろうけどよくやった!(少しネタバレ) | PageSpeed Insightsのモバイル評価が40点台から80点台に上げてみた »»
JavaScript(jQuery)でデータを出力するとき、うっかりすると以下のように少しづつ出力していくコードを組みがちですけど。
javascript
for(var i = 0; i < row.length; i++) {
$("#contents").append(row[i]);
}
1行ずつ足してスクリーンに反映するのはムダに処理時間がかかるので、やめたほうが良いです。
1行づつ足すのは文字変数内で行って、最後画面へ一気に反映する。
という形が良いです。
上記のコードで言えば下記のように書くべき。
javascript
var output = "";
for(var i = 0; i < row.length; i++) {
output += row[i];
}
$("#contents").append(output);
歴史でいうと、戦国時代に織田信長が戦略上川の中州に城を作ることになったのですが、作ろうとしても敵が攻撃してくるのですぐ壊されてしまうことがありました。
そこで豊臣秀吉があらかじめ川の上流にて城の完成部品を作って流し、下流では一気に組み立てる工法を使うことで一夜にして城を完成させることにより目的を果たしたという話みたいなもんですかね。
システム的に言うと、事前に文字変数内で追加していくと、CPU←→メモリーといった内部処理で完結するので処理が高速になります。
一方画面出力するには映像出力とやり取りすることになるんですが、これがCPU←→メモリー間の通信と比べてすごく遅い。
ですので、1行づつ画面出力する処理をすると映像出力部分がボトルネックとなって、CPUとメモリーに空き時間が生まれてしまって遅くなります。
あらかじめ出力データを揃えておいて、映像出力部分にまとめて渡すとボトルネックが最小になるので、結果として高速に描画を完了できます。
量が多くなればなるほどその処理時間差は開いていき、全体的な処理時間についてアルゴリズム変更で2倍以上差がつくというのもよくある話です。
See the Pen Output at once in jQuery. by Hiroshi Kuze (@hiroshikuze) on CodePen.
ただ悩むのが描画量多すぎるために、最後の画面出力へ渡すのも時間がかかってしまい、やっぱりシステムが固まったように見えてしまうケース。
自分も描画量が多すぎてどうやっても描画に時間がかかる場合どうするか良いか答えを出せないのですが。
とにかくにもまとめて描画する1回の描画量を減らすして、分散しつつ各回はまとめて描画するようにするしかない。
いまのところこれでなんとかできないかと考えているのが、「遅延ロード作戦」。
画面に見えている部分とその周辺だけ描画する
スクロールバー移動後動作するイベントをセットする
イベント内の処理では、スクロールの座標を調べて、スクロールバーの位置が未描画部分に達したら追加部分を少しづつ足していく
この方法だと最初の描画がなにせ表示領域だけしか描画しないだけにすごく短時間で終わるというメリットがあります。
一方でまだコードを書いていないんで比較できないんですけど、途中で固まってひっかかる印象を持つようになってスクロールをサクサク進めることができないことにならないか不安です。
あと主にInternet Explorer 11で影響強いんですけど、表示部分にあとから追加する場合の処理スピードの劣化しやすさがひどい。
そもそも他のブラウザ・・・たとえばChromeでは『「最後に画面へ反映」自体すごく時間がかかって』がIEの比じゃないほど発生しないから、(自分が今回対応している案件の場合)こんな試行錯誤しなくていいんですよ。
なんで法人ではInternet Explorer 11の人気がいまだに高いんだよ!
もちろんその理由は安定して旧システムを使い続けたい・他のブラウザは入れたくないというニーズが高いのは知っています。
ですが、足手まといで本当に辛い。
MicrosoftもMicrosoft。
Internet Explorer(6)を腐った牛乳扱いしている割には、Windows 10 EnterpriseとかWindows 20XX ServerではIEが標準ブラウザでEdgeすら入れていないって顧客ニーズに答えた結果なのはわかるんですけど、あえて言う。
Microsoft何考えているの?!
(だからこそ自分たちが依頼を受ける際もInternet Exploreを対象にするならあらかじめ大幅に予算と工数を取ってUIも古いものにしないといけないという正論はわかっています。)
そんな愚痴はともかく、その他の解決策としては『縦に追加していくのは諦めて「次のページへ」ボタンを追加する』というのも検討しています。
この方法なら描画範囲は限定されるのでInternet Explorer11の古いシステムによる描画時間の遅さは軽減されます。
個人的にマウスホイールから手を離して利用者に小さいボタンを探させて押させるのは負けと感じて悔しい。
とはいえホイールによる縦スクロールの快適さばっかり時間を費やせないし、仕方ない。
■広告
投稿者 kuze : 2019年12月14日 18:12
«« シティーハンターフランス版は日本テレビでは放送できないだろうけどよくやった!(少しネタバレ) | PageSpeed Insightsのモバイル評価が40点台から80点台に上げてみた »»
コメント