GitHub стал быстрее на 22% за счет увеличения объема отправляемого CSS

GitHub только что сообщил о значительном успехе: сокращение времени рендеринга на сервере на определенных целевых страницах составило до 22%. Этот прирост производительности стал результатом контринтуитивного решения — отправлять больше CSS. Вместо динамической генерации стилей «на лету» GitHub решил компилировать стили на этапе сборки, переложив ресурсоемкие задачи с процесса обработки запроса.

Для многих веб-разработчиков такой результат звучит парадоксально. Общепринятое мнение гласит, что для производительности лучше использовать минимальный, специфичный для маршрута CSS. Однако динамическое создание такого CSS, особенно с помощью библиотек CSS-in-JS с серверным рендерингом, может потреблять значительные ресурсы процессора сервера при каждом запросе пользователя. Мнимая выгода от отправки только «необходимого» CSS становится узким местом на стороне сервера.

Важно отметить, что это улучшение касается исключительно серверного рендеринга. Цифра 22% отражает время, сэкономленное сервером на подготовке первоначального HTML-ответа. Это не означает, что общее время загрузки страницы на стороне клиента сократилось на ту же величину или что всё приложение стало быстрее на 22%. Это целенаправленная оптимизация серверной нагрузки, переносящая значительную часть логики стилизации с выполнения во время работы программы на компиляцию статических ресурсов.

Первоначальная архитектура GitHub во многом опиралась на server-rendered CSS-in-JS — метод, при котором логика стилизации выполняется во время каждого запроса. Этот подход использует JavaScript для вычисления стилей, зависящих от свойств, генерации уникальных имен классов и сбора необходимого CSS во время рендеринга HTML сервером. Несмотря на кажущуюся эффективность, этот динамический процесс несет скрытые вычислительные затраты.

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

Динамическая стилизация дает весомое преимущество: она передает только те стили, которые необходимы для конкретного состояния страницы, минимизируя объем CSS на стороне клиента. Однако эта избирательность не бесплатна. Сервер платит за это циклами процессора, постоянно выполняя одни и те же вычисления стилей и манипуляции со строками для каждого входящего запроса.

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

Переход GitHub на CSS Modules иллюстрирует фундаментальный сдвиг в том, где выполняются вычислительные задачи. Вместо генерации стилей по запросу, CSS Modules компилируют стили в статические файлы .css на этапе сборки. Это означает, что сервер рендерит только статический HTML с заранее определенными именами классов, полностью освобождая цикл «запрос-ответ» от генерации стилей.

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

Заявленное улучшение времени серверного рендеринга на 22% на определенных страницах GitHub — это впечатляющий результат, но важно не путать его с универсальным приростом производительности для всей платформы. Более масштабная миграция GitHub на Primer, которая включала отказ от более чем 6400 динамических пропсов, привела к общему сокращению времени серверного рендеринга на 55% для основных наборов компонентов и на 25% — времени инициализации компонентов.

Прирост производительности на конкретных страницах варьировался от 1% до 22%, что отражает сложность и масштаб их приложения. Этот неоднозначный результат подчеркивает, что, хотя принцип переноса вычислений на этап сборки является верным, точные преимущества в производительности сильно зависят от уникальной архитектуры приложения и использования компонентов. Подробнее об особенностях этого архитектурного сдвига читайте в статье Improving site performance by shipping more CSS - The GitHub Blog.

Выводы GitHub преподают важный урок: оценивайте страницу, а не идеологию стилизации. Команды должны оценивать время серверного рендеринга наряду с объемом CSS, поведением кэша и критически важными для пользователя метриками, такими как Time to First Byte (TTFB) и Largest Contentful Paint (LCP), на репрезентативных маршрутах. Такой целостный подход позволяет увидеть реальное влияние на пользовательский опыт.

Ни одно решение для стилизации не является абсолютным лидером. CSS Modules, Tailwind CSS, Chakra UI и инструменты без runtime-компонента имеют свои уникальные компромиссы в плане удобства разработки, объема сетевого трафика и архитектурных накладных расходов. Выбор полностью зависит от конкретных потребностей приложения и узких мест в производительности, а не от универсального правила.

Бенчмаркинг всего пути пользователя имеет первостепенное значение. Хотя GitHub добился сокращения времени серверного рендеринга до 22% за счет передачи большего объема CSS, само по себе это не гарантирует более быструю загрузку страницы в целом. Сервер — это лишь одно звено в цепи; более тяжелый клиентский контент или медленное сетевое соединение могут свести на нет эти серверные улучшения.

В конечном итоге цель состоит в создании более быстрого и отзывчивого приложения для конечного пользователя. Это означает тщательное тестирование и сравнение моделей стилизации на основе комплексного набора метрик. Выбирайте подход, который лучше всего соответствует архитектуре вашего приложения и обеспечивает доказуемые улучшения во всем стеке.

Как GitHub сократил время серверного рендеринга на 22%?

На определенных целевых страницах GitHub сократил объем работы по стилизации на стороне сервера, перейдя от runtime CSS-in-JS к CSS Modules, обрабатываемым на этапе сборки.

Означает ли ускорение серверного рендеринга на 22% ускорение страницы на 22%?

Нет. Это показатель времени серверного рендеринга, а не общего времени загрузки. Передача данных по сети, парсинг CSS и отрисовка также влияют на то, что видит пользователь.

Почему runtime CSS-in-JS может замедлять серверный рендеринг?

Серверу может потребоваться вычислять динамические стили, генерировать имена классов, а также собирать или внедрять CSS при обработке каждого запроса.

Когда команде стоит рассмотреть CSS Modules?

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