Primer Design System лежит в основе многих интерфейсов, которые вы видите на GitHub сегодня. От кнопок до баннеров и хлебных крошек — эти базовые компоненты должны быть доступны, гибки и производительны в самых разных сценариях.
Еще в 2023 году количество компонентов на определенных страницах начало стремительно расти. Это привело к ряду проблем с производительностью в рамках нашего текущего решения CSS-in-JS:
- Первоначальная загрузка страниц занимала больше времени из-за инициализации стилей на клиенте
- Производительность серверного рендеринга снизилась, так как сбор стилей сместился с клиента
- Обновления стилей вышли из-под контроля по мере роста количества компонентов на странице
Стало очевидно, что команде Primer необходимо решить эту проблему у истоков. Нам нужно было найти альтернативу, которая полностью исключила бы затраты на стороне клиента и сервера, наблюдаемые с нашим текущим решением. Самое главное, любая выбранная нами альтернатива должна была работать так, чтобы избежать любых сбоев в работе GitHub во время миграции.
Представляем CSS (Modules)
Команда Primer нашла решение, отвечающее всем нашим критериям: CSS Modules. Этот формат позволил бы нам делать то, что мы любим больше всего: писать и использовать нативные возможности CSS, сохраняя при этом определенный уровень совместного размещения и инкапсуляции, к которому мы привыкли в CSS-in-JS.
С помощью CSS Modules стили создаются в файле CSS рядом с исходным кодом JavaScript для компонента. Это также позволяет нам обрабатывать все имена классов как локальные по умолчанию, предотвращая некоторые коллизии и проблемы, возникающие из-за глобальных селекторов. Этот формат также устраняет необходимость в каком-либо времени выполнения на клиенте или сервере. Вместо этого стили объединяются в таблицы стилей CSS, которые отправляются как часть HTML страницы.
Однако это решение кардинально отличалось от имевшегося у нас тогда CSS-in-JS. Это изменение потребовало бы обновления каждого компонента Primer и каждого компонента на GitHub, созданного с использованием этого подхода. К счастью, дизайн-системы — идеальный инструмент для масштабного внедрения такого рода изменений.
Постепенный переход к CSS Modules
Ситуация с переходом на CSS Modules была ясна. Команде Primer нужно было подготовить обновления для каждого из своих компонентов, переведя их с CSS-in-JS на CSS Modules. В то же время обновления, которые мы вносили в эти компоненты, не должны были нарушать их использование на GitHub. Наконец, базовый метод, который мы использовали для CSS-in-JS, также должен был продолжать работать для любых компонентов на GitHub, которые в данный момент его использовали.
Учитывая все эти ограничения, мы остановились на стратегии инкрементальной миграции, которая позволила бы нам безопасно выпускать обновления компонентов, не разрушая экосистему. Для каждого компонента наш план заключался в следующем:
- Добавить новый файл, который преобразует существующие стили в CSS Modules
- Добавить компонент в список управляемых флагом функций (feature flag), который переключает старые и новые стили
- Использовать существующие тесты визуальной регрессии для проверки идентичности снимков между нашим решением CSS-in-JS и CSS Modules
- Постепенно внедрять флаг функции для нашей команды, затем для сотрудников GitHub и, наконец, для всех пользователей GitHub, чтобы выявлять любые проблемы по ходу дела
Этот процесс создал прочную обратную связь: проблемы выявлялись на ранних этапах, поскольку Primer непрерывно доставляла эти изменения на GitHub. Использование флагов функций позволило нам выполнить эту миграцию безопасно, одновременно предоставив четкие данные о преимуществах CSS Modules в производительности.
К декабрю 2024 года все компоненты в Primer были перенесены на CSS Modules с использованием этого процесса. Мы увидели рост производительности по всем направлениям, в частности:
- Требуется на 55% меньше времени для серверного рендеринга страницы
- Требуется на 25% меньше времени для инициализации компонентов на странице
Увидев явный прирост производительности от этой работы в Primer, мы начали задаваться вопросом, сможем ли мы добиться аналогичного прироста производительности, выполнив такие преобразования в других частях GitHub. И в то же время, сколько времени пройдет, прежде чем мы сможем окончательно отказаться от поддержки CSS-in-JS в масштабах всей компании?
Отказ от CSS-in-JS на GitHub
Одной из самых сложных частей удаления нашего решения CSS-in-JS из Primer было использование пропса sx. Этот пропс был способом стилизации и кастомизации компонентов из Primer. Команды могли передавать инлайн-объект для настройки абсолютно всего в компоненте. Он воплощал в себе лучшие и худшие стороны CSS-in-JS:
- Отличная поддержка TypeScript с интеграцией наших Design Tokens
- Совместное размещение с компонентом, так что все находится в одном месте
- Высокие накладные расходы во время выполнения из-за динамической природы инлайн-объектов, используемых для sx
- Сложности масштабирования по мере роста количества компонентов, использующих sx на странице
В результате первым этапом нашего пути по отказу от CSS-in-JS стало сокращение использования sx на GitHub. Это позволило бы нам немедленно повысить производительность, аналогично тому приросту, который мы наблюдали при миграции компонентов Primer. Это также отлично подготовило нас к полному удалению CSS-in-JS из продукта.
Двойственность Primer
Важно отметить, что, хотя сама дизайн-система официально отказалась от styled-components, большая часть кодовой базы самого GitHub — нет. Поскольку пропсы sx были де-факто стандартом стилизации на GitHub в течение многих років, нам предстояло перенести тысячи таких пропсов, прежде чем мы смогли бы даже подумать о переводе GitHub на новую изящную версию @primer/react, которая не зависела от styled-components.
Итак… как мы проделали эту огромную работу, повысив уверенность и снизив риски? Ответ: не все сразу.
Первоначальная миграция CSS была немного сложнее, чем мы описывали: помимо миграции компонентов на CSS modules, настройки флагов функций для тестирования в продакшене и их постепенного внедрения, мы также создали «оберточные» компоненты в транзитивной библиотеке, которую мы назвали @primer/styled-react. Вся цель этого пакета заключалась в том, чтобы разрешить использование sx в недавно мигрированных компонентах. Таким образом, те части кодовой базы пользовательского интерфейса GitHub, которые использовали этот пропс, могли продолжать работать с ними, импортируя тот же компонент через @primer/styled-react, в то время как мы получали прирост производительности от прямого импорта из @primer/react для остальных случаев.
Styled Box Zero
Следующий этап процесса миграции выглядел следующим образом:
- Для каждого пакета: перевести все использование sx в эквивалентные файлы CSS modules. Сюда входило сопоставление перекрестных ссылок (см. миграция на переменные CSS), замена импортов @primer/styled-react на импорты @primer/react, тестирование в предпродакшене и развертывание
- Перевести все использование sx в эквивалентные файлы CSS modules. Сюда входило сопоставление перекрестных ссылок (см. миграция на переменные CSS)
- Заменить импорты @primer/styled-react на импорты @primer/react
- Протестировать в предпродакшене
- Развернуть
Как ни странно, как раз когда мы готовились предпринять это масштабное усилие, было объявлено о переходе styled-components в режим поддержки, что стало еще одним подтверждением того, что мы движемся в правильном направлении.
Работа началась в апреле 2025 года с пиковым объемом около 7760 свойств sx для миграции; завершение этого процесса ожидалось лишь к маю 2026 года. Сначала один из наших замечательных штатных разработчиков, Ian Sanders, создал плагин для VS Code, который помогал с миграцией отдельных свойств. Аналогичный кодомод был разработан внутри компании и использовался для миграции целых файлов в кодовой базе GitHub. Эта работа, хотя и требовала некоторого ручного контроля и тщательной проверки, была в основном автоматизирована. Команда из 8 инженеров поочередно мигрировала 6419 свойств в течение 6 месяцев, зафиксировав прирост производительности времени рендеринга на стороне сервера от 1% до 22% на некоторых страницах.
В другой части GitHub возможности Copilot росли по экспоненте. ИИ становился умнее, функциональнее; пока эта работа еще продолжалась, мы выпустили агента программирования Copilot и инструмент проверки кода Copilot.
К моменту, когда мы возобновили эту работу в апреле 2026 года, ситуация изменилась: силами двух инженеров, при поддержке неустанной решимости и большого количества агентов программирования Copilot, нам удалось сократить количество свойств sx с 895 до нуля всего за три недели.
Битва тем
Это был великий день: мы наконец завершили миграцию свойств sx, стоявших между нами и полным удалением styled-components, которое готовилось годами… теперь-то мы наконец сможем очистить эти зависимости и перейти к другой, более интересной работе, верно? А вот и нет!
GitHub поддерживает семь различных тем, каждая из которых предлагает вариант режима с высокой контрастностью. Все это реализовано с помощью — вы угадали — styled-components. Прежде чем мы сможем даже подумать об удалении этих зависимостей, нам необходимо отвязать нашу систему тем.
Впрочем, это не так страшно, как звучит. Наши переменные тем всегда определялись в CSS через наш пакет @primer/css, и мы заранее заложили поддержку тем без использования styled-components при миграции @primer/react в конце 2025 года. Нам нужно было удалить именно использование JavaScript и утилиты, предоставляемые styled-components. И мы снова взялись за работу.
Вы уже знаете процедуру: выполнить миграцию, постепенно внедрить изменения, использовать фрейги функций для всего. Спустя два месяца и несколько небольших трудностей мы дали зеленый свет удалению зависимостей; даже это мы обернули фрейгом функций. Береженого бог бережет.
Все хорошо, что хорошо кончается
По состоянию на июнь 2026 года GitHub полностью работает на CSS-модулях. Меры предосторожности, которые мы приняли, позволили нам безопасно внедрить масштабные архитектурные изменения, провести стресс-тестирование в продакшене, оперативно обнаруживать ошибки, перестраиваться и устранять их, что в конечном итоге позволило нам достичь поставленных целей и добиться значительного прироста производительности.
То, что поначалу казалось миграцией CSS, обернулось постепенной реплатформенностью того, как GitHub стилизует, оформляет темами и доставляет пользовательский интерфейс в больших масштабах. В итоге мы не только удалили sx, styled-components и styled-system из dotcom, но и сделали это, не сломав сам GitHub в процессе. Повышение производительности, улучшение пользовательского опыта и удобства наших продуктов остаются главными приоритетами для всех нас здесь, в GitHub.
Теги:
- автоматизация
- CSS
- дизайн-системы
- инженерия производительности
- Primer
- скрипты
Автор статьи
Джош Блэк (Josh Black) — инженер-программист из Остина, штат Техас. Он любит работать над дизайн-системами, создавать доступные интерфейсы и есть чилакилес.
Мари — инженер-программист команды GitHub Primer из Атланты. Если она не двигает пиксели, то, вероятно, заталкивает ручную кладь на верхнюю полку самолета где-то над Атлантикой.
Узнайте больше от GitHub
Документация
Все необходимое для освоения GitHub в одном месте.
GitHub
Создавайте будущее на GitHub — платформе, где каждый и откуда угодно может создать что угодно.
Истории клиентов
Познакомьтесь с компаниями и инженерными командами, которые создают продукты с помощью GitHub.
GitHub Universe 2026
Присоединяйтесь к нам 28–29 октября в Сан-Франциско или онлайн на GitHub Universe — нашей флагманской конференции для разработчиков, объединяющей людей, агентов и мировой код.
