Частота развёртки экрана: то, что разработчики привыкли игнорировать

При создании адаптивных сайтов или приложений все учитывают вариативность размеров экранов. И это правильно. Но есть ещё одна важная характеристика — частота развёртки экрана. Как она влияет на работу приложения или сайта — остаётся часто за пределами внимания разработчиков. А зря. Потому что именно здесь кроется разница между «работает» и «работает хорошо». Пока ваш потенциальный пользователь выбирает себе монитор: https://allo.ua/ru/monitory/chastota_razvertki_jekrana-144_gc/ с частотой 144Гц так как понимает разницу отображения видео на экранах с минимальной частотой в 60Гц и с частотой в 144Гц, вам также стоит позаботиться о коде вашего приложения или анимации на сайте. Об этом и пойдет здесь речь - полезно почитать разработчикам тяжелых сайтов и приложений.

Что такое частота развёртки и почему это не только «железный» вопрос

Частота развёртки (refresh rate) — это количество раз в секунду, которое экран обновляет изображение. Измеряется в герцах (Hz). Стандарт долгое время был один: 60 Hz. Но сегодня всё иначе. Смартфоны флагманского сегмента работают на 90, 120, а порой и 144 Hz. Мониторы для геймеров давно перешагнули за 240 Hz.

Казалось бы — это задача операционной системы и GPU. Но нет. Как только в интерфейс вашего приложения или сайта добавляется хоть одна анимация, переход, скролл или динамическая сцена — частота развёртки экрана пользователя становится вашей проблемой тоже. Такая мелочь может привести к потере пользователей вашего приложения или сайта, сервиса. Тем более рынок мониторов фактически уже уходит от минимальных частот развертки, а значит число мониторов у пользователей с частотами 144Гц и выше увеличивается.

«Браузер не может показать кадр быстрее, чем экран способен его отобразить. Но он вполне может показывать их медленнее — и пользователь это почувствует сразу.»

Когда частота развёртки имеет значение

Не для всех проектов этот вопрос одинаково критичен. Статичный лендинг с одной анимацией появления заголовка — вполне простит вам незнание темы. Но есть категории продуктов, где игнорирование refresh rate — это профессиональный просчёт.

Анимации и переходы в интерфейсе

CSS-анимации и JavaScript-переходы рендерятся покадрово. Если экран работает на 120 Hz, он ожидает 120 кадров в секунду. Если ваша анимация рассчитана на 60 fps — визуально она будет выглядеть чуть менее плавной, чем могла бы. Не катастрофа, но упущенная возможность.

Гораздо хуже — обратная ситуация. Если ваш JavaScript-цикл анимации строится на setInterval или даже на неправильно используемом setTimeout, а не на requestAnimationFrame — на экране с 120 Hz вы получите рассинхронизацию, артефакты и рывки. Браузер будет пытаться рендерить кадры в моменты, которые не совпадают с циклом обновления экрана.

Игры и интерактивные приложения в браузере

Браузерные игры, редакторы, карты, визуализации данных в реальном времени — всё это критично зависит от fps. Здесь разница между 60 и 120 Hz экраном — это буквально разница в отзывчивости управления. Если вы разрабатываете WebGL-сцену или Canvas-анимацию и не учитываете реальную частоту экрана — вы работаете вслепую.

Видеоконференции и стриминг

Онлайн-технологии реального времени — WebRTC, потоковое видео, живые трансляции — тоже зависят от этого параметра косвенно. Декодирование и отображение видеопотока происходит с учётом частоты экрана. Если частота видео (например, 30 fps) не кратна частоте экрана (например, 144 Hz) — могут появляться микрозависания, которые пользователь воспримет как «плохой интернет», хотя проблема на стороне рендеринга.

Скролл и parallax-эффекты

Один из самых недооценённых кейсов. Плавность скролла напрямую определяется тем, насколько синхронизирован ваш JavaScript с циклом обновления экрана. На 120 Hz-устройстве пользователь сразу замечает, если скролл «дёргается» — даже если на 60 Hz это было незаметно.

Как браузер узнаёт частоту экрана — и можете ли это узнать вы?

Браузер имеет доступ к информации о частоте развёртки через системные API. Разработчики могут получить приблизительное значение через JavaScript — с помощью измерения временны́х меток в requestAnimationFrame. Метод прост: запускаем несколько итераций rAF, измеряем дельту между кадрами и вычисляем среднее. Если дельта ≈ 8.3 мс — перед нами 120 Hz. Если ≈ 16.6 мс — 60 Hz. Прямого API для получения refresh rate в браузере пока нет (на момент написания статьи), но экспериментальный Screen.prototype в некоторых браузерах уже содержит поле refreshRate. В Node.js, конечно, этот вопрос не стоит — там нет экрана.

Как частота развёртки влияет на производительность загрузки

Здесь важно развеять один миф: сама по себе высокая частота экрана не замедляет загрузку страницы. HTTP-запросы, парсинг HTML, выполнение JS — всё это происходит до того, как экран «включается в игру». Но вот что происходит дальше — интереснее.

Браузер после загрузки ресурсов входит в фазу рендеринга: layout → paint → composite. И именно на этапе composite начинается взаимодействие с GPU и, соответственно, с частотой экрана. Если ваша страница содержит тяжёлые CSS-анимации или JS-анимации, которые не вынесены на GPU-слой (через transform и opacity), — браузер будет вынужден перекрашивать пиксели на каждом кадре. На 120 Hz это означает вдвое больше операций paint в секунду по сравнению с 60 Hz.

