Output Console 50× szybsza dzięki shadow DOM
Output Console — okno deweloperskie, do którego trafiają logi strony — przez długi czas miało ograniczenie: powyżej kilkuset wpisów renderowanie zaczynało się rozjeżdżać. 700 wpisów na liście dawało okno, które zatykało się przy każdej aktualizacji — ~5 sekund na re-render. W v3.2.30 wprowadziliśmy okno do shadow DOM — i razem z izolacją od stylów strony przyszła nieoczekiwana, ogromna przyspieszka. Te same 700 wpisów renderuje się teraz w ~100 milisekundach. Pięćdziesiąt razy szybciej.
Skąd brała się wolność
Output Console był w drzewie DOM strony jako zwykły element. Każde dodanie nowego wpisu wymuszało, by przeglądarka przeliczyła style dla wszystkich elementów w drzewie — bo CSS strony mógł teoretycznie wpłynąć na wygląd jednego z nich. Style recalc na 700+ elementach, plus 500+ stron z własnym CSS-em w tle, plus okno musiało rerenderować się przy każdym nowym logu — to dawało zauważalny lag.
Dodatkowy koszt: niektóre serwisy (Google Workspace, Notion, korporacyjne intranety) mają tysiące reguł CSS w stylesheet-cie strony. Każda nasza nowa linia w Output Console powodowała match-przeszukanie tysięcy selektorów strony — czy któraś z nich nas dotyczy.
Co zrobił shadow DOM
Renderowanie okna jako shadow root daje przeglądarce informację: style strony nie dotyczą tego poddrzewa. Przy każdym nowym wpisie przeglądarka pomija pętlę match-przeszukania selektorów strony. Style recalc obowiązuje tylko style z wewnątrz shadow rootu — kilkadziesiąt linijek CSS-u Output Console-a zamiast tysięcy linijek strony.
Efekt: profile-r pokazał, że 87% czasu renderowania w pre-shadow DOM był stracony na RecalculateStyle dla węzłów Output Console-a. Po migracji ten koszt znika prawie w całości.
Jak to zmierzyliśmy
Repro: stronę z aktywnym Output Console-em + 700 wcześniej dodanych wpisów (Network, Console, dataLayer). DevTools Performance tab, akcja: JUSTZIX.log('test ' + i) w pętli 100×.
- Pre v3.2.30 (light DOM): 100 nowych wpisów = ~5000 ms główne render time.
- Post v3.2.30 (shadow DOM): 100 nowych wpisów = ~100 ms.
Faktyczny mnożnik zależał od strony — na minimalnym (about:blank) zaledwie 5×, ale na produkcyjnym Google Workspace blisko 60×. „50×" to przybliżona mediana — dlatego trzymamy się tego nagłówka.
Co to zmienia w workflow
Trzy konkretne sytuacje, w których to robi różnicę:
- Długo działający debug — zostawiasz Output Console otwarte na ekranie godzinami, w tle leci normalna aktywność strony (autosave-y, polling, GTM events). Wcześniej okno robiło się powoli reagujące po jakimś czasie; teraz utrzymuje płynność.
- Network storm — analiza waterfall-a strony, na której leci ~100 żądań na sekundę (np. infinite scroll z lazy-load-em). Wcześniej okno opóźniało się o pół sekundy za realnym ruchem; teraz nadąża.
- dataLayer-szpieg — strony z bardzo aktywnym GTM-em (e-commerce, CRM dashboardy) pushują 5-10 zdarzeń na sekundę. Lista „nowych pushy" rośnie szybko — teraz scrollujesz po niej w czasie rzeczywistym.
Czy to wpływa na inne okna
Output Console było pierwszym oknem migrowanym do shadow DOM (v3.2.30). Po tym samym wzorcu poszedł AI Helper (v3.2.76, patrz osobny post). Pozostałe okna deweloperskie — CSS pane, JS pane, JS Console — wciąż żyją w light DOM-ie. Każde z nich ma znacznie mniej węzłów (CSS pane = 1 textarea + nagłówek, JS pane analogicznie), więc nie odczuwają tego samego problemu wydajnościowego. Migracja kolejnych jest planowana jako naturalne rozszerzenie izolacji.
Zobacz też
- Output Console — pełny opis okna i jego zakładek
- AI Helper w shadow DOM — drugi krok izolacji okien wtyczki
- Okna na froncie — wszystkie okna deweloperskie wtyczki
Zainstaluj JustZix — i miej Output Console, która nadąża za ruchem na stronie.
Oceń ten wpis
Brak ocen — oceń jako pierwszy.