Цикл событий в JavaScript простыми словами

Цикл событий в JavaScript: от очередей к отзывчивому интерфейсу

Цикл событий - это фундаментальный механизм, который определяет, как JavaScript выполняет код в браузере. Он управляет порядком выполнения синхронных и асинхронных операций, обеспечивает обновление интерфейса и обработку пользовательских действий. Без понимания его работы невозможно создавать отзывчивые веб-приложения и избегать распространённых ошибок при работе с асинхронным кодом.

Разберёмся, как устроен цикл событий, почему микрозадачи выполняются раньше макрозадач, как задачи влияют на отрисовку интерфейса и какие типичные ошибки допускают разработчики при работе с асинхронным кодом.

Анатомия цикла событий: стек, очереди и микроочереди

Цикл событий состоит из нескольких ключевых компонентов:

Стек вызовов (Call Stack) - это место, где выполняется синхронный JavaScript-код. Когда функция вызывает другую функцию, новая задача добавляется в стек. Когда функция завершается, она удаляется из стека. Если стек переполняется (например, при бесконечной рекурсии), возникает ошибка “Maximum call stack size exceeded”.
Очередь макрозадач (Macrotask Queue) - сюда попадают задачи, которые нужно выполнить позже. Это:
- Таймеры (setTimeout, setInterval)
- События DOM (click, scroll, input)
- Сетевые запросы (fetch, XMLHttpRequest)
- Другие асинхронные операции
Очередь микрозадач (Microtask Queue) - очередь для задач с более высоким приоритетом. Сюда попадают:
- Промисы (then, catch, finally)
- Задачи, созданные через queueMicrotask
- Мутации DOM (через MutationObserver)

Порядок выполнения задач следующий:

Выполняется текущая макрозадача из стека вызовов
Когда стек пустеет, выполняются все микрозадачи из очереди микрозадач
Браузер может обновить интерфейс, если пришло время нового кадра
Цикл берёт следующую макрозадачу из очереди макрозадач

Почему микрозадачи выполняются раньше макрозадач: типичный тупик

Рассмотрим классический пример, который часто вызывает недопонимание:

console.log('Начало');

setTimeout(() => console.log('Таймер'), 0);

Promise.resolve()
  .then(() => console.log('Промис 1'))
  .then(() => console.log('Промис 2'));

console.log('Конец');

Многие разработчики, сталкиваясь с подобным кодом, ожидают, что таймер выполнится раньше промисов, так как он был установлен первым. Это распространённое заблуждение - первый тупик, в который попадают новички.

Почему это не работает:

setTimeout с нулевой задержкой не означает “выполнить немедленно” - он означает “добавить задачу в очередь макрозадач”
Микрозадачи, поставленные в текущей задаче, выполняются раньше любой следующей макрозадачи
Цикл событий всегда сначала выполняет все микрозадачи, прежде чем перейти к следующей макрозадаче

Правильный вывод:

Начало
Конец
Промис 1
Промис 2
Таймер

Второй тупик: попытка использовать таймеры для управления потоком выполнения

Распространённая ошибка - попытка использовать setTimeout для управления порядком выполнения асинхронных операций. Например:

function fetchData() {
  fetch('/api/data')
    .then(response => response.json())
    .then(data => {
      console.log('Данные получены');
      setTimeout(() => {
        console.log('Обработка завершена');
      }, 0);
    });
}

Разработчики часто думают, что setTimeout здесь необходим, чтобы гарантировать выполнение кода после завершения промиса. На самом деле это избыточно и создаёт ненужную задержку.

Почему это плохое решение:

Создаётся лишняя макрозадача, которая задерживает выполнение кода
Усложняется понимание потока выполнения
Может привести к race conditions при вложенных вызовах
Нарушает естественный порядок выполнения микрозадач

Правильное решение - просто продолжить цепочку промисов:

function fetchData() {
  fetch('/api/data')
    .then(response => response.json())
    .then(data => {
      console.log('Данные получены');
      return data;
    })
    .then(data => {
      console.log('Обработка завершена');
    });
}

Как задачи влияют на отрисовку интерфейса

Все микрозадачи выполняются до точки отрисовки, поэтому длинная цепочка промисов не отдаёт поток браузеру. Между двумя макрозадачами отрисовка может и не произойти. Если изменения нужно гарантированно показать до тяжёлой работы, используют requestAnimationFrame и уже в нём ставят setTimeout, либо scheduler.yield().

Рассмотрим пример долгой задачи:

function processLargeArray() {
  const largeArray = Array(1000000).fill(0);
  let sum = 0;

  for (let i = 0; i < largeArray.length; i++) {
    sum += Math.sqrt(largeArray[i]);
  }

  console.log('Обработка завершена');
}

