Webフロントエンドに従事するお前らはいい加減高頻度イベントとレイアウトとスタイリングの付き合い方を考えろ - Qiita
もうなんかこの際マジで言わせていただくんですけど、知ってるか知らないか分かりませんが世の中にはすごい頻度で呼ばれうるDOMイベントって言うのがいくつかあるわけですよ 例えば scroll mousemove, touchmove devicemotion 辺りですよ。 で、高頻度で呼ばれるって言うことは必然的に処理量が増えるって分かりますよね？？？？？while(1) {}じゃないとはいえUIスレッドに十分影響を与えうる頻度で呼ばれる訳です。分かりますよね？？？？？？？？ そうなると当然そのイベント内で重い処理を行えば人間が認識できるレベルでのレスポンス遅延が起きるっていうのはご理解できますよね？ 重い処理っていうのはまぁ想像出来るとは思うんですが例えばよくあるのが DOMのレイアウトプロパティへのアクセス offsetTop、offsetLeft、offsetWidth、offsetHe
scrollイベントが呼ばれすぎることへの対処 - 素人がプログラミングを勉強していたブログ
onscrollを監視していると大量にeventが来てパフォーマンスが劣化するというのはよく聞く話で、 underscore.jsなどでイベントをthrottleやdebounceさせて対処していることが多い。 ただ、scrollに応じてスタイルを変更させたりする場合は、0.1秒くらい遅れがあると視覚的にカクカクしがちで、仕方なくsetTimeout(fn, 0)でthrottleさせることも多いと思う。 scrollイベントは画面のフラッシュレートと同期していないので、マウスやトラックパッドの動きに応じて大量に呼ばれていて、setTimeoutも画面のフレッシュレートとは関係なく内部の実行タイマーに応じて動いている。よって、setTimeout(fn, 0)でthrottleしてもまだ無駄が多い。実験してみたところ、requestAnimationFrameを使うと少しだけマシになること
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
