Повышение производительности сайта за счет отправки большего количества CSS25.09.2026 18:00

Дизайн-система Primer лежит в основе многих интерфейсов, которые вы сегодня видите на GitHub. От кнопок и баннеров до «хлебных крошек» — эти базовые компоненты должны быть доступны, гибки и производительны в самых разных сценариях.

Еще в 2023 году количество компонентов на определенных страницах начало стремительно расти. Это привело к ряду проблем с производительностью в нашем текущем решении CSS-in-JS:

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

Стало очевидно, что команде Primer нужно решать проблему у истоков. Нам требовалось найти альтернативу, которая позволила бы полностью избежать накладных расходов на стороне клиента и сервера, с которыми мы столкнулись в текущем решении. Что еще важнее, выбранная альтернатива должна была работать так, чтобы не сломать GitHub в процессе миграции.

Знакомьтесь: CSS (Modules)

Команда Primer нашла решение, отвечающее всем нашим критериям: CSS Modules. Этот формат позволил нам заниматься любимым делом: писать и использовать нативные возможности CSS, сохраняя при этом ту локализацию и инкапсуляцию, к которой мы привыкли в CSS-in-JS.

При использовании CSS Modules стили создаются в файле CSS рядом с JavaScript-исходниками компонента. Это также позволяет обрабатывать все имена классов как локальные по умолчанию, предотвращая конфликты и проблемы, которые могут возникать из-за глобальных селекторов. Кроме того, такой формат избавляет от необходимости использовать какое-либо клиентское или серверное исполняемое окружение (runtime). Вместо этого стили объединяются в таблицы стилей 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 flags), переключающую новые и старые стили.
• Использовать существующие тесты визуальной регрессии для проверки идентичности снимков экрана (скриншотов) между нашим решением 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 благодаря интеграции с нашими дизайн-токенами.
• Расположение рядом с компонентом (co-location), благодаря чему все находится в одном месте.
• Высокие накладные расходы на выполнение из-за динамической природы инлайн-объектов, используемых для sx.
• Проблемы с масштабированием по мере роста количества компонентов на странице, использующих sx.

В результате первым шагом на пути отказа от CSS-in-JS стало сокращение использования sx по всему GitHub. Это позволило бы сразу улучшить производительность — аналогично тому, как это было при миграции компонентов Primer. Кроме того, это создало идеальную основу для полного удаления CSS-in-JS из продукта.

Дуализм Primer

Важно отметить, что хотя сама дизайн-система официально отказалась от styled-components, большая часть кодовой базы самого GitHub — нет. Поскольку пропсы sx годами были де-факто стандартом стилизации на GitHub, нам предстояло перенести тысячи пропсов sx, прежде чем мы смогли бы даже задуматься о переводе GitHub на новую изящную версию @primer/react, которая не зависела от styled-components.

Итак… как же мы проделали этот огромный объем работы, повысив уверенность и снизив риски? Ответ: не все сразу.

Изначальная миграция CSS была немного сложнее, чем казалось на первый взгляд: помимо перевода компонентов на CSS-модули, использования флажков функций для тестирования в продакшене и плавной раскатки, мы также создали компоненты-«обертки» в промежуточной библиотеке под названием @primer/styled-react. Вся суть этого пакета заключалась в том, чтобы разрешить использование sx в недавно мигрированных компонентах. Таким образом, те участки кодовой базы пользовательского интерфейса GitHub, где применялся этот пропс, могли продолжать использовать его, импортируя тот же компонент через @primer/styled-react. В то же время мы получали прирост производительности от импорта напрямую из @primer/react там, где этот пропс был не нужен.

Styled Box Zero

Следующий этап процесса миграции выглядел следующим образом:

• Для каждого пакета в отдельности:
  • Преобразовать все варианты использования sx в эквивалентные файлы CSS-модулей (включая перекрестные ссылки — см. руководство по миграции на CSS-переменные).
  • Заменить импорты @primer/styled-react на импорты @primer/react.
  • Протестировать в препродакшене.
  • Развернуть в продакшене.

Как ни странно, пока мы готовились к этому масштабному предприятию, было объявлено о переходе styled-components в режим поддержки, что стало дополнительным подтверждением того, что мы движемся в правильном направлении.

Работа началась в апреле 2025 года, когда пиковое число подлежащих миграции пропсов sx составляло около 7 760; завершить ее удалось лишь к маю 2026 года. Сначала один из наших замечательных штатных разработчиков, Иэн Сандерс (Ian Sanders), создал плагин для VS Code, упрощающий миграцию отдельных пропсов. Аналогичный кодемод был разработан внутри компании и использовался для миграции целых файлов в кодовой базе GitHub. Эта работа, хотя и требовала ручного контроля и тщательной валидации, была в основном автоматизирована. Ротация из 8 инженеров перенесла 6 419 пропсов за 6 месяцев, добившись прироста производительности серверного рендеринга от 1% до 22% на некоторых страницах.

В другой части GitHub возможности Copilot росли экспоненциально. Искусственный интеллект становился умнее и функциональнее; пока эта работа еще продолжалась, мы выпустили агент кодинга Copilot и инструмент ревью кода Copilot.

К тому моменту, когда мы вернулись к этой задаче в апреле 2026 года, ситуация изменилась: силами команды из двух инженеров, благодаря неуклонной решимости и активному использованию агентов кодинга Copilot, нам удалось сократить количество пропсов sx с 895 до 0 всего за три недели.

Битва тем

Это был великий день: мы наконец завершили миграции 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.

Авторы

Джош Блэк (Josh Black) — разработчик ПО из Остина, штат Техас. Он любит работать над дизайн-системами, создавать доступные интерфейсы и есть чилакилес.

Мари (Marie) — инженер-программист из Атланты, работающая над проектом GitHub Primer. Когда она не двигает пиксели на экране, то, скорее всего, заталкивает ручную кладь на верхнюю полку самолета где-то над Атлантикой.