Frontend интервью: 18 вопросов по браузеру, сети, производительности и архитектуре

Введение

Ранее написанные frontend-опросники упирались в React: useEffect, ререндеры, формы, роутинг, memoization, тесты компонентов. Получается что этот слой уже закрыт в подборке по Junior React и нескольких более узких материалах. Ниже другая часть frontend-интервью: браузер как среда выполнения, сеть как ограничение, main thread как дефицитный ресурс, кэш как источник ускорения и багов, а delivery как вопрос надежности.

Эти 18 вопросов подобраны так, чтобы не дублировать уже опубликованные React-опросники. Поэтому здесь нет пересказа props/state, hooks, controlled vs uncontrolled, React Query, Playwright или TypeScript generics. Вместо этого фокус на том, где кандидата проверяют на инженерное мышление: понимает ли он путь запроса, цену рендеринга, модель кэширования, угрозы браузерной безопасности и компромиссы между скоростью разработки и устойчивостью продукта.

Как читать эту подборку

Ниже вопросы собраны не по библиотекам, а по зонам ответственности frontend-инженера.

Блок	Что реально проверяют	Где чаще теряют баллы
Браузер и рендеринг	Понимаете ли вы, когда UI становится видимым и интерактивным	Смешивают parse, paint, hydration и обработку событий
Сеть и кэш	Умеете ли вы снижать задержку и объяснять поведение браузера	Путают HTTP cache, CDN cache и cache в Service Worker
Безопасность	Видите ли вы угрозы на клиентской границе	Отвечают списком терминов без модели атаки
Производительность	Умеете ли вы искать узкое место, а не оптимизировать наугад	Сводят все к useMemo или tree shaking
Архитектура и delivery	Понимаете ли вы, как фронтенд живет в production	Игнорируют rollout, rollback, flags, observability

Архитектура frontend-системы: где проходит критический путь

На интервью сильный frontend-ответ почти всегда начинается не с фреймворка, а с пути пользователя:

1. Браузер получает HTML, JS, CSS, шрифты и данные.
2. Сеть, DNS, TLS, CDN и кэш влияют на момент первого байта.
3. Парсер и загрузчик строят критический путь рендеринга.
4. Main thread тратит время на parse, execute, layout, paint и обработку событий.
5. Уже после первого экрана приложение продолжает жить под давлением данных, аналитики, feature flags и сторонних скриптов.

Если смотреть на систему в этой последовательности, многие вопросы из статьи становятся связными. Например, плохой Cache-Control увеличивает сетевую цену. Тяжелый bundle удлиняет parse и execute. Сторонний скрипт бьет по INP. Ошибка в CSP ломает виджеты или, наоборот, открывает лишнюю поверхность для XSS. Слишком грубый rollout превращает релиз фронтенда в лотерею.

В этом смысле frontend-архитектура ближе к системному дизайну, чем кажется. Смежную картину полезно держать рядом со статьей про system design для frontend-разработчика, но здесь мы идем через короткие interview-вопросы, а не через одну большую задачу.

18 вопросов по frontend без повторов React-опросников

Вопрос 1. Что именно происходит между вводом URL и первым видимым экраном?

Сильный ответ должен пройти по цепочке: DNS, TLS, HTTP-запрос, ответ с HTML, разбор документа, загрузка критических ресурсов, построение DOM и CSSOM, layout, paint, а затем уже выполнение клиентского JavaScript. Ошибка большинства кандидатов в том, что они перескакивают сразу к “браузер рендерит страницу”, не разделяя сетевую и вычислительную части.

На практике этот вопрос проверяет, умеете ли вы локализовать проблему. Если TTFB высокий, причина обычно не в bundle. Если HTML приходит быстро, но интерактивность поздняя, узкое место может быть уже в JS, hydration или сторонних скриптах. Для React-проектов этот слой потом стыкуется с разбором hydration после SSR, но сам вопрос шире любого фреймворка.

Вопрос 2. Почему CSS иногда блокирует отображение, хотя он “не код”?

