Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Scan time on large applications: measured breakdown and remaining options

Aperta
  • Qualcosa non va?
#264 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
playwright, typescript, vite
Ambito
performance, testing-qa

Direzione di ricerca

Start by measuring how quickly a passing focus move arrives, then benchmark Vite server.warmup and parallel screen scans as described in the issue. Compare results on a quiet machine and account for the source attributes needed by overlay file and line hints. Done means the measurements support a decision on which scan-time option to adopt.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area: engine enhancement performance

Measured on a real product UI (one screen, about 55 seconds)

Phase Share
Readiness wait while the app mounts about 2,000 dev-server modules 37%
Seven focus-settle timeouts at 2.5 s proving menus do not steal focus 32%
Whole-DOM fetch per accessibility lookup (separate issue) 16%
Keyboard walks, axe, everything else 15%

The lab tunnel was not the bottleneck: API calls cost about 300 ms more than local and overlap with module loading.

On a small application one screen takes about 10 seconds warm. Editing the vite config triggers a one-time dependency re-optimization that doubles the next scan.

Options not taken, with reasons

  • Shortening SETTLE_SAMPLES_REQUIRED recovers about 1 second but guards a real two-burst mount regression.
  • Shortening FOCUS_SETTLE_TIMEOUT_MS recovers 2.5 seconds per unfocused widget but there is no measurement of how quickly a passing focus move arrives; shortening blind turns slow but correct focus into false failures. Measure a passing case first.
  • Running screens in parallel shares one browser process and a DOM-stability poll, so contention lengthens the wait; likely a loss on a loaded laptop. Measure before adopting.
  • A production build removes the module-graph cost but drops the JSX source attributes the overlay's file and line hints read.
  • Vite server.warmup for the target application may cut the module-graph time while keeping source attributes; unmeasured.

Direction

Measure a passing focus move; measure server.warmup; measure parallel screens on a quiet machine; then decide.

Lingua principale
TypeScript
Stelle
0
Fork
0
Merge medio
2h 48m
PR unite (30g)
8

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di usabl-dev/usabl

Tutte le issue di usabl-dev/usabl

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.