Plate
PlateEditorsTemplates
GitHub16kGitHub
DiscordDiscord
  • Feature Kits
  • Plugin
    • Plugin Methods
    • Plugin Shortcuts
    • Plugin Context
    • Plugin Components
    • Plugin Rules
    • Editing Behavior
    • Plugin Input Rules
  • Editor
    • Editor Methods
    • Controlled Value
  • Authored Changes
  • Performance
  • Static Rendering
  • HTML
  • Markdown
  • Form
  • TypeScript
  • Debugging
  • Unit Testing
  • Browser
  • Troubleshooting
  • Locations
  • Transactions
  • Serializing
  • Roots
  • Document Meta
  • Clipboard and Paste
  • Decorations, annotations, and widgets
  • Schema
  • History
  • Pagination
  • Annotations
  • DOM Coverage
  • External Text Views
  • Virtualized Rendering

Performance

PreviousNext

A recorded Plate vs Plite large-document benchmark and how to measure your current checkout.

Performance is about whether the editor stays usable when the document gets large. This page shows a recorded 10k Plate vs Plite snapshot from the docs benchmark route and the command for measuring your current checkout.

Recorded snapshot

This snapshot was captured on June 2, 2026 from the docs benchmark route in headless Chrome. The benchmark uses a 10,000-block document with chunked rendering enabled.

These numbers describe that checkout and environment. Run the benchmark on the version you use before comparing current performance.

WorkloadPlitePlate corePlate with basic plugins
Open a mixed document524 ms866 ms
Controlled ValueStatic Rendering

On This Page

Recorded snapshotRun the benchmarkWhat it measuresRead the numbersSourceOptimize the measured cost
Build your editor
Production-ready AI template and reusable components.
Get all-access
881 ms
Type in a mixed document26 ms43 ms35 ms
Open a code-heavy document526 ms837 ms1101 ms

Read this as a workload snapshot, not as a universal editor score. Mount time, typing latency, plugin cost, and document shape are different performance questions.

Run the benchmark

Start the docs app:

pnpm --filter www dev

Then run the public editor benchmark in another terminal:

pnpm --filter www perf:editor:public

The runner writes a compact JSON summary to apps/www/.tmp/editor-perf-public-summary.json.

What it measures

The benchmark keeps the public comparison small on purpose:

MeasurementWhat it tells you
Opening a mixed documentThe cost of mounting a large editor with normal rich-text variety.
Typing in a mixed documentWhether the editor still responds under a large loaded document.
Opening a code-heavy documentThe cost of a harder mark-heavy rendering profile.

Plate core isolates the editor wrapper cost. Plate with basic plugins adds the common block and mark plugins many editors start with.

Read the numbers

Compare like with like:

  • use mount numbers for startup cost
  • use typing numbers for interaction cost
  • use the basic plugin column when you care about a real Plate setup
  • rerun the benchmark on your machine before publishing a performance claim

The raw output also includes lower-level Plate diagnostics, such as node-id cost. Those are useful for debugging Plate itself, but they are not the public story.

Source

Use the Huge Document demo for manual inspection. The benchmark route lives at /dev/editor-perf, and the runner lives in apps/www/scripts/run-editor-perf.mts.

Optimize the measured cost

Profile the complete interaction: typing, selection, paste, undo, and scrolling can have different costs. Distinguish transaction work, React subscriptions, DOM mounting, and painting before changing the editor's rendering mode.

Keep corrections local to affected entries. Whole-document maintenance belongs in explicit repair, not every keystroke. Keep plugin component definitions stable and subscribe UI to the smallest state it needs: useEditorSelection for selection, useEditorSelector for derived editor state, and node-scoped hooks for rendered content.

EditorContent mounts the complete document. Use VirtualizedEditorContent only when the measured DOM budget requires omission. Offscreen content then needs explicit handling for native find, accessibility, printing, and third-party DOM integrations. Pagination geometry by itself does not establish a virtualized mounting policy.

Browser painting can dominate a large tree even when transactions and React are fast. Measure any content-visibility policy in the browsers you support; its per-element overhead and accessibility behavior also affect the result.