Привет! Это снова Максим из Яндекс Браузера. Мы с командой продолжаем делиться историями об интересных и неочевидных оптимизациях производительности, которые внедряем в наш браузер. В прошлый раз мы писали о том, как улучшили стабильность GPU‑процесса, воспользовавшись оптимизациями в драйверах видеокарт, сделанными специально для Google Chrome. А сегодня речь пойдёт об ускорении старта нашего браузера на Windows.

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

Один из способов значительно ускорить запуск — использовать фоновый режим (подобную функциональность предоставляют в том или ином виде все современные браузеры, включая Яндекс Браузер). Однако он отключён у некоторых пользователей и не даёт преимуществ при открытии браузера сразу же после старта операционной системы.

В этой статье остановимся на оптимизации медленных стартов браузера, когда ни один его процесс ещё не был запущен. Профилируя подобные старты с помощью встроенной подсистемы трейсинга на слабых устройствах с Windows (например, ноутбуках с HDD), мы заметили, что одно из узких мест — это время инициализации GPU‑процесса.

Коротко о GPU-процессе

GPU‑процесс — это выделенный процесс браузера, который отвечает за растеризацию, композитинг и презентацию конечного кадра в результате работы пайплайна рендеринга. Для понимания мультипроцессной архитектуры браузера можно прочитать одну из статей отличного цикла от разработчиков Google Chrome.

Этот процесс может работать в нескольких режимах:

• С поддержкой аппаратного ускорения (aka хардварный рендеринг). Отрисовка при этом выполняется на GPU при помощи библиотек Skia (предоставляет верхнеуровневое API для рисования) и ANGLE (реализация OpenGL ES от Google, транслирующая вызовы в операции с нативными графическими API, такими как DirectX, OpenGL, Vulkan или Metal).

• Без поддержки аппаратного ускорения (aka софтварный рендеринг). Рендеринг в этом режиме выполняется на CPU с помощью библиотеки Skia. При этом часть функций браузера, например, WebGL и WebGPU, будет недоступна.

Режим хардварного рендеринга, несомненно, более предпочтителен ввиду бóльшей производительности и используется по умолчанию. Но при его инициализации требуется загрузка ряда динамических библиотек (ANGLE, D3D, драйверы GPU) и создание графического контекста. Это как раз и приводит к значительным задержкам на старте браузера, которые суммарно могут достигать десятков секунд. В режиме софтварного рендеринга накладных расходов значительно меньше, из‑за чего GPU‑процесс может инициализироваться в разы быстрее.

Другим значительным фактором, влияющим на время инициализации GPU‑процесса, является вид используемого дискового устройства — HDD или SSD. Вот некоторые цифры из статистики Яндекс Браузера:

В связи с вышеописанным сама собой напрашивается мысль: нельзя ли запускать браузер с GPU‑процессом в режиме софтварного рендеринга, а потом переключать его на хардварный? Об этом в прошлом задумывались и разработчики Chromium, и мы, но идея считалась чересчур сложной для реализации.

Trampoline GPU-процесс

Реализовать такое переключение в рамках одного GPU‑процесса было бы действительно трудоёмко и, что не менее важно для нас, внесло бы большое количество конфликтов с кодовой базой Chromium. Такое решение было бы крайне тяжёлым в поддержке.

Однако в процессе изучения того, как другие процессы браузера взаимодействуют с GPU‑процессом, нам пришло в голову интересное решение. На старте мы параллельно создаём вспомогательный или, как мы его назвали, trampoline GPU‑процесс в режиме софтварного рендеринга и используем его для отрисовки, пока основной GPU‑процесс полностью не проинициализируется в хардварном режиме. Затем мы бесшовно переключаемся между ними.

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

Тем не менее, в процессе реализации нам пришлось преодолеть несколько сложностей. Одной из них было промаргивание белым кадром содержимого браузера при смене GPU‑процессов, которое в перспективе могло бы раздражать пользователей.

Такой сайд‑эффект был совершенно нежелательным, поэтому нам пришлось реализовать частичную приостановку пайплайна рендеринга до полной подготовки нового кадра браузером.

Мы также имплементировали определённые ограничения по области использования trampoline GPU‑процесса: с помощью него не стоит пытаться отрисовывать элементы веб‑страниц, рассчитывающих на наличие аппаратного ускорения (например, видеоэлементы или canvas). Дело в том, что переключение с софтварного рендеринга на хардварный не является стандартным поведением и его не могут учесть веб‑разработчики. При обработке таких элементов рендеринг веб‑страницы будет приостановлен до полной инициализации основного GPU‑процесса. Это эквивалентно поведению браузера без использования trampoline GPU‑процесса.

Что получилось

Первым делом мы решили проверить эффект от использования trampoline GPU‑процесса по бенчмаркам на нашем тестовом стенде. В качестве эталонной метрики для оценки скорости старта браузера мы выбрали время первой отрисовки NTP (New Tab Page, страница новой вкладки) — именно её чаще всего видят пользователи после запуска. Замеры показали ускорение на 24%: эффект можно было заметить невооруженным взглядом.

Данные замеров

Устройство: Dell Latitude E6330, Intel Core i7–3540M 3.00GHz, Intel HD Graphics 4000, 2×4GB HMT351S6CFR8A‑PB, WDC WD5000LPCX-24VHATO

Следующим этапом было проведение A/B‑эксперимента с trampoline GPU‑процессом на небольшой доле пользователей с целью отловить возможные проблемы и точно оценить изменения метрик.

Как ожидалось, эффект от фичи оказался весьма впечатляющим среди пользователей с HDD (ускорение отрисовки NTP на старте до 28% по разным процентилям) и менее интересным, но всё равно позитивным среди пользователей с SSD (ускорение до 2%). Подробно результаты эксперимента изображены на дашборде в DataLens.

Что не менее важно, среди пользователей с HDD улучшились и продуктовые метрики: был зафиксирован статистически значимый рост числа поисков и открытий веб‑страниц с NTP.

Ну и наконец, мы не могли не попробовать сравнить наш браузер с Chromium. Страница новой вкладки в Яндекс Браузере «потяжелее», чем у визави, поэтому для более справедливого сравнения мы решили выбрать сценарий с открытием одной и той же веб‑страницы на старте браузера (например, ya.ru). Яндекс Браузер по бенчмарку оказался быстрее на 30%!

Данные замеров

Устройство: Dell Latitude E6330, Intel Core i7–3540M 3.00GHz, Intel HD Graphics 4000, 2×4GB HMT351S6CFR8A‑PB, WDC WD5000LPCX-24VHATO

Эксперимент мы признали успешным, а фичу с trampoline GPU‑процессом раскатили на всю аудиторию Яндекс Браузера для Windows начиная с версии 25.2.0.

Вот так нестандартное использование особенностей архитектуры браузера позволило нам сделать запуск браузера быстрее. Надеюсь, этот рассказ был интересен для вас, ждём вашего фидбэка в комментариях!