9

1,000 行以上、12 列以上の HTML テーブルがあります。

列を固定サイズ (ユーザーが制御可能) にし、垂直方向または水平方向に拡大/縮小しないようにします。したがって、視覚的には、特定のテーブル セルの内容が 1 行になり、セルの最後でオーバーフローが途切れます。

大きなテーブルで Chrome でパフォーマンス分析を行う場合、主なパフォーマンス キラーはoverflow:hiddenです。

各セルの内容を入力内に配置しようとしましたが、これは同じ視覚的動作を複製するためですが、パフォーマンスに同様の影響があります。

パフォーマンスを向上させるために人々は何を推奨していますか?

必要に応じて table タグを使用する必要はありませんが、良好なパフォーマンスが得られる場合は table タグを使用することをお勧めします。

更新 1 : パフォーマンスの問題を示すファイルをここに含めました。このファイルは非常に大きく (25MB)、コンピュータの速度が低下することに注意してください。デフォルトでは、テーブルのオーバーフローは非表示に設定されておらず、テーブルが読み込まれると (しばらく時間がかかる場合があります)、ブラウザーのパフォーマンスは比較的スムーズになります。

ただし、ファイルを編集して 12 ～ 15 行目のコメントを外してから開くと、. テーブルの周りでブラウザを読み込んだ後、応答が大幅に低下することがわかります。

4

4 に答える 4

3

参考までに: iPad/iOS でこの問題に遭遇し、table-layout:fixed のテーブルに約 100 行あるページでパフォーマンスの問題が発生しました。

セルまたはセル内の div が、セルを個別に描画するように強制する属性を取得するとすぐに、描画に 100 ミリ秒ではなく約 300 ミリ秒かかります (これにより、私の状況では UI が非常に遅く感じられます)。

2 つのプロパティ (position:relativeまたはoverflow:hidden) のいずれかが問題を引き起こし、それらを削除すると速度が最適化されましたが、固定幅の列に対してセル テキストが広すぎる場合、テキスト オーバーフローが発生しました。

テーブルの上に絶対divを動的にポップアップしているため、テーブルが描画された後でもスローダウンが発生していました。javascript をプロファイリングする場合 ( を使用(new Date).getTime())、javascript 内のテーブルとは関係のない場所で速度低下が測定されます。

[編集: 一部のソリューションとして以下を追加]

  1. すべてのセル コンテンツをspan要素内に配置します (ブロック要素を含む幅ではなく、コンテンツの offsetWidth を測定できます)。
  2. ドキュメントに行を追加した後、各 span.offsetWidth が列幅より大きいかどうかをテストします。そうである場合は、含まれているブロックのスタイルに (またはクラスを介して) 「overflow:hidden」を追加します。
  3. 一部の列については、上記の 1 と 2 をスキップできます (セルの内容をクリッピングする必要がないことがわかっている場合)。

警告:

  1. 測定は iOS5 Safari でのみ行われました (他のブラウザーのプロファイルは作成していません)。
  2. テーブル行を動的に作成するため、うまくいきます (javascript を使用した例の処理は遅くなりますか?)。
  3. データのほとんどのセルはオーバーフローしません (クリッピングはまばらにのみ必要です - 限られた数のセルのみ)。
  4. 最初のページ読み込みが損なわれました (ページ内のテーブルの生成が 80 ミリ秒から 800 ミリ秒になりました)。
  5. ただし、ダイナミック コンボ ポップアップ (340 ミリ秒から 130 ミリ秒) を高速化して、キーボードの応答性を大幅に向上させました。

あなたの状況では、最初に可変幅の列を使用し、すべての列のoffsetWidthを測定し、列の幅をピクセル幅に設定し、overflow:hidden を列のoffsetWidthが使用するピクセル幅よりも大きい列にのみ設定するのが速いかもしれません桁。

于 2012-06-28T01:38:43.080 に答える
2

タイル張りのアプローチを使用してみることができます。これは、無限に横スクロール可能なゲームなどを効率的に作成するための非常に典型的なアプローチです。

すべてのデータを Javascript 配列に入れ、N 行が表示されるテーブルに N + 1 行を配置します。下にスクロールすると、最後のアイテムが表示されます。最初の項目が見えなくなるまでスクロールした時点で、すべてのデータを 1 行上に移動し、スクロール位置を最初の位置にリセットします。正しく行われると、シフトはユーザーに対して完全に透過的になります。N 行が表示されるテーブルでは、N + 1 行しか操作できません。

以前にこれを行ったことがありますが、非常に特定の UI 制約の下で行われました。組み込みのブラウザのスクロールバーなどを使用してこれを一貫させることを考えて、私はちょっとシャッターを切りました。

于 2012-05-16T00:03:26.730 に答える
1

Webkit バグ 75001はこの問題に関連しており、それを解決するために行われている作業をカバーしています (詳細については、bugzilla の依存関係も参照してください)。

于 2012-06-29T04:12:02.823 に答える
1

まず、テーブルを作成するために必要なマークアップの量は、新しい行に clear:both css を使用して div を使用するよりもはるかに多くなります。これが最初のパフォーマンス ヒットです。

また、オーバーフローをクラスとして設定しています（ ? ）

 <style type="text/css"> .ovfl { overflow:hidden; }</style>

  <td class="ovfl"></td>

余談ですが、1000 行というのはかなりの負荷です。

div を使用すると、少なくとも、訪問者がそれらにスクロールするまで、display:noneを使用して div にそれらを ( scroll を超えて) 見えないようにする簡単な機会があります。

ほとんどの場合、この仕事で猫を飼うスキンはほとんどありません。

ホープには良い考えがありました。

于 2012-05-15T23:22:14.343 に答える