Результат: CPU перегружен, battery drain на мобильных устройствах возрастает, и пользователь с флагманским телефоном парадоксально получает более «горячий» и менее отзывчивый интерфейс, чем пользователь с бюджетным устройством на 60 Hz.

Практические инструменты и подходы

requestAnimationFrame — основа основ

Если вы всё ещё используете setInterval для анимаций — остановитесь прямо сейчас. requestAnimationFrame автоматически синхронизирует вызов колбэка с циклом обновления экрана, независимо от того, 60 это Hz или 144. Браузер сам знает, когда рисовать следующий кадр.

function animate(timestamp) {
 // timestamp — время в мс от начала сессии
 const delta = timestamp - lastTimestamp;
 lastTimestamp = timestamp;

 // Обновляем состояние на основе delta, а не просто «на 1 шаг»
 position += speed * (delta / 1000);

 draw();
 requestAnimationFrame(animate);
}

requestAnimationFrame(animate);

Ключевой момент — обновлять состояние на основе временно́й дельты, а не на основе количества кадров. Иначе на 120 Hz ваш объект будет двигаться вдвое быстрее, чем на 60 Hz.

CSS-анимации и GPU-ускорение

Анимировать через CSS следует только свойства transform и opacity — они обрабатываются на этапе composite и не вызывают layout или repaint. Всё остальное (width, top, left, background-color и т.д.) — это дорогостоящие операции, которые на высокочастотных экранах ударят по производительности заметнее.

• Используйте will-change: transform для элементов, которые будут анимироваться — браузер заблаговременно вынесет их на отдельный GPU-слой
• Не злоупотребляйте will-change: каждый слой потребляет память GPU
• Проверяйте слои в Chrome DevTools → Layers panel
• Используйте вкладку Performance для анализа реального fps в вашем приложении
• Тестируйте на устройствах с разными refresh rate — эмулятор не заменит реальное железо

Адаптация к частоте экрана через медиазапросы

CSS уже поддерживает медиазапрос prefers-reduced-motion, который позволяет отключать анимации для пользователей, которые этого хотят. Но есть и менее известный — update:

@media (update: fast) {
 /* Экран с высокой частотой обновления — можно использовать сложные анимации */
 .card {
 transition: transform 0.2s ease;
 }
}

@media (update: slow) {
 /* Медленный экран (e-ink, например) — избегаем анимаций */
 .card {
 transition: none;
 }
}

Значение update: fast соответствует обычным LCD/OLED-экранам, update: slow — устройствам вроде электронных книг, где частота обновления измеряется единицами Hz. Это редко используемый, но полезный инструмент в арсенале профессионала.

Частота развёртки и формула плавности

Есть простая математика, которую полезно держать в голове. Время на отрисовку одного кадра (frame budget) вычисляется так:

\[ t_{frame} = \frac{1000\text{ мс}}{f_{Hz}} \]

Для 60 Hz это ≈ 16.6 мс на кадр. Для 120 Hz — ≈ 8.3 мс. Для 144 Hz — ≈ 6.9 мс. Именно столько времени у браузера есть на то, чтобы выполнить весь JavaScript, layout, paint и composite — и успеть передать кадр экрану. Если вы укладываетесь в этот бюджет — анимация плавная. Если нет — кадр пропускается, и пользователь видит рывок.

На 120 Hz этот бюджет вдвое меньше. Это не значит, что разрабатывать для таких экранов нужно вдвое лучше — это значит, что нужно быть вдвое аккуратнее.

Что такое «jank» и почему это враг UX

«Jank» (от англ. jankiness — дёрганость) — термин из среды фронтенд-разработчиков, обозначающий визуальные рывки и нестабильность анимации из-за пропущенных кадров. Возникает, когда браузер не успевает отрисовать кадр в отведённый frame budget. На высокочастотных экранах jank заметен острее, потому что пользователь уже привык к плавности и мозг моментально фиксирует любое отклонение от ритма. Исследования показывают, что jank воспринимается пользователями как признак «плохого качества» продукта — даже если функционально всё работает корректно.

Чек-лист для разработчика

1. 1) Все JavaScript-анимации используют requestAnimationFrame с дельта-временем
2. 2) CSS-анимации применяются только к transform и opacity
3. 3) Профилирование выполнено в Chrome DevTools с включённым FPS-метром
4. 4) Приложение протестировано на реальных устройствах с 60, 90 и 120 Hz
5. 5) Тяжёлые вычисления вынесены в Web Workers, чтобы не блокировать main thread
6. 6) Используется prefers-reduced-motion для доступности
7. 7) GPU-слои проверены в Layers panel — нет лишних, нет утечек

Тема частоты развёртки — это один из тех редких случаев, когда понимание «железного» параметра напрямую влияет на качество кода. Мир уходит от монотонного 60 Hz: Apple, Samsung, OnePlus и другие производители давно сделали высокую частоту стандартом даже в среднем ценовом сегменте. Через несколько лет 120 Hz будет таким же базовым ожиданием, каким сегодня является адаптивность под мобильные экраны. Разработчики, которые начнут учитывать этот параметр сейчас, просто будут на шаг впереди. А вы уже сталкивались с проблемами анимаций на высокочастотных экранах в своих проектах? Напишите в комментариях — интересно узнать, как решали.