25 августа 2026 года Chrome 152 приехал в стабильный канал на Windows, Mac, Linux, ChromeOS и Android — и принёс свойство navigator.cpuPerformance. Одно число от 0 до 4, которое сайт читает синхронно, без разрешений и без единого такта вычислений. Задумано оно как подсказка для видеозвонков и стримов: слабому устройству отдать 240p без размытия фона, мощному — 1080p с эффектами. Через две недели после релиза индустрия скрапинга обсуждает другое: у антибот-систем появился дешёвый и стабильный сигнал о железе, на котором крутится ваш браузер.
Что именно отдаёт браузер
Свойство возвращает не гигагерцы и не модель процессора, а «корзину» производительности. По пояснительной записке WICG тиров четыре плюс нулевой:
- 0 — классифицировать устройство не удалось;
- 1 — практически непригодно для тяжёлых задач;
- 2 — слабое, но рабочее;
- 3 — комфортное для обычных сценариев;
- 4 — производительное, с запасом на многозадачность.
Спецификация прямо запрещает раскрывать вендора, название модели и количество ядер, требует HTTPS и ставит цель приватности: каждая корзина должна покрывать заметную долю устройств в интернете — порядка сотен разных моделей CPU, чтобы значение не сужало аудиторию до единиц.
Реальная реализация в Chromium оказалась проще спецификации. В разборе Zyte показано, что классификация опирается прежде всего на число логических ядер и на зашитую таблицу повышений и понижений: частота не учитывается вовсе, хотя спека это позволяет. Повышение получают AMD Ryzen, ядра Intel Gracemont, Apple silicon и Intel Core Ultra; понижение — Intel Atom и процессоры эпохи Core 2. Грубая привязка выглядит так: одноядерные и совсем слабые машины попадают в первый тир, два–четыре ядра дают второй, четыре–десять ядер или современные энергоэффективные чипы — третий, а восемь и больше ядер на Core Ultra, Apple M-серия и всё, что от десяти ядер, — четвёртый.
Почему это сигнал детекта, а не просто ещё один байт энтропии
Само по себе значение слабое: пять вариантов — это около 2,3 бита энтропии, меньше, чем даёт язык интерфейса. Опасность в трёх других свойствах.
Оно бесплатное. Чтобы снять таймингом реальную скорость исполнения JS, скрипту детекта нужно занять процессор на десятки миллисекунд, и это заметно в профайлере. Здесь — синхронное чтение свойства, ноль затрат, ноль следов.
Оно стабильное. Значение не зависит от загрузки машины в момент проверки: это класс железа, а не текущая утилизация. Между сессиями, перезапусками и сменами IP оно остаётся тем же — то есть годится как часть долгоживущего идентификатора профиля.
Оно проверяется на непротиворечивость. Это главное. Современные антибот-движки редко банят по одному полю — они ищут внутренние противоречия в наборе. Устройство, заявившее четвёртый тир, обязано подтвердить его правдоподобным navigator.hardwareConcurrency, разумным navigator.deviceMemory, современной строкой GPU-рендерера и соответствующей скоростью исполнения JS. Профиль, который отдаёт tier 4 и при этом исполняет бенчмарк как двухъядерная виртуалка, ловится тривиальной перекрёстной проверкой.
Отдельно получается почти готовый водораздел «датацентр против живого пользователя»: типовой облачный инстанс на двух vCPU честно рапортует первый тир, тогда как потребительские ноутбуки и телефоны живут в третьем–четвёртом. Для скрапера, который крутится на дешёвой VPS в headless-режиме и при этом выдаёт себя за обычный Chrome на Windows, это неудобное сочетание.
Чем это отличается от hardwareConcurrency, который был всегда
Резонный вопрос: число ядер сайт и раньше читал через navigator.hardwareConcurrency, а объём памяти — через navigator.deviceMemory. Что изменилось?
Изменилась связность. hardwareConcurrency — сырое число, и подменяют его давно и повсеместно: поставил восемь вместо тридцати двух, и вопрос закрыт. cpuPerformance — величина производная, посчитанная самим браузером по зашитой таблице. Как только в наборе появляются два поля, одно из которых вычисляется из другого, любая односторонняя правка рвёт связь между ними. Выставили четыре ядра, а тир остался четвёртым — по логике реализации такое сочетание требует либо Apple silicon, либо Core Ultra, либо десяти ядер; значит, либо врёт число ядер, либо врёт строка GPU, и детектору достаточно заметить сам факт несовпадения, не выясняя, где именно ложь.
Ровно поэтому старые чек-листы «какие поля подменить в профиле» устаревают не по одному пункту, а целыми блоками: правильный вопрос теперь не «что подменить», а «какая непротиворечивая конфигурация железа у нас получается в сумме».
Кого это задевает сильнее всего
Chromium-only — и это не смягчающее обстоятельство. WebKit по этому API занял позицию «против», Mozilla публичной позиции не заявила, так что в Safari и Firefox свойства, скорее всего, не будет. Но подавляющая часть продакшн-автоматизации — Playwright, Puppeteer, nodriver, Patchright, агентные браузеры — построена именно на Chromium. То есть сигнал прилетает ровно в ту нишу, где его меньше всего ждут.
Больнее всего противоречие бьёт по эмуляции мобильных профилей. Если антидетект-профиль выдаёт себя за Android-смартфон, а cpuPerformance под ним отвечает «4», потому что браузер физически запущен на десктопе с Ryzen, — это не мелкая неточность, а взаимоисключающая пара сигналов. То же с ферма-сценариями, где десятки профилей с разными «устройствами» живут на одной хостовой машине и потому дают идентичный тир.
Что это меняет для парсинг-стека
Несколько практических следствий для тех, кто гоняет headless-браузеры пачками.
- Контейнеры наследуют хост. Браузер в докере видит ядра хостовой машины, а не лимиты cgroup, — значит, десять контейнеров на одном жирном сервере дадут десять одинаковых максимальных тиров. Разнообразие профилей, которое вы старательно рисовали в user-agent, на уровне железа отсутствует.
- Дешёвая VPS теперь заметнее. Два vCPU — это первый тир, а первый тир на десктопном Chrome под Windows встречается у живых людей нечасто. Раньше слабый сервер был просто медленным; теперь он ещё и помечен.
- Сигнал бесплатен для сайта. Тяжёлые проверки вроде тайминговых бенчмарков сайты включают выборочно, потому что они стоят времени пользователя. Чтение свойства не стоит ничего, поэтому его добавят в базовый набор даже те площадки, которые раньше ограничивались IP-репутацией и заголовками.
- Он ляжет рядом с Compute Pressure. В релиз-нотах Chrome прямо предлагают сочетать новый API с Compute Pressure API — то есть комбинация «класс железа плюс наблюдаемая нагрузка» изначально задумана как штатный сценарий, и антиботам не придётся ничего изобретать.
Отдельно стоит пересмотреть допущение, что достаточно один раз собрать «хороший» профиль и переиспользовать его годами. Браузеры добавляют такие свойства без анонсов для конечных пользователей: между релизом Chrome 152 и первыми публичными разборами прошли недели, в течение которых профили спокойно отдавали новое поле, ни о чём не подозревая. Проверять набор полей имеет смысл раз в цикл релизов, а не раз в год.
Что делать практически
- Снимите текущее значение. В консоли профиля:
navigator.cpuPerformance,navigator.hardwareConcurrency,navigator.deviceMemoryи строка рендерера WebGL. Записывайте четвёркой, а не по одному полю — вас будут проверять именно связкой. - Сверьте тир с легендой профиля. Мобильная легенда — первый–третий тир, бюджетный ноутбук — второй–третий, флагманский десктоп — четвёртый. Тир 4 под видом старого Android или тир 1 под видом MacBook на M-серии одинаково подозрительны.
- Не правьте свойство в лоб. Подмена через
Object.definePropertyловится по следам переопределения геттера и по расхождению с реальной скоростью исполнения. Если и менять, то на уровне сборки браузера или через встроенные механизмы. - Помните про легальный оверрайд. Chrome даёт пользователю ручку в настройках (Performance → Speed → Override CPU performance tier), а администраторам — корпоративную политику. Это полезно знать с двух сторон: значение может быть не только «настоящим», но и выставленным руками, а массово одинаковый оверрайд на пуле профилей сам становится меткой.
- Разнесите профили по разному железу. Если все ваши профили сидят на одном сервере, тир у них будет одинаковый — независимо от того, какие устройства они изображают. Это тот случай, когда парк из нескольких машин разной конфигурации честно решает проблему, а патч — нет.
Детальнее про соседний сигнал того же семейства — в разборе отпечатка по объёму памяти устройства, а по стелс-браузерам, которые с такими свойствами работают из коробки, есть бенчмарк nodriver, Camoufox и Patchright.
Где здесь прокси
Прямо скажем: прокси не чинит отпечаток браузера. cpuPerformance считается на стороне клиента, и никакой IP его не изменит. Но антибот принимает решение по сумме слоёв, и именно на стыке слоёв обычно и происходит провал.
Типовая цепочка, по которой валятся дешёвые сетапы, выглядит так: IP из известной хостинг-сети, первый тир процессора, headless-признаки в JS — три независимых сигнала, каждый из которых по отдельности терпим, а вместе они складываются в однозначный вердикт. Убрать сетевой слой из этой суммы дешевле и надёжнее, чем воевать с браузерными полями: с резидентного IP запрос выглядит как трафик обычного домашнего провайдера, и «датацентровая» гипотеза у детектора отпадает сама. Для мобильных легенд логика та же — мобильный прокси должен подпирать мобильный профиль, иначе противоречие просто переезжает с процессора на сеть.
Коротко
Chrome 152 добавил не столько новый отпечаток, сколько новую строку в таблице перекрёстных проверок. Два с небольшим бита сами по себе никого не выдают — выдаёт несогласованность: заявленное устройство должно совпадать с классом процессора, объёмом памяти, видеокартой, скоростью исполнения и сетью, из которой пришёл запрос. Аудит профилей на этой неделе стоит начать с одной строки в консоли и вопроса «а такое железо вообще бывает у того, за кого мы себя выдаём?».