パフォーマンスガイド

高速レンダリングはCanvas2Dより先に始まる。データは列指向に保ち、一度だけ転送し、メインスレッドでのデコードを避け、チャートは表示される表現だけを描画させる。

まずはWorkerの自動選択とデフォルトの詳細度（LOD）ポリシーで開始し、実際の負荷を計測する。LOD calibration lab を使って、密度、再ベース比、量子化を変更する前に調整する。

推奨ロードパイプライン

初回フレームのレイテンシーが重要な場合は、極値を保持する小さなプレビューを表示する。
ネットワークフェッチとデコードは専用のデータWorkerで開始する。
列指向フォーマットから必要な列とレンジのみを読み取る。
整列した長さ、有限で順序付けされたX、単位、および宣言されたギャップを検証する。
型付けされた列を一度だけチャートレンダラーに転送する。
転送後にデータWorkerを終了させ、別コピーを保持させない。

HTTP範囲読み取りの場合は、静的ホストがバイトレンジをサポートし、途中のキャッシュがそれらを保持することを確認する。正しい全件ダウンロードのフォールバックでもモバイル訪問者には依然として高コストになり得る。

初期バンドルを小さく保つ

重いデータデコーダやオプションのデモは動的にインポートする。
現在表示されている、または選択されたチャートのみをマウントする。
レンダラーが受け入れられることを示すためだけに、着地ページに何百万行ものショーケースデータを配送してはいけない。
テーマカタログや二次的な例は保護された初回フレームパスから外しておく。
制約のあるデバイスではキュレーション済みまたは適応型の例を優先し、フルワークベンチへのリンクを提供する。

Workerモードを選ぶ

一般的なアプリケーションではrenderMode: "auto"を使用し、解決されたモードを測定する。メインスレッドモードはテストや小さな静的チャートに有用だが、大規模なインタラクティブデータセットは通常Workerで動かすべきである。

作業負荷に応じてライン表示を調整する

lod.densityは主要なfidelity/work制御である。0.75から始める。ローカルの詳細が視覚的に不足しておりフレーム時間が余裕ある場合は増やす。マルチパス塗りつぶし範囲、高いデバイスピクセル比、またはCanvas2Dの塗りコストが支配的なブラウザでは減らす。

表現の滑らかさは密度だけでなくrebaseRatioとquantizationStepに依存する。細かい値は個々のテクスチャ変更を減らすが階層クエリをより頻繁にする。実際のズームジェスチャで調整し、定常状態のフレーム時間、クエリ訪問数、表示頂点数、視覚的安定性を比較する。

開発中は一時的にsetStatsCallbackを使用する:

chart.setStatsCallback((stats) => {
  console.table({
    frame: stats.frameTime,
    mode: stats.presentationMode,
    vertices: stats.presentationVertices,
    visits: stats.presentationQueryVisits,
    ready: stats.lodReady,
  });
}, { intervalMs: 250 });

アプリケーションがテレメトリを消費しない場合は、本番環境ではコールバックを無効にする。

バッチ更新

完全なバッチが既に存在する場合はバルクの型付き配列APIを使用する。
ひとつのUI操作による複数の同期的で命令的な変更にはbatch()を使用する。
フレーム毎のコールバック内で配列を構築したり文字列をフォーマットしたりすることを避ける。
アプリケーション側のストリーミング再構築はデバウンスし、古い非同期結果は無視する。

データの意味を保持する

パフォーマンス低下は極値と実際のギャップを保持しなければならない。レンジ包絡を事前に平均化したり、欠落区間を接続したり、各積み上げ領域入力を独立にダウンサンプルしたりしてはならない。OHLCVの場合は実際の観測に基づき、openは最初、highは最大、lowは最小、closeは最後、volumeは合計で集計する。