Потому что браузеру нужен CSSOM, чтобы корректно посчитать layout и paint. Если критические стили еще не загружены, браузер часто не хочет показывать промежуточный, визуально неверный экран. Поэтому CSS на критическом пути может быть не менее важен, чем JS.

Сильный ответ звучит так: “CSS не блокирует сеть магически, но может блокировать рендеринг нужного участка страницы, потому что без стилей браузер не знает финальную геометрию и визуальное состояние”. Это полезнее, чем общий тезис “CSS влияет на отображение”.

Вопрос 3. Чем отличаются preload, prefetch и preconnect?

preconnect заранее готовит соединение: DNS, TCP, TLS. preload говорит браузеру, что конкретный ресурс скоро понадобится на текущем маршруте и его надо тянуть приоритетно. prefetch обычно относится к будущей навигации и имеет более низкий приоритет.

На production-проекте ошибка в этих механизмах дорогая. Избыточный preload может конкурировать с действительно критическими ресурсами. Случайный prefetch тяжелых чанков при слабой сети легко превращается в лишний расход трафика. Для смежной темы держите рядом разбор code splitting и lazy loading, где хорошо видно, что приоритет загрузки не менее важен, чем сама разбивка по чанкам.

Вопрос 4. В чем разница между Cache-Control, ETag и кэшем в Service Worker?

Cache-Control и ETag относятся к HTTP-модели кэширования между браузером и сервером. Они определяют, можно ли использовать локальную копию и нужно ли валидировать ресурс повторно. Service Worker живет на другом уровне: это программируемый прокси в браузере, который может сам решать, как обслуживать запрос.

Самая частая ошибка на интервью: описывать все три механизма как “кэш браузера”. Это разные уровни контроля. HTTP-кэш проще и безопаснее для статики. Service Worker мощнее, но опаснее: он добавляет собственную логику инвалидации, офлайн-режим, fallback и новые точки отказа.

Вопрос 5. Как CDN меняет поведение frontend-приложения, кроме ускорения статики?

CDN уменьшает сетевую задержку до пользователя, снимает часть нагрузки с origin, кэширует статику ближе к региону пользователя и помогает стабилизировать выдачу при всплесках трафика. Но с ним появляются и новые риски: неочевидная инвалидация, устаревшие ассеты на edge-нодах, рассинхронизация HTML и JS после релиза.

Сильный ответ обычно включает кейс: “Если HTML уже указывает на новый хэшированный bundle, а часть CDN-узлов еще держит старую картину или origin обновился неатомарно, пользователь может поймать 404 на чанк”. Это уже инженерный ответ, а не пересказ определения CDN.

Вопрос 6. Чем CORS отличается от CSRF, и почему их часто путают?

CORS регулирует, может ли браузер читать ответ другого origin в рамках политики безопасности. Это правило доступа к ответу. CSRF — это атака, где браузер жертвы отправляет доверенный запрос от имени пользователя, например с cookies, на другой сайт. Это уже вопрос подделки межсайтового запроса.

Именно поэтому “включим CORS и защитимся от CSRF” — неверная формулировка. Эти механизмы закрывают разные риски. Сильный кандидат обычно проговаривает, что CSRF связан с доверенной аутентификацией на основе cookies и защищается через SameSite, CSRF-token и корректную модель сессии.

Вопрос 7. Что такое CSP и зачем она frontend-команде, если XSS “чинят в коде”?

CSP — это дополнительный уровень защиты, который ограничивает, откуда страница может загружать и выполнять скрипты, стили, изображения и другие ресурсы. Она не заменяет безопасный рендеринг данных, но уменьшает blast radius, если уязвимость все же проскочила.

На интервью хороший ответ не сводится к “ставим заголовок и все”. Надо проговорить tradeoff: слишком строгая политика ломает аналитику, A/B-инструменты, сторонние виджеты и inline-скрипты, а слишком мягкая почти ничего не защищает.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-r4nd0m';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  connect-src 'self' https://api.example.com;
  frame-ancestors 'none';
  base-uri 'self';

Такой пример полезен не как идеальный шаблон, а как демонстрация модели: вы явно перечисляете доверенные источники и не полагаетесь на “раз браузер загрузил, значит можно”.

Вопрос 8. Что сильнее всего бьет по INP и почему long tasks опаснее, чем кажутся?

INP страдает, когда main thread занят слишком долго и не может быстро обработать пользовательское действие. Причиной могут быть тяжелые вычисления, синхронный парсинг больших структур, дорогой layout, сторонние скрипты, реконсиляция крупного дерева или каскад событий после ввода.

Сильный ответ здесь всегда отделяет симптом от причины. Низкий INP — не “проблема кнопки”. Это сигнал, что у вас перегружен критический поток обработки событий. Для соседней темы производительности полезен разбор React profiling и поиска узких мест, но сам принцип одинаков и вне React.

Вопрос 9. Когда Web Worker действительно помогает, а когда это ложная оптимизация?

Worker полезен, когда есть тяжелая CPU-работа, которую можно вынести с main thread: парсинг больших данных, вычисления, компрессия, трансформация документов, fuzzy search, обработка графов. Он почти не помогает, если узкое место в сети, DOM, layout или в слишком частых перерисовках UI.

Слабый ответ звучит так: “Если все тормозит, вынесем в worker”. Сильный: “Worker снимает давление с main thread, но добавляет стоимость сериализации сообщений, отдельную архитектуру обмена и не умеет напрямую трогать DOM”.

// worker.ts
self.onmessage = (event: MessageEvent<{ values: number[] }>) => {
  const total = event.data.values.reduce((sum, value) => sum + value, 0);
  self.postMessage({ total });
};

// main.ts
const worker = new Worker(new URL("./worker.ts", import.meta.url), {
  type: "module",
});

worker.postMessage({ values: hugeArray });
worker.onmessage = (event: MessageEvent<{ total: number }>) => {
  renderTotal(event.data.total);
};

Такой пример показывает главное: worker не “ускоряет код”, а перераспределяет нагрузку между потоками.

Вопрос 10. Что такое критический путь рендеринга и что в нем обычно оптимизируют первым?

Критический путь рендеринга — это цепочка ресурсов и операций, без которых нельзя показать полезный экран. Обычно сначала смотрят на HTML, критический CSS, шрифты, основные изображения и минимальный JS, который нужен именно первому экрану.

Частая ошибка кандидатов — начинать с мелких micro-оптимизаций внутри приложения, когда страница еще проигрывает до первого meaningful paint. Если у пользователя на старте 900 КБ JS и три блокирующих шрифта, разговор про мемоизацию вторичен.

Вопрос 11. Что такое правильная стратегия code splitting и почему “много чанков” не всегда лучше?

Цель code splitting не в максимальном числе файлов, а в уменьшении стоимости текущего пользовательского пути. Слишком крупный bundle плохо для старта. Слишком мелкая нарезка создает много запросов, дополнительные зависимости и более сложную деградацию при ошибке загрузки чанка.

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

Вопрос 12. Чем source maps полезны и почему они иногда становятся риском?

Source maps резко упрощают диагностику production-ошибок: по ним читаются реальные стеки вызовов, видно исходные имена модулей и строк. Но если выкладывать их бесконтрольно в публичный доступ, вы облегчаете жизнь не только своей команде, но и атакующему: структура проекта, внутренние имена, скрытые пути и иногда комментарии становятся легче для анализа.

Сильный ответ не требует запрета source maps вообще. Обычно зрелый вариант такой: maps нужны, но доступ к ним должен контролироваться, например через error monitoring-платформу или закрытый storage, а не как публичный ассет.

Вопрос 13. Что такое feature flag во frontend и как не превратить его в вечный технический долг?

Feature flag позволяет выкатывать поведение поэтапно: по окружению, проценту пользователей, сегменту или роли. Это снижает риск релиза и дает путь быстрого rollback без нового деплоя. Но если не удалять старые флаги, они превращаются в скрытую ветвистость продукта.

Зрелый ответ всегда включает lifecycle. У флага должна быть цель, владелец, дата удаления и понятный default-path. Иначе через несколько месяцев одна страница живет в четырех несовместимых режимах, а тестирование и debugging становятся резко дороже.

Вопрос 14. Когда microfrontend-архитектура оправдана, а когда это дорогая ошибка?

Она оправдана, когда у вас действительно много независимых команд, разные темпы релизов, жесткие границы ответственности и организационная цена единой кодовой базы выше технической цены интеграции. Во всех остальных случаях microfrontend легко превращается в дубли UI-kit, разъехавшиеся зависимости, лишний runtime и неровный UX.

Сильный ответ не романтизирует подход. Он признает, что microfrontend — это не про “модно”, а про компромисс между автономией команд и целостностью продукта.

Сравнение архитектурных подходов

Подход	Где помогает	Главная цена	Когда выбирать
Один монолитный frontend	Простая поставка, единые зависимости, быстрый onboarding	Конфликты команд и тяжелые релизы при росте	Небольшая или средняя команда
Модульный монолит	Ясные границы, но единый pipeline	Нужна дисциплина архитектуры	Большинство зрелых продуктов
Microfrontends	Автономия крупных команд	Дублирование инфраструктуры и сложный UX	Очень большой продукт и орг-сложность
SSR/SSG для части маршрутов	Быстрый первый экран и SEO	Сложнее инфраструктура и клиентские границы	Контентные и маркетинговые зоны
Islands/server-first подход	Ниже цена клиентского JS	Более сложная модель разработки	Когда интерактивность нужна не везде

Практический вывод простой: хороший frontend-дизайн почти всегда начинается с модульного монолита, а не с максимальной распределенности. Дальше архитектура усложняется только под реальное давление команды, трафика или продукта.

Вопрос 15. Как выстроить frontend-observability, а не только ловить ошибки в консоли?

Нужны как минимум четыре слоя: runtime errors, web vitals, бизнес-критичные технические события и release context. Иначе вы видите, что “что-то сломалось”, но не знаете у какого релиза, на каком браузере, в какой сети и после какого пользовательского действия.

Сильный ответ обычно перечисляет конкретику: LCP, INP, CLS, error rate по релизу, route change timing, failed chunk load, API latency на клиенте, процент rollback по флагу. Именно такие сигналы позволяют спорить не мнением, а данными.

Вопрос 16. Как понять, что проблема в сети, а не в UI?

Надо смотреть на waterfall и разделять этапы: DNS/TLS/TTFB, download, parse, execute, render, user interaction. Если ответ API приходит медленно, UI часто вообще ни при чем. Если API быстрый, а экран зависает после ответа, тогда узкое место уже в клиенте: парсинг, нормализация, layout, перерисовка или сторонние эффекты.

На интервью полезно проговаривать именно эту последовательность. Она показывает, что вы не лечите симптом по наитию.

Вопрос 17. Что такое надежный rollout фронтенда и почему “задеплоили в пятницу” — не стратегия?

Надежный rollout — это не только CI/CD, но и последовательность мер: canary, feature flags, совместимость старого HTML с новым JS, контроль кэшей, быстрый rollback, мониторинг после релиза и ограничение blast radius. Для frontend это особенно важно из-за кэшируемой статики и распределенной доставки через CDN.

Типовая production-ошибка: выкатить новый frontend, не учесть старые вкладки пользователя, старые чанки в браузерном кэше и переходы между версиями. В аналитике это всплывает как ChunkLoadError, белые экраны и резкий всплеск ошибок сразу после релиза.

Вопрос 18. Как на интервью отвечать на “общий frontend-вопрос”, чтобы не звучать учебником?

Рабочая схема обычно такая:

1. Сначала определяете слой: браузер, сеть, кэш, main thread, безопасность, доставка (delivery).
2. Затем объясняете, какой риск или ограничение этот слой создает.
3. Потом показываете tradeoff: что выигрываем и чем платим.
4. Заканчиваете коротким production-примером.

Например, вместо ответа “Service Worker нужен для офлайна” лучше сказать: “Service Worker полезен, когда мы хотим контролировать стратегию ответа на сетевой запрос и переживать плохую сеть, но он добавляет собственный слой кэширования и усложняет инвалидацию, поэтому для обычной статики сначала я бы выжал HTTP cache и CDN”.

Ошибки на практике

Самые частые ошибки на этом слое повторяются из проекта в проект:

• Команда оптимизирует React-дерево, хотя проблема в TTFB, CDN или блокирующих ресурсах.
• Стратегия кэширования не согласована с релизами, из-за чего пользователи ловят старый HTML и новые чанки или наоборот.
• В проект бесконтрольно добавляют сторонние скрипты, и они тихо съедают INP и стабильность main thread.
• CSP и security headers включают слишком поздно, уже после накопления внешних зависимостей, которые невозможно быстро сократить.
• Feature flags не удаляют, и frontend годами живет в ветвистой логике с неочевидным поведением.

По логам и метрикам это обычно видно заранее: всплеск ChunkLoadError, ухудшение INP на слабых устройствах, рост client-side error rate после релиза, скачки LCP по сегментам сети, увеличившийся объем JS на route-level.

Best practices

• Измеряйте путь пользователя по этапам, а не обобщенным ощущением “страница тормозит”.
• Используйте явную модель кэширования в явной модели: что решает HTTP, что решает CDN, что решает приложение.
• Ограничивайте main thread как дефицитный ресурс, особенно на слабых устройствах.
• Выкатывайте крупные frontend-изменения через flags и понятный rollback-сценарий.
• Считайте сторонние скрипты частью архитектурного бюджета, а не бесплатным дополнением.
• Удаляйте временные решения: старые флаги, legacy polyfills, лишние preloads, неиспользуемые чанки.

Частые ошибки

• Отвечать определением без объяснения причинно-следственной связи.
• Путать браузерный кэш, кэш CDN и кэш приложения.
• Считать, что безопасность фронтенда сводится к “не использовать dangerouslySetInnerHTML”.
• Искать performance-проблему только в коде компонента и игнорировать сеть, шрифты и third-party.
• Предлагать Web Worker, microfrontend или Service Worker как универсальное средство от любой боли.

Как отвечать на интервью

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

Если вопрос широкий, полезно явно сузить рамку: “Я отвечу со стороны браузера и delivery”, “Я разделю проблему на сеть и main thread”, “Я бы сначала определил, где источник истины у кэша”. Такие формулировки звучат взрослее, чем быстрый поток определений.

FAQ

Нужно ли frontend-разработчику знать такие темы, если основной стек — React?

Да. React не отменяет устройство браузера, сети, кэша, CSP, CDN и механики релиза. На больших проектах именно эти слои часто определяют надежность системы сильнее, чем локальная компонентная логика.

Какие из этих вопросов чаще всего задают на middle и senior интервью?

Обычно про кэширование, performance, CSP/XSS, critical rendering path, CDN, observability, rollout и архитектурные компромиссы. Чем выше уровень, тем меньше интервьюеру интересен синтаксис и тем больше — модель принятия решений.

Что из этого особенно полезно потренировать вслух?

Разницу между типами кэша, путь запроса до первого экрана, модель INP и long tasks, отличие CORS от CSRF, смысл CSP и критерии выбора между модульным монолитом и microfrontend.

Итоги

Этот опросник закрывает тот кусок frontend, который обычно выпадает из React-подготовки: браузерная среда, сеть, кэш, безопасность, performance и delivery. Если проговорить все 18 вопросов без шпаргалки, у вас уже будет сильная база для middle/senior-разговора даже в тех командах, где фреймворк меняется, а инженерные ограничения остаются теми же.