processLargeArray();

Пока выполняется эта функция, пользователь видит замороженный интерфейс - кнопки не реагируют на нажатия, анимации не работают, страница не прокручивается.

Третий тупик: попытка использовать requestIdleCallback для долгих задач

Многие разработчики, столкнувшись с проблемой долгих задач, первым делом пытаются использовать requestIdleCallback. Например:

function processInIdle() {
  requestIdleCallback(() => {
    processLargeArray();
  });
}

На первый взгляд, это кажется хорошим решением - задача будет выполняться в периоды простоя браузера. Однако у этого подхода есть серьёзные недостатки.

Почему это не работает как ожидается:

Непредсказуемое время выполнения - задача может начаться в любой момент, когда браузер сочтёт, что у него есть свободное время
Колбэк выполняется целиком. Если внутри тяжёлая синхронная работа, интерфейс замирает так же. Проблема подхода в том, что он лишь откладывает долгую задачу и не дробит её, а без опции timeout колбэк может долго не вызываться
Отсутствие гарантий - браузер может вообще не предоставить время для выполнения задачи, если пользователь активно взаимодействует со страницей
Сложность отладки - прерывистое выполнение усложняет отладку и может приводить к неожиданным состояниям

Правильный подход - разбивать долгие задачи на части и уступать управление браузеру:

function processLargeArrayChunked() {
  const largeArray = Array(1000000).fill(0);
  let sum = 0;
  let index = 0;
  const BUDGET = 16; // бюджет одного кадра

  function processChunk() {
    const startTime = performance.now();

    while (index < largeArray.length && performance.now() - startTime < BUDGET) {
      sum += Math.sqrt(largeArray[index]);
      index++;
    }

    if (index < largeArray.length) {
      setTimeout(processChunk, 0);
    } else {
      console.log('Обработка завершена');
    }
  }

  processChunk();
}

Решение задач с собеседований: от простого к сложному

На собеседованиях часто спрашивают о порядке вывода в подобных примерах:

console.log('Начало');

setTimeout(() => console.log('Таймер 1'), 0);

Promise.resolve()
  .then(() => console.log('Промис 1'))
  .then(() => console.log('Промис 2'));

setTimeout(() => console.log('Таймер 2'), 0);

console.log('Конец');

Вывод будет таким:

Начало
Конец
Промис 1
Промис 2
Таймер 1
Таймер 2

Четвёртый тупик: попытка заучить порядок вывода

Многие разработчики пытаются запомнить порядок вывода для конкретных примеров, считая, что это поможет на собеседованиях. Однако такой подход обречён на провал.

Почему это не работает:

Любое изменение кода меняет порядок - добавление вложенного промиса, await или другой асинхронной конструкции полностью меняет картину
Невозможно запомнить все варианты - существует бесконечное количество комбинаций асинхронных операций
Не даёт понимания сути - заучивание примеров не объясняет, как на самом деле работает цикл событий
Приводит к ошибкам в реальном коде - полагаясь на заученные примеры, легко допустить ошибку в реальном проекте

Рассмотрим более сложный пример с вложенными промисами и await:

console.log('Начало');

setTimeout(() => console.log('Таймер'), 0);

Promise.resolve()
  .then(() => {
    console.log('Промис 1');
    return Promise.resolve().then(() => console.log('Вложенный промис'));
  })
  .then(() => console.log('Промис 2'));

async function asyncExample() {
  console.log('Асинхронная функция');
  await Promise.resolve();
  console.log('После await в функции');
}

asyncExample();

console.log('Конец');

Реальный вывод:

Начало
Асинхронная функция
Конец
Промис 1
После await в функции
Вложенный промис
Промис 2
Таймер

Пошаговое объяснение:

Выполняется синхронный код (Начало, Асинхронная функция, Конец)
После завершения синхронного кода выполняются микрозадачи:
- Первый промис из цепочки (Промис 1)
- Продолжение после await встало в очередь ещё во время синхронного кода, поэтому оно выполняется следующим (После await в функции)
- Вложенный промис ставится в очередь, когда выполняется колбэк “Промис 1”, поэтому он выполняется после продолжения async-функции (Вложенный промис)
- Второй промис из цепочки (Промис 2) выполняется последним среди промисов, так как возврат промиса из then добавляет лишние такты микрозадач
Браузер может обновить интерфейс
Выполняется следующая макрозадача (Таймер)

Оптимизация долгих задач

Долгие задачи блокируют интерфейс, так как браузер не может обновить кадр, пока задача не завершится. Для решения этой проблемы задачи дробят на пакеты по бюджету времени и уступают поток, а для вычислений используют Web Worker. Подробности оптимизации отзывчивости интерфейса разобраны в статье о метриках front-web-vitals.

