[Beta]: Typing lags in the pagination example with the default 990 stress pages, and fast typing falls over a second behind

Abierto
  • ¿Algo no está bien?
#5,258 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
react, typescript
Área
frontend, performance

Línea de trabajo

Start with the measurement memo in packages/plitejs/src/pagination/react.tsx:1015 and createPageLayoutGeometry in packages/plitejs/src/pagination/page-geometry.internal.ts:16; the issue reports whole-document pagination and page geometry work on each key press. Reproduce at /examples/plite/pagination with Stress pages set to 990, then compare with 0. Done when typing stays responsive with the default settings and the comparison still works.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug performance issue target:beta

Testing lane

  • Repository: udecode/plate
  • Branch: next
  • Release channel: Beta
  • Exact commit/package version: NOT_ENOUGH_INFO

Summary

With the default settings on /examples/plite/pagination, which are Rendering Virtualized and Stress pages 990 (383 pages, 3000 blocks), each typed letter takes about 70 to 110 ms to appear. At one key every 60 ms the page falls behind. The typed line stops following the keys and catches up in a few jumps, with letters up to about 1.6 s late. With Stress pages set to 0, the same typing shows each letter in about 16 ms.

Reproduction

Repro 1: /examples/plite/pagination, Chromium
  1. Open https://beta.platejs.org/examples/plite/pagination. The bar above the pages reads pages 383 | … | stress pages 990 | blocks 3000.
  2. Click after ownership in the first line of the right page, and type the quick brown fox at one key every 120 ms.
  3. Type jumps over the lazy dog at one key every 60 ms, a fast burst.
  4. For comparison, set Stress pages to 0. The bar reads pages 12 | … | stress pages 0 | blocks 30.
  5. Click after Section on the right page, and type the quick brown fox at one key every 120 ms.
  6. Type jumps over the lazy dog at one key every 60 ms.

The script sends each key at a fixed pace, the way a keyboard delivers keys, and does not wait for the page to finish. It measures, in the page, the time from each key event to the next frame after the text changed:

Step Stress pages Pace Median Worst
2 990 120 ms 71 ms 116 ms
3 990 60 ms 917 ms 1576 ms
5 0 120 ms 17 ms 27 ms
6 0 60 ms 16 ms 25 ms

During step 3 the typed line does not move with each key. In the recording it jumps forward three times, about half a second apart, and the script counts no painted letter until all 24 keys are in.

The agent also timed other settings without the recording. These are medians per key:

  • Defaults (Facing on, Virtualized, Stress pages 990): Chromium 70 to 77 ms, WebKit about 107 ms.
  • Defaults, with Chromium's CPU slowed 4x to stand in for a slower computer: about 280 ms.
  • Facing off, Virtualized, Stress pages 990: about 70 ms.
  • Virtualized, Stress pages 0: Chromium 8 to 16 ms, WebKit about 21 ms.
  • Rendering Complete DOM (12 pages): 45 to 60 ms in both engines.
  • The Rich Text example, for reference: Chromium 9 to 12 ms, WebKit 16 to 18 ms.

In the same runs, a 60 ms burst with the defaults showed its earliest letters about 2 s late, and the run appeared together. At 120 ms per key each key took about 70 ms, with no backlog. With the CPU slowed 4x, even one key every 200 ms, a normal typing pace, built a backlog, and the earliest letter showed about 8 s late. With Stress pages 0 the same bursts took 15 to 25 ms per key.

Expected

Typed letters show up within a frame or two, as they do on this page with Stress pages 0 and on the Rich Text example. natamox confirmed by hand that typing is still slow with virtualization on.

Actual

With the defaults each letter takes about 70 to 110 ms to show, and a fast burst falls more than a second behind.

Environment

  • Exact next commit/Beta package version: NOT_ENOUGH_INFO
  • An agent measured it on 2026-10-22 (PT) in headless Chromium 149.0.7827.55 and Playwright WebKit 26.5 (not Safari) on macOS, driven by Playwright with real key presses, at a 1280 x 860 window. The recording uses Chromium.
  • natamox confirmed it by hand on 2026-10-22 (PT). The browser of that retest was not recorded.
  • Not tried: Firefox, Safari itself, real input methods, mobile.

Caveat

  • All numbers come from headless browsers on a fast machine and are a reference only. The recording's readout was measured while the video was recording, and the 4x CPU slowdown is simulated.
  • The stalled painting during fast typing was seen in headless Chromium. A normal Chrome window may stall less or more.
  • From a reading of the code on next at bb6147452c, with a CPU profile: each key press changes the document version, and PagedEditable then recomputes the pagination of the whole document synchronously during render (the measurement memo at packages/plitejs/src/pagination/react.tsx:1015). Then createPageLayoutGeometry (called at packages/plitejs/src/pagination/react.tsx:1060, defined at packages/plitejs/src/pagination/page-geometry.internal.ts:16) filters every fragment for every page, so its work grows with pages times fragments. Virtualization only cuts the DOM that renders. Each key still recomputes every page.
  • In a Chromium CPU profile of 11 key presses, the geometry step took about 23 ms per key and re-pagination about 14 ms per key. Most of the rest went to the projection step that follows and to the React commit. Over 42 keys, script time was 2.8 s and browser layout 9 ms. The profile was taken on the minified Beta build without source maps, so the agent matched its frames to these functions by reading the code.
  • Rendering Complete DOM also takes 45 to 60 ms per key with only 12 pages. That page has 4867 DOM nodes, because all 240 table rows render. It was not profiled.

Evidence

  • Repro 1: headless Chromium recording, 39 seconds, with an English step panel on the right. An orange ring marks each click. The dark readout box at the bottom is drawn by the test script, not the page. It shows the document size, how many keys the step has handled and painted, and the time from key to letter. From 0:01 to 0:07 the 120 ms run reaches median 71 ms, worst 116 ms. The fast burst starts at 0:08. The typed line jumps forward at about 0:08.5, 0:09.0 and 0:09.7 while the readout counts 0 painted letters, and at 0:10 the readout shows median 917 ms, worst 1576 ms. From 0:13 Stress pages is 0. The 120 ms run from 0:18 reads median 17 ms, worst 27 ms, and the burst from 0:23 reads median 16 ms, worst 25 ms.
Repro 1 — Chromium, /examples/plite/pagination

https://github.com/user-attachments/assets/01fde260-7099-4cb7-8095-dbda6595649e

Related

Other Beta issues on the pagination pages from the same round of testing:

  • #5253: in Facing mode, clicks on the first left page land on the right page and drag-select selects nothing
  • #5254: the docs sidebar covers the page and toolbar at 1280 px and wider
  • #5255: with Facing on, the right page is cut off on first load
  • #5257: in Safari, text shifts when the caret moves and headings overlap the text during selection
  • #5260: in Safari, Shift+Down stops extending after the first line
Lenguaje dominante
TypeScript
Estrellas
16.6k
Forks
993
Merge medio
20 h 2 min
PR fusionados (30 d)
62

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de udecode/plate

Todos los issues de udecode/plate

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.