Если у вас всё ещё живёт MacBook Pro 2016–2020 годов на процессоре Intel, вам наверняка знакома эта картина: вы открываете обычный фильм или ролик на YouTube в Google Chrome, проходит ровно две минуты — и ноутбук превращается в раскалённую сковороду. Температура процессора пробивает 95–99 °C, кулеры выходят на взлётные 7200 RPM, в «Мониторинге системы» просыпается беспощадный kernel_task, съедающий процессор ради спасения чипа от перегрева, видео начинает идти рывками, а батарея тает за час.

В этой статье я расскажу, как обычный вопрос «почему мой ноутбук кипит от одного фильма в браузере?» превратился в многомесячное инженерное расследование. Мы пройдём весь путь:

1. Ревизия скрытых демонов macOS: как сбой локатора (searchpartyuseragent) и contactsd крутил процессор каждые 30 миллисекунд и почему обычная перезагрузка macOS это не лечит.

2. Аппаратная профилактика и физика старого аккумулятора: что дала чистка, замена термопасты и почему батарея на 1000+ циклов сама становится печкой.

3. Рождение TurboControl: почему готовые утилиты вроде Turbo Boost Switcher и Macs Fan Control довели меня до белого каления всплывающими окнами паролей при каждом выходе из сна, и как мы написали своё нативное Menu Bar приложение на Swift + SwiftUI + C (прямая работа с регистрами MSR и чипом AppleSMC).

4. Детектив с Google Chrome (версии 151 vs 153): почему даже с выключенным Turbo Boost и заблокированными кодеками видеочип Intel Iris вдруг оказался загружен на 70%, как Google тихо занёс старые видеочипы Intel в чёрный список и почему флаг Skia Graphite, спасавший в Chrome 151, в Chrome 153 вдруг начал отключать видеокарту и раскалять проц до 99 °C.

В конце каждого раздела я собрал конкретные шпаргалки с командами и флагами браузера, которые можно применить прямо сейчас, а само приложение выложил в Open Source (MIT) и Homebrew.

---

Акт 1. «Ноутбук кипит от одного фильма»: миф про Safari, зацикленный Локатор и кодеки

Дано: MacBook Pro 13" 2017 года (двухъядерный Intel Core i5-7360U Kaby Lake с базовой частотой 2.3 ГГц и разгоном Turbo Boost до 3.6 ГГц, встроенная графика Intel Iris Plus Graphics 640, 8 ГБ ОЗУ).

Симптом простой и мучительный: запускаешь один фильм в Chrome — ноутбук раскаляется так, что невозможно держать на коленях, а вентилятор воет как пылесос.

Первая мысль любого маковода из советов в интернете: «У тебя всего 8 ГБ оперативки, Chrome всё сожрал и ушёл в своп, переходи на Safari!». Открываю «Мониторинг системы» и проверяю память. Нагрузка на память — зелёная (занято 5.74 ГБ из 8 ГБ, своп минимальный). А вот попытка открыть всего пару современных тяжёлых вкладок в Safari даже без фильма привела к тому, что процессы com.apple.WebKit.WebContent из‑за агрессивного кэширования страниц съели оперативку куда быстрее Chrome.

Память ни при чём — чип греют вычисления. Переключаемся на вкладку ЦП в «Мониторинг системы» и видим прекрасную картину:

Помимо Google Chrome и WindowServer, в топе висят два подозрительных процесса:

1. kernel_task (21.3%) — это уже следствие, а не причина. Когда датчики температуры приближаются к критическим значениям, ядро macOS искусственно захватывает потоки процессора «пустыми» циклами ожидания, чтобы физически не дать другим программам греть кремний дальше.

2. contactsd (18.7%) и siriknowledged (10.4%) — а вот это уже чистый паразит, который вхолостую сжигал почти треть двухъядерного процессора даже без всякого видео!

Расследование бага contactsd + searchpartyuseragent

Попытка просто убить contactsd через крестик в «Мониторинге системы» или выключить синхронизацию контактов в настройках iCloud не дала ничего — демон launchd воскрешал процесс через секунду, и он снова уходил в потолок. Более того, я несколько раз перезагружал ноутбук, но кулеры не успокаивались.

Лезем в системные логи macOS и находим корень зла. Виновником оказался вовсе не список контактов, а фоновый демон службы «Локатор» (searchpartyuseragent):