Позиция редакции

Модель двух очередей (макрозадачи и микрозадачи) и точки обновления интерфейса достаточна для большинства прикладных задач на фронтенде. Она позволяет объяснить основные сценарии работы с асинхронным кодом и оптимизировать отзывчивость интерфейса.

Эта модель хорошо работает в следующих случаях:

При разработке пользовательских интерфейсов
При работе с сетевыми запросами
При обработке пользовательских событий
При реализации анимаций и переходов

Однако у этой модели есть ограничения, при которых она становится неверной или недостаточной:

Серверный JavaScript (Node.js) имеет более сложный цикл событий с дополнительными фазами (таймеры, I/O, проверка, закрытие). Здесь модель двух очередей не отражает всех нюансов работы event loop.
Низкоуровневая работа с event loop - если вы пишете библиотеки или фреймворки, которые напрямую взаимодействуют с циклом событий, потребуется более глубокое понимание.
Специфические браузерные реализации могут иметь особенности, не покрываемые базовой моделью. Например, некоторые браузеры могут оптимизировать выполнение микрозадач или иметь дополнительные очереди для специфических операций.
Новые API могут вводить дополнительные типы задач с собственными правилами приоритезации. Например, задачи планировщика (scheduler.postTask) или задачи отрисовки (requestAnimationFrame).

Таким образом, базовая модель хорошо подходит для объяснения принципов работы цикла событий и решения большинства практических задач на фронтенде. Однако при работе с низкоуровневым кодом или в специфических средах может потребоваться более глубокое понимание деталей реализации конкретной JavaScript-машины.

Как это устроено

Цикл событий определяет, когда выполняется код в браузере. Если интерфейс зависает или асинхронные операции срабатывают не в том порядке — ищите, где микрозадачи (промисы, queueMicrotask) блокируют отрисовку. Микрозадачи всегда выполняются раньше макрозадач, даже если таймер был установлен раньше. - Не используйте setTimeout для управления потоком — это создаёт лишние задержки. - Долгие задачи разбивайте на части, чтобы браузер успевал обновлять интерфейс. - requestIdleCallback не гарантирует выполнение и не решает проблему зависания.

Чем это обойдётся

Цикл событий — не абстракция, а рабочий инструмент. Если в команде путают порядок выполнения промисов и таймеров, ошибки будут накапливаться в продакшене. Исправлять их постфактум дороже, чем объяснить механику один раз: потребуется внутренний воркшоп с разбором реальных примеров из вашего кода. - Микрозадачи (промисы) всегда выполняются раньше макрозадач (таймеры, события DOM) — смешивание в одной цепочке приводит к race conditions. - Долгие синхронные операции блокируют интерфейс: разбивайте их на части, чтобы отдавать управление браузеру. - Не используйте setTimeout(..., 0) для управления потоком — это создаёт лишние задачи и замедляет выполнение. - Решение принимайте после аудита: если асинхронные ошибки встречаются часто, обучение окупится быстрее, чем исправление багов в продакшене.

Цикл событий в JavaScript простыми словами

Цикл событий в JavaScript: от очередей к отзывчивому интерфейсу

Анатомия цикла событий: стек, очереди и микроочереди

Почему микрозадачи выполняются раньше макрозадач: типичный тупик

Второй тупик: попытка использовать таймеры для управления потоком выполнения

Как задачи влияют на отрисовку интерфейса

Третий тупик: попытка использовать requestIdleCallback для долгих задач

Решение задач с собеседований: от простого к сложному

Четвёртый тупик: попытка заучить порядок вывода

Оптимизация долгих задач

Позиция редакции

С чем это связано

Асинхронность: что она ускоряет, а что нет

Core Web Vitals: что действительно двигает оценку

Состояние в React: когда нужна библиотека, а когда нет

Асинхронность: что она ускоряет, а что нет

Цикл событий в JavaScript простыми словами

Цикл событий в JavaScript: от очередей к отзывчивому интерфейсу

Анатомия цикла событий: стек, очереди и микроочереди

Почему микрозадачи выполняются раньше макрозадач: типичный тупик

Второй тупик: попытка использовать таймеры для управления потоком выполнения

Как задачи влияют на отрисовку интерфейса

Третий тупик: попытка использовать requestIdleCallback для долгих задач

Решение задач с собеседований: от простого к сложному

Четвёртый тупик: попытка заучить порядок вывода

Оптимизация долгих задач

Позиция редакции

С чем это связано

Асинхронность: что она ускоряет, а что нет

Core Web Vitals: что действительно двигает оценку

Состояние в React: когда нужна библиотека, а когда нет

Асинхронность: что она ускоряет, а что нет

Письмо по вторникам