Płynne działanie strony w JavaScript - jak działa Event Loop i jak uniknąć zacinania ekranu?

Anatomia Event Loop: Stos, Kolejki i Renderowanie

Sercem wykonawczym JavaScriptu jest pojedynczy wątek, który zarządza przydziałem czasu procesora pomiędzy logikę aplikacji a proces renderowania pikseli na ekranie. Aby uniknąć chaosu, przeglądarka opiera się na czterech filarach:

• Call Stack (Stos wywołań): Miejsce, w którym wykonywane są aktualne funkcje synchronously (krok po kroku). Jeśli funkcja wykonuje się zbyt długo, stos zostaje zablokowany.
• Task Queue / Macrotask Queue: Kolejka zadań zoptymalizowanych pod kątem zdarzeń zewnętrznych, takich jak zdarzenia interakcji (click, input), timery (setTimeout, setInterval) czy zapytania I/O.
• Microtask Queue: Kolejka zadań o wyższym priorytecie niż macrotask. Trafiają tu głównie obietnice (Promises), callbacki queueMicrotask oraz obserwatory MutationObserver. Przeglądarka opróżnia całą kolejkę mikrozadań natychmiast po wyczyszczeniu stosu wywołań, zanim przejdzie do kolejnego makrozadania.
• Render Pipeline: Proces przeliczania stylów, układu (Layout) i rysowania (Paint), który przeglądarka próbuje wykonać z częstotliwością 60 klatek na sekundę (co około 16.6ms).

Gdy na stosie wywołań znajduje się ciężkie zadanie trwające np. 300ms, pętla zdarzeń zostaje wstrzymana. W tym czasie przeglądarka nie może ani obsłużyć kliknięcia użytkownika, ani przeryrysować klatki, co bezpośrednio pogarsza wskaźniki wydajności interakcji – obszernie wyjaśnia to materiał pokazujący, czym skutkuje refaktoryzacja JavaScript pod kątem metryki INP.

Pułapka nieskończonych mikrozadań w praktyce

Częstym błędem programistycznym powodującym całkowite zablokowanie interfejsu przy zachowaniu braku błędów w konsoli jest nadmierne zagnieżdżanie mikrozadań. Ponieważ przeglądarka ma obowiązek opróżnić całą kolejkę Microtask Queue przed przejściem do następnej klatki, rekrurencyjne dodawanie obietnic całkowicie odcina wątek główny.

Oto prosty przykład pętli, która na stałe zamraża interfejs użytkownika:

function blockEngine() {
    Promise.resolve().then(() => {
        // Mikrozadanie tworzy kolejne mikrozadanie bez końca
        blockEngine();
    });
}
blockEngine();

W przeciwieństwie do rekrurencji synchronicznej, ten kod nie przekroczy maksymalnego rozmiaru stosu wywołań (Stack Overflow), ale spowoduje głód wątku renderującego (Render Starvation). Ekran przestanie reagować na jakiekolwiek akcje, a przeglądarka sprawi wrażenie całkowicie zawieszonej.

Metody rozbijania długich zadań (Long Tasks)

Aby zapobiec blokowaniu wątku głównego, długotrwałe operacje logiczne należy dzielić na mniejsze fragmenty (chunks), dając przeglądarce czas na obsłużenie zdarzeń użytkownika oraz wyrenderowanie klatki pomiędzy kolejnymi krokami.

1. Użycie scheduler.yield() oraz setTimeout

Nowoczesne przeglądarki wprowadzają API scheduler.yield(), które pozwala w elegancki sposób oddać sterowanie do pętli zdarzeń i wznowić wykonywanie funkcji natychmiast po obsłudze pilnych zadań. Jako rozwiązanie zastępcze (fallback) stosuje się rozbijanie pętli za pomocą klasycznego setTimeout z czasem 0ms:

async function processLargeArray(items) {
    for (let i = 0; i < items.length; i++) {
        doHeavyCalculation(items[i]);

        // Co 100 elementów oddajmy kontrolę wątkowi głównemu
        if (i % 100 === 0) {
            if ('scheduler' in window && 'yield' in performance.scheduler) {
                await performance.scheduler.yield();
            } else {
                await new Promise(resolve => setTimeout(resolve, 0));
            }
        }
    }
}

2. Przenoszenie ciężkich obliczeń do Web Workers

Jeżeli Twoja aplikacja wymaga przetwarzania dużych zbiorów danych, szyfrowania czy operacji na obrazach, optymalnym rozwiązaniem jest całkowite usunięcie tych obliczeń z wątku głównego i przeniesienie ich do osobnego wątku roboczego (Web Worker). Działa on równolegle i nie wpływa na płynność interfejsu użytkownika.

Zrozumienie, w jaki sposób wykonywanie skryptów wpływa na modyfikacje elementów ekranowych, staje się kluczowe, gdy analizujesz jak wygenerowany kod przekłada się na struktury przeglądarki, np. gdy badasz czym jest DOM (Document Object Model) i jak dynamicznie nim manipulować bez spadków FPS.

Animacje a optymalne renderowanie

Jeśli zmieniasz właściwości wizualne elementów w pętli lub podczas scrollowania, zmiana nie powinna odbywać się wewnątrz timerów setInterval ani bezpośrednio w zdarzeniach opartych na obietnicach. Do synchronizacji zmian wizualnych z częstotliwością odświeżania monitora służy metoda requestAnimationFrame().

function smoothAnimation() {
    // Aktualizacja pozycji lub stylów elementu
    updateElementPosition();

    // Rejestracja wywołania na następną klatkę renderowania
    requestAnimationFrame(smoothAnimation);
}

requestAnimationFrame(smoothAnimation);

Stosowanie odpowiednich mechanizmów wykonawczych w połączeniu ze świadomą kontrolą mikrozadań zabezpiecza witrynę przed lagami. W efekcie strona działa płynnie nawet na słabszych urządzeniach mobilnych, zapewniając doskonały komfort użytkowania i bezbłędny UX.