2

I've been investigating some performance issues with scrolling my website on iPad Safari. We have some pages which are large table elements with up to 500 rows; the performance impact definitely seems related to the number of rows in the table (and, on pages without such tables, scrolling performance seems fine). Desktop browsers are perfectly fine.

You can try this out at the following link. NOTE: to repro, make sure to change the default of 25/page to 500/page. http://www.cellartracker.com/list.asp?table=Notes&iUserOverride=0&T=1000

After doing quite a bit of debugging, I've found that if I remove any 'touchstart' events I've bound, scrolling performance is normal (and super-fast, as expected). I have a few $(document).on('touchstart', '<selector>', function ()...) events configured to assist with making some hover functionality accessible to touch devices. Currently, I bind to $(document) for two reasons:

  1. There can be a lot of elements that match the selector, so traditionally the performance of a single delegated event handler is better than 500+ handlers attached to each element (I just fixed some perf issues related to this on IE8).
  2. Some of the affected elements are loaded via AJAX, so those wouldn't automatically get the handler if I bound to the individual elements.

OK, great--I've found the cause--but I don't know why this is a problem only on pages with large tables and how to work around it. For devices with BOTH touch and keyboard/mouse, I want each input mechanism to act consistently (so the if (touch) bind('click') else bind('mouseenter') approach isn't what I'm looking for). Plus, I'm also looking at implementing the Fast Buttons approach for some elements, which would likely necessitate binding to $(document) as that's where the corresponding click handlers currently are bound.

So...any ideas on how to improve scrolling perf on these pages while still binding touchstart to $(document)? The HTML is pretty fixed at this point, but if there are simple tweaks to the DOM that would have a big impact I'm open to it.

4

2 に答える 2

4

さて、これを別の作業のために数日間取っておいた後、パフォーマンスが不思議なことに大幅に改善されていることに気付きました! 加えられた他の変更をさかのぼると、パフォーマンスの問題の根源であるjQuery UI 1.8.20が見つかりました。他のいくつかの問題を修正するために jQuery UI 1.9.2 にアップグレードしたところ、恐ろしいスクロール ラグやパフォーマンスの問題が発生しなくなりました。

touchstartにバインドしたことによるわずかなパフォーマンスの低下がまだ見られます$(document)が、現在は非常に小さいため、ほとんど認識できません。ただし、元の質問をより適切に最適化する方法について他のガイダンスがある場合は、ぜひ聞いてください!

于 2012-12-18T22:39:23.093 に答える
0

scrollperf の低下は DOM のサイズに比例することがわかりました。DOM ノードの数、ネストのレベル、ピクセル数、レンダリングの複雑さ、またはその他のものであるかどうかを判断するのに十分なテストをまだ行っていません。フィード アイテムを追加するほど、スクロールのパフォーマンスが低下することは言うまでもありません。

次の Codepen はこれを示しています。

http://codepen.io/ddopson/pen/zgCfj

40 ほどのフィード アイテムを追加し (最初のボタン)、「touchstart」イベント リスナーを切り替える (3 番目のボタン) と、大規模なページでタッチ イベントをリッスンする場合のペナルティがどれほど深刻であるかがはっきりとわかります。

私もこの問題を解決しようとしていますが、まだ正しい道を整理していません...

于 2013-03-06T01:01:17.793 に答える