• Каждые 30 миллисекунд он запускал процедуру reevaluateFamilySharing и фоновое сканирование сети Локатора (Find My Network).

• Когда поблизости (даже у соседей за стеной) оказывался любой чужой AirTag или устройство Apple, служба пыталась сопоставить его ключ с моей адресной книгой через contactsd.

• В локальном демоне учётных записей (ACDAccountStore) произошёл сбой токена ("The connection to ACDAccountStore was invalidated"). Вместо того чтобы подождать, searchpartyuseragent ушёл в бесконечный цикл рестартов, бомбардируя contactsd сотнями запросов авторизации tcc_send_request_authorization в секунду!

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

Разорвать этот круг удалось только жёстким одновременным пристрелом всей тройки демонов, что заставило систему пересоздать IPC‑сокеты с нуля:

killall -9 searchpartyuseragent contactsd accountsd

И чтобы этот баг больше никогда не высаживал батарею в фоне, в Системные настройки → Конфиденциальность и безопасность → Службы геолокации → Системные службы (Детали…) мы отключили бесполезные для ноутбука тумблеры «Важные геопозиции» и «Аналитика Mac», а внизу включили показ иконки геолокации в строке меню, чтобы сразу видеть, если какой‑то демон снова сойдёт с ума.

Кодеки видео: почему Kaby Lake задыхается на современном вебе

Вторая проблема из первого скриншота — сам видеопоток. YouTube и современные онлайн‑кинотеатры по умолчанию отдают видео в кодеках AV1 и VP9. Но у процессоров Intel 7-го поколения (Kaby Lake, 2017 год) вообще нет аппаратного декодера AV1, а аппаратная поддержка VP9 сильно ограничена. В результате браузер перекладывает декодирование видеопотока на центральный процессор (CPU).

Решение здесь классическое, но с важным нюансом — ставим расширение enhanced‑h264ify и настраиваем его так:

• Ставим галочки: Блокировать VP8, Блокировать VP9, Блокировать AV1.

• Оставляем снятой галочку Блокировать h264 (AVC) — теперь плеер отдаёт поток в старом добром H.264, который аппаратно щёлкает блок Intel Quick Sync.

• Важный лайфхак для Retina‑экранов: если поставить галочку «Блокировать 60 к/с видео», ролик пойдёт в стандартных 30 fps. Для обычного фильма или разговорного видео разницы нет, а вот нагрузка на отрисовку пикселей экрана 2560×1600 падает ровно в 2 раза.

Смотрим в «Мониторинг системы» через минуту после убийства зацикленного Локатора и включения H.264:

Процессы contactsd и siriknowledged исчезли полностью, а нагрузка Google Chrome упала с 26.5% до 2.0%!

? Шпаргалка № 1: Первая помощь при фоновом нагреве macOS

1. Если в топе CPU висит contactsd или accountsd, сбросьте цепочку IPC‑сокетов: killall -9 searchpartyuseragent contactsd accountsd

2. Проверьте статус теплового троттлинга в терминале: pmset -g therm (в норме должно быть CPU_Speed_Limit = 100 и No thermal warning).

3. Проверьте скрытых демонов автозагрузки (например, у меня в фоне постоянно висел демон AnyDesk, которого не было видно в обычном списке «Объекты входа»). Отключается навсегда через: sudo launchctl disable system/com.philandro.anydesk.Frontend

---

Акт 2. Чистка, замена термопасты, «эффект 1014 циклов» и ловушка Intel Turbo Boost

Казалось бы — победа? Как бы не так. В тот же день я решил довести дело до идеала: разобрал MacBook, вычистил радиатор от пыли, заменил высохшую заводскую термопасту на свежую, собрал обратно и включил двухчасовой фильм.

Ноутбук всё равно ощутимо грелся снизу, а батарея продолжала таять!

Проводим глубокую аппаратную диагностику контроллера питания (ioreg -rn AppleSmartBattery) и находим сразу две физические причины:

1. Внутреннее сопротивление изношенного аккумулятора (1014 циклов): На моём макбуке батарея прошла 1014 циклов (статус Service Recommended, остаточная ёмкость ~68%). У пожилых литий‑полимерных ячеек сильно возрастает внутреннее химическое сопротивление. Когда ноутбук при просмотре фильма потребляет 15–20 Ватт, сама батарея при отдаче такого тока начинает ощутимо разогреваться изнутри, подогревая алюминиевое днище.

2. Агрессивный алгоритм Intel Turbo Boost: Замеры через powermetrics показали абсурдную вещь. Базовой частоты процессора Core i5 (2.3 ГГц) хватает с трёхкратным запасом, чтобы крутить любое видео без единого дропа кадров. Но при малейшем всплеске активности в браузере (подгрузка чанка видео, выполнение JS‑скрипта на странице) процессор мгновенно врубает Intel Turbo Boost и задирает частоту до 3.6 ГГц. Из‑за нелинейного роста напряжения энергопотребление чипа подскакивает с комфортных 10–12 Вт до 28–35 Вт, кристалл за секунды пробивает 85–90 °C, а следом за ним раскаляется и старая батарея!

Почему меня выбесил сторонний софт для отключения Turbo Boost

Чтобы запретить процессору бессмысленно уходить в разгон при просмотре кино, мне посоветовали классическую утилиту Turbo Boost Switcher. Я поставил её бесплатную версию, отключил Turbo Boost — и действительно, процессор перестал прыгать выше 2.3 ГГц. Но радость длилась ровно до первого закрытия крышки ноутбука.

Каждый раз, когда MacBook выходил из сна, посреди экрана выскакивало вот это окно:

Я сначала спросил ИИ‑ассистента: «А можешь просто исправить код этого приложения, чтобы оно не спрашивало пароль?». Но бинарник закрыт и подписан цифровой подписью Apple (Code Signature) — любое вмешательство в машинный код сломает подпись, и Gatekeeper просто не даст его запустить.

К тому же, когда мы заглянули в GitHub‑репозиторий rugarciap/Turbo-Boost-Switcher и соседние проекты, выяснилось, что проблема куда шире:

• В Issue #182 пользователи с 2022 года просят возможность переключать Turbo Boost через скрипты и CLI — решения нет.

• В Issue #126 и Issue #169 люди жалуются на троттлинг и просят совместить управление Turbo Boost с ранним включением вентиляторов — тоже тишина.

• В популярном мониторе exelban/stats (Issue #645) автор прямо отказался добавлять тумблер Turbo Boost.

• А держать одновременно запущенными Turbo Boost Switcher (который клянчит пароль) и Macs Fan Control (который умеет крутить кулеры, но не умеет выключать Turbo Boost) — сомнительное удовольствие.

Тогда я сказал: «Нам нужно своё приложение. Замер температур и нагрузки не только проца, но и видеочипа, управление оборотами винта, переключение Turbo Boost в один клик без единого пароля, автозапуск и красивый нативный интерфейс в верхней панели. Делай!»

---

Акт 3. Пишем свой TurboControl на Swift, C и IOKit

Мы решили не тащить в проект ни Electron, ни даже громоздкий .xcodeproj — всё приложение собирается за 3 секунды прямым скриптом build_app.sh через clang и swiftc, весит в оперативной памяти около 15 МБ и потребляет 0.1% CPU.

Вот из каких технических кирпичиков сложилась архитектура TurboControl.

1. Укрощение регистра MSR_IA32_MISC_ENABLE и беспарольный хелпер

На процессорах Intel технология Turbo Boost управляется на аппаратном уровне через модельно‑специфичный регистр MSR_IA32_MISC_ENABLE (адрес 0x1A0 / 0x1FC), а именно — 38-м битом:

• Если бит 38 равен 0 — Turbo Boost включён.

• Если записать в бит 38 единицу (1) — процессор жёстко фиксируется на базовой частоте (для моего i5-7360U это 2.3 ГГц) и никогда не превышает базовый теплопакет TDP.

В пользовательском пространстве (ring 3) выполнить инструкции ассемблера rdmsr / wrmsr нельзя — это привилегия ядра (ring 0). Поэтому мы использовали крошечное безвредное расширение ядра DisableTurboBoost.kext и написали вокруг него привилегированный диспетчер /usr/local/bin/turbocontrol-helper.

Чтобы навсегда избавиться от ввода пароля при переключении режимов, выходе из сна или перезагрузке, установочный скрипт один раз при инсталляции прописывает строго ограниченное правило в /etc/sudoers.d/turbocontrol:

%admin ALL=(ALL) NOPASSWD: /usr/local/bin/turbocontrol-helper

В результате Swift‑приложение переключает состояние процессора мгновенно вызовом sudo -n /usr/local/bin/turbocontrol-helper disable | enable, а сам хелпер можно дёргать из любых собственных bash‑скриптов или Быстрых команд macOS.

2. Почему заводская логика кулеров Apple вредит старым Intel Mac (и как мы написали драйвер AppleSMC)

Когда мы вывели на экран реальные датчики из чипа AppleSMC (температуру процессора TC0P/TC0E, температуру видеочипа Intel Iris TCGC и текущие обороты кулера F0Ac), вскрылась поразительная деталь заводской настройки Apple:

Процессор уже раскалился до 89 °C, видеочип — 75 °C, а вентилятор крутится всего на 1990 RPM (28% мощности)!

Инженеры Apple настроили кривую охлаждения в угоду абсолютной тишине: система упорно держит минимальные обороты (1200–1900 RPM) вплоть до 85–90 °C. К тому моменту, когда прошивка наконец решает раскрутить турбину, тепловая трубка и весь алюминиевый корпус уже находятся в состоянии глубокого теплового насыщения. Охладить раскалённый брусок алюминия на 2000 RPM невозможно, поэтому через минуту кулер в панике взлетает на максимальные 7200 RPM.

При этом на оборотах 2500–3400 RPM вентилятор MacBook Pro работает практически бесшумно (лёгкий шелест воздуха), но если включить эти обороты превентивно при 55 °C, тепло сдувается с радиатора сразу и корпус вообще не успевает нагреться выше 65–72 °C!

Для прямого управления кулером мы написали на чистом C утилиту smc_fan_writer.c, которая общается с контроллером AppleSMC через IOKit:

1. Переводит битовую маску режима вентилятора в ключе FS! (тип ui16, 2 байта): запись 0x00 0x01 переводит кулер № 0 в ручное управление, а 0x00 0x00 возвращает контроль заводскому автомату Apple.

2. Записывает целевые обороты в ключ F0Tg в специфичном для Apple 14-битном формате с фиксированной точкой fpe2 (Unsigned Fixed Point 14.2), где значение RPM сдвигается на 2 бита влево (RPM << 2) и упаковывается в Big‑Endian:

// Запись целевых оборотов в AppleSMC (формат fpe2: RPM * 4 в Big-Endian)
int raw = rpm << 2;
uint8_t fpe2[2] = {
    (uint8_t)((raw >> 8) & 0xFF),
    (uint8_t)(raw & 0xFF)
};
smc_write_key(conn, "F0Tg", 'fpe2', fpe2, 2);

На базе этого драйвера в TurboControl появились 4 режима работы кулера:

• Умный (Ранний) — наша кастомная кривая: тишина (1200 RPM) до 50 °C, мягкий старт 1800–3400 RPM в зоне 50–65 °C, активное удержание 3400–4900 RPM в зоне 65–75 °C.

• Авто (Apple) — штатный заводской профиль macOS.

• Макс (7200 RPM) — продувка в 1 клик, чтобы за минуту остудить ноутбук.

• Ручной — плавный слайдер от 1200 до 7200 RPM с дебаунсом в 150 мс.

А чтобы при закрытии приложения кулер случайно не остался зафиксированным на ручных оборотах, в applicationWillTerminate срабатывает автоматический возврат в Авто (Apple).

3. Подводные камни UI на macOS: прыгающие шкалы и ловушка Fullscreen

По ходу ежедневного использования приложения мы наткнулись на три неочевидных бага macOS/SwiftUI, решение которых пригодится любому macOS‑разработчику:

1. Честное сохранение выбора пользователя (UserDefaults): В первой версии приложения мы сделали ошибку: при каждом старте и выходе из сна программа принудительно выключала Turbo Boost. Когда мне однажды понадобился включённый Turbo Boost, после перезагрузки он снова сам выключился. Мы переписали логику: теперь приложение намертво запоминает в UserDefaults именно ваш последний выбор (ВКЛЮЧЕН или ОТКЛЮЧЕН) и после сна восстанавливает строго его.

2. Анимация полос прогресса («прилёты снизу»): Если в SwiftUI повесить модификатор .animation(...) на контейнер с GeometryReader или динамическим текстом разной ширины (49°C → 50°C), при каждом тике таймера окно NSPopover микро‑дёргается по вертикали, а полоски визуально «выпрыгивают снизу». Мы жёстко зафиксировали высоту карточек (68 px), перевели цифры на моноширинный шрифт .monospaced и привязали анимацию исключительно к ширине заполняемой капсулы.

3. Обрезание шапки окна в полноэкранном режиме (Fullscreen): Стандартный системный NSPopover жёстко привязывается к системному окну строки меню (NSStatusBarWindow). Когда вы смотрите фильм на весь экран, поднимаете мышь наверх, открываете приложение в трее и опускаете курсор ниже — macOS автоматически прячет верхнюю строку меню вверх за пределы экрана (y > screen.maxY) и утягивает за собой верхнюю часть NSPopover вместе с кнопкой настроек! Решение: мы полностью отказались от NSPopover и заменили его на собственную плавающую панель FloatingPanel: NSPanel с флагом .fullScreenAuxiliary и жёстким расчётом экранных координат (maxTopY = screenFrame.maxY - 28.0). Теперь даже когда верхнее меню в полноэкранном фильме уезжает вверх, окно TurboControl остаётся целиком на экране.

Вот как выглядит интерфейс TurboControl в штатном режиме (Turbo Boost включён, кулер на профиле Apple Auto):

---

Акт 4. Поворот сюжета: «Почему с выключенным Turbo Boost он всё равно греется в Chrome?!»

Несколько дней я пользовался TurboControl и заметил странную вещь. Я открываю видео в Chrome, выключаю Turbo Boost, включаю его обратно — а температура всё равно ползёт к 85–89 °C! И тут наше приложение впервые показало то, чего не видно в обычном «Мониторинге системы» macOS (который показывает только загрузку CPU):

• Загрузка CPU была всего 30%.

• А вот загрузка встроенного видеочипа GPU (Intel Iris Plus 640) застыла на отметке 70%!

В процессорах Intel 13-дюймовых MacBook Pro центральный процессор и графическое ядро Intel Iris находятся на одном общем кремниевом кристалле под одной медной тепловой трубкой. Даже если зажать частоту ядер CPU на 2.3 ГГц, раскалённый от 70%‑ной нагрузки видеочип точно так же разогревает весь процессор до 89 °C!

Но почему видеочип загружен на 70%, если кодеки VP9/AV1 уже заблокированы через enhanced-h264ify? Мы полезли внутрь конфигурации Chrome и самого плеера YouTube.

Три скрытых пожирателя ресурсов в YouTube и Chrome

1. «Фоновая подсветка» (Ambient Mode) в плеере YouTube: Несколько лет назад YouTube незаметно включил по умолчанию эффект динамического размытого свечения вокруг границ видеоплеера. На современных чипах M1–M4 он незаметен, но на встроенной графике Intel 2017 года постоянный рендеринг размытия (Gaussian Blur) каждого кадра на Retina‑разрешении в реальном времени отъедает +30–40% мощности GPU впустую! Лечение: нажимаем на шестерёнку в правом нижнем углу плеера YouTube → выключаем тумблер «Фоновая подсветка» (Ambient Mode).

2. Блокировщик рекламы и переход Chrome на Manifest V3: Анализ папки расширений показал установленный старый Adblock Plus, который активно дёргал CPU на динамических страницах. При этом классический uBlock Origin в свежем Chrome уже был отключён с плашкой «Это расширение больше не доступно, так как оно не соответствует рекомендациям» (из‑за отказа Google от Manifest V2). Лечение: удалили старый блокировщик и поставили официальный uBlock Origin Lite (uBO Lite). Он работает целиком через нативный движок браузера declarativeNetRequest, не держит фоновых JS‑процессов и вообще не нагружает ни CPU, ни оперативную память.

3. Встроенная выгрузка вкладок: В chrome://settings/performance включили «Экономию памяти» (Memory Saver) (а вот переключатель «Экономия энергии» в новых версиях Chrome на macOS скрывается, когда ноутбук подключен к зарядке, и работает автоматически при питании от батареи).

---

Акт 5. Финальный босс: Chrome 151 против Chrome 153, Skia Graphite и чёрный список видеокарт Intel

Но самое интересное ждало нас на странице chrome://gpu. Этот раздел я рекомендую прочитать всем, у кого старый Intel Mac тормозит или греется в современном Chrome, потому что за один месяц мы попали в две противоположные ловушки от разработчиков Google.

Эпизод 1: Chrome 151 и прожорливый Skia Graphite

В конце августа (на версии Chrome 151) мы открыли отчёт chrome://gpu и увидели такую строчку:

Graphics Feature Status
=======================
* Canvas: Hardware accelerated
* Skia Graphite: Enabled
* Video Decode: Hardware accelerated

В свежих версиях Chrome компания Google включила новый экспериментальный движок 2D‑рендеринга и композитинга Skia Graphite (пришедший на смену старому Skia Ganesh). Под архитектуру Apple Silicon (M1/M2/M3/M4) его вылизали отлично, а вот на старых интегрированных чипах Intel Iris Plus 640 в версии 151 он вызывал дикий перегруз шейдерных блоков — видеочип молотил на 70% даже на простом видео.

Тогда в Chrome 151 мы открыли chrome://flags/#skia-graphite, переключили его в Disabled и перезапустили браузер. Результат в TurboControl был мгновенным:

Ноутбук стал холодным и бесшумным. Я спокойно смотрел фильмы две с половиной недели, пока в середине сентября не перезагрузил Mac.

Эпизод 2: Внезапное обновление до Chrome 153, «99 °C» и слайд‑шоу на весь экран

После перезагрузки ноутбука начался кошмар:

1. Видео в Chrome вдруг стало дико тормозить (будто упал FPS), а процессор снова начал греться.

2. Попытка сбросить флаги кнопкой Reset all и перезапустить окно браузера сначала вообще ничего не меняла (потому что на macOS закрытие окна на красный крестик не выгружает процесс Chrome из памяти — нужен полный выход через Cmd + Q).

3. А когда мы наконец перезапустили браузер и покрутили настройки — процессор за минуту раскалился до 99 °C, кулер взвыл на 7200 RPM, а при развороте видео на весь экран картинка превратилась в слайд‑шоу!

Я уже был готов взорваться: «В браузере графическое ускорение включено! Теперь видео на весь экран тормозит! Мы долго по кругу ходить будем?!»

Мы прекратили гадать и полезли напрямую в конфигурационный JSON‑файл Chrome (~/Library/Application Support/Google/Chrome/Local State) и аргументы командной строки запущенных процессов Google Chrome Helper (GPU).

И вот какая двойная ловушка обнаружилась внутри:

Ловушка А: Внутренний «чёрный список» оборудования Chrome (Software Rendering List)

В файле Local State действительно стояло "hardware_acceleration_mode": { "enabled": true }. То есть в настройках браузера галочка «Использовать графическое ускорение» была включена! Но в реальных процессах macOS висели принудительные флаги:

--use-gl=disabled --disable-gpu-compositing

Почему? Потому что у Chrome есть встроенный чёрный список старых видеокарт и драйверов (Software Rendering List). В новых версиях браузера встроенная графика Intel Iris Plus 640 (2017 года) попала под блокировку: несмотря на включённый тумблер в настройках, Chrome втихую отключает GPU и переводит отрисовку всех пикселей Retina‑экрана (2560×1600) в аварийный программный режим на двухъядерный центральный процессор! Чтобы запретить браузеру блокировать видеокарту, жизненно необходим флаг: chrome://flags/#ignore-gpu-blocklist (Override software rendering list → Enabled). Когда мы нажали Reset all, этот флаг слетел, и видеокарта вырубилась.

Ловушка Б: В Chrome 153 флаг Skia Graphite = Disabled стал ломать видеокарту!

Но почему тогда, когда мы включили ignore-gpu-blocklist и снова поставили Skia Graphite = Disabled (как делали в августе), видео на весь экран начало тормозить?

Оказалось, что пока ноутбук работал без перезагрузки, Google обновил браузер с версии 151 до Chrome 153. И в версии 153 разработчики Chromium изменили архитектуру графического пайплайна на macOS:

• В Chrome 151 отключение Skia Graphite (Disabled) аккуратно переключало браузер на старый быстрый движок Skia Ganesh.

• А в Chrome 153+ старый пайплайн убрали, и теперь принудительное значение Skia Graphite = Disabled вызывает фатальный фоллбэк: Chrome полностью отключает аппаратный композитинг (--use-gl=disabled)! При этом сам баг с перегрузом GPU внутри Skia Graphite в 153-й версии разработчики наконец‑то починили.

Как только мы вернули chrome://flags/#skia-graphite в положение Default, оставив включённым ignore-gpu-blocklist = Enabled, и перезапустили браузер через Cmd + Q — всё встало на свои места! Аппаратное ускорение заработало на 100%, 4K и FullHD на весь экран пошли идеально плавно, загрузка GPU упала до нескольких процентов, а температура процессора вернулась к комфортным 60–66 °C.

? Шпаргалка № 2: Идеальная конфигурация Google Chrome для MacBook на Intel

1. Аппаратное ускорение: Откройте chrome://settings/system → убедитесь, что тумблер «Использовать графическое ускорение (при наличии)» включён.

2. Обход чёрного списка старых GPU Intel (Обязательно!): Откройте chrome://flags/#ignore-gpu-blocklist (Override software rendering list) → переключите в Enabled. Без этого флага современный Chrome может втихую отключить Intel Iris даже при включённом тумблере в настройках.

3. Движок Skia Graphite (зависит от вашей версии Chrome): Откройте chrome://flags/#skia-graphite:

   • Если у вас Chrome 153 и новее — обязательно оставьте Default (значение Disabled в новых версиях отключает аппаратный рендеринг!).

   • Если у вас старая сборка (Chrome 140–151) и в TurboControl вы видите загрузку GPU 60–80% на простом видео — переключите в Disabled.

4. Правильный перезапуск: После смены любых флагов закрывайте Chrome строго через Cmd + Q (а не красным крестиком окна), затем проверьте на странице chrome://gpu, что напротив Compositing и Video Decode горит зелёный статус Hardware accelerated.

5. Расширения и плеер:

   • enhanced‑h264ify — блокируем VP8, VP9, AV1 и (по желанию) 60fps.

   • uBlock Origin Lite — лёгкий блокировщик рекламы под Manifest V3 без фоновой нагрузки на CPU.

   • В шестерёнке плеера YouTube выключаем «Фоновую подсветку» (Ambient Mode).

---

Итоги: замеры «До и После»

Когда вся система заработала в комплексе — вычищены фоновые демоны macOS, настроен аппаратный пайплайн Chrome 153, а в строке меню дежурит наш TurboControl (с выключенным Turbo Boost и профилем кулера «Умный ранний») — ноутбук 2017 года буквально обрёл вторую молодость:

---

Выход в Open Source (и забавный курьёз с контрибьютором из США)

Изначально мы писали TurboControl исключительно под себя, но когда привели код, локализацию (RU / EN) и установщик в порядок, стало понятно, что с точно такой же болью каждый день сталкиваются тысячи владельцев Intel MacBook Pro и MacBook Air (2015–2020 гг.).

Кстати, при первой публикации репозитория на GitHub случился забавный курьёз. Мы разрабатывали проект в паре с ИИ‑ассистентом (Google Antigravity / Gemini), и я попросил указать его в соавторах коммита (Co-authored-by). Ассистент недолго думая вписал в трейлер коммита вымышленный адрес antigravity@google.com. Через минуту я открываю страницу репозитория на GitHub и с удивлением вижу в блоке Contributors рядом со своим профилем улыбающегося незнакомого парня:

Оказалось, что GitHub автоматически ищет по базе, к какому аккаунту привязан email из Co-authored-by, и этот адрес почему‑то оказался закреплён за реальным американским разработчиком Шимоном Шварцем (@shimonenator)! Пришлось быстро переписывать историю коммита и менять адрес на официальный сервисный бот @gemini-code-assist.

Где скачать и как попробовать TurboControl

Проект полностью открыт под лицензией MIT — без рекламы, платных Pro‑версий, телеметрии и запросов паролей.

• ? Репозиторий на GitHub (исходники и готовый релиз TurboControl.zip): https://github.com/vladsboev‑web/TurboControl

• ? Установка в одну строчку через Homebrew:

  brew install --cask vladsboev-web/tap/turbocontrol
  

  (В postflight скрипт один раз попросит пароль администратора для регистрации беспарольного хелпера в /etc/sudoers.d/turbocontrol и снимет карантин Gatekeeper, после чего приложение появится в верхней строке меню).

• ? Установка для тех, кто не любит терминал: Скачайте архив из Releases, распакуйте и просто дважды кликните по файлу Install TurboControl.command.

Если у вас остался рабочий MacBook на Intel (Pro или Air 2015–2020 годов) — пробуйте настройки Chrome и утилиту, пишите в комментариях свои замеры температур до/после и делитесь, какие ещё скрытые флаги или системные процессы приходилось укрощать вам!

Вся разработка Gemini 3.8 flash high, потом рефакторинг и заливка на гитхаб — Gemini 4 Argon, все в Antigravity. Статья и скрины от Gemini 4.