Как TypeScript влияет на производительность в продакшн
Что проверяют
Понимаете ли вы, что типы TypeScript исчезают при сборке и в браузер попадает обычный JavaScript. Интервьюер ждёт, что вы отделите рантайм от времени сборки и назовёте места, где TypeScript всё же оставляет след в бандле. Следом часто спрашивают про проверку данных с сервера.
Как отвечать
Прямого влияния на скорость в браузере нет: V8 типов не видит и ничего по ним не оптимизирует. Сегодня типы чаще вырезает не tsc, а esbuild, SWC или Babel, а tsc --noEmit только проверяет. След остаётся в нескольких местах:
target: чем старее цель, тем больше переписывания.async/awaitи классы под ES5 превращаются в громоздкие хелперы, бандл растёт. Для современных браузеров цель ES2020 и выше почти ничего не меняет;- синтаксис с рантаймом: обычный
enum,namespace, параметры-свойства в конструкторе и декораторы генерируют код. ФлагerasableSyntaxOnly(TypeScript 5.8) запрещает такой синтаксис, и типы остаётся просто стереть; - хелперы: без
importHelpersиtslibвспомогательные функции копируются в каждый модуль; - сборка: полная проверка типов в большом монорепо идёт минутами, но это время CI, а не пользователя. Помогают
incremental, project references и нативный компилятор на Go, который команда TypeScript развивает как TypeScript 7.
Косвенный эффект есть: меньше ошибок вида undefined is not a function доезжает до пользователя. Но это про надёжность, а не про скорость. И важная оговорка: типы не проверяют данные в рантайме. Ответ fetch, приведённый через as User, может оказаться чем угодно, поэтому на границах системы нужна схема вроде Zod или Valibot, а она уже тратит процессорное время.
Где спотыкаются
Говорят, что статические типы ускоряют код, потому что «компилятор знает типы». tsc не оптимизирует, он проверяет и транспилирует.
Не знают, что обычный enum превращается в объект в бандле, а const enum плохо дружит с isolatedModules, на котором построены Vite и esbuild.
Путают безопасность типов с гарантиями в рантайме и верят as на данных из сети.