--bot-performance-timing: временные сигналы и отпечаток браузера
Разберите базовый и расширенный режимы --bot-performance-timing, наблюдаемые API Performance Timing и границы проверок через прокси и anti-bot системы.
Нужна структурированная документация по теме Отпечатки?
Эта статья относится к редакционной библиотеке. Для пошаговой настройки, справки и постоянных обновлений переходите сразу в соответствующий раздел docs.
--bot-performance-timing управляет временными поверхностями на уровне движка, чтобы страница видела согласованный жизненный цикл. Флаг не обещает принятие сессии сайтом и не скрывает сетевые сведения, которые видны через прокси. Практический вопрос уже: описывают ли значения правдоподобную навигацию и загрузку ресурсов?
Что контролирует флаг
Страница может читать performance.now(), PerformanceNavigationTiming, PerformanceResourceTiming и устаревший объект performance.timing. Изменение только одного свойства создаёт противоречие. Флаг меняет модель браузера так, чтобы разные представления описывали один цикл.
BotBrowser описывает два уровня. Базовый сохраняет правдоподобные и согласованные значения для обычного профиля. Расширенный применяет документированные интервалы, точные параметры которых пока экспериментальны. В issue не задан глобальный или страничный seed: воспроизводимая ссылка - неизменяемый запрос сырых временных данных и его стабильное резюме. Это описание области действия, а не оценка детектора и не гарантия незаметности.
Перед выбором режима определите окно наблюдения. Холодный первый визит, восстановленная страница и переход в одностраничном приложении дают разные наборы событий. Контекст рядом с режимом помогает не принять ожидаемое различие за ошибку конфигурации.
Базовый режим: согласованный цикл
Базовый режим сохраняет порядок фаз: начало запроса предшествует ответу, настоящая навигация имеет ненулевые этапы, а повторное чтение одной записи стабильно. Современные записи и старый объект используют один жизненный цикл.
Результаты всё равно зависят от кэша, сети, перенаправлений, фоновых сценариев и планирования процессора. Повторные чтения должны быть стабильны для завершённых записей ресурсов и навигации после responseEnd; до responseEnd допускается один переход от базового к расширенному режиму при финализации навигации. Цель флага - убрать искусственное противоречие выборочного патча, а не сделать все страницы одинаковыми. Время следует считать диагностическим контекстом, а не идентификатором.
Базовый режим удобен как исходная точка совместимости. Запускайте его с обычной точностью приватности и поддерживаемыми состояниями кэша. Если измерение недоступно, используйте документированный запасной путь, а не подставляйте искусственное число.
Расширенный режим: экспериментальные интервалы представлений
Расширенный режим применяет документированные интервалы, сохраняя форму корректной навигации. Глобального или страничного seed нет. Повторные чтения стабильны для завершённых записей ресурсов и навигации после responseEnd; до responseEnd при финализации записи допускается один переход от базового к расширенному режиму. Параметры интервалов остаются экспериментальными, поэтому сравнивайте ограниченные нагрузки, а не идентичность.
Публичный контракт охватывает getEntries(), записи навигации и ресурсов, performance.timing и performance.toJSON(). Он также называет неизменяемый запрос сырых временных данных и стабильное резюме, но не задаёт глобальный или страничный seed. Проверка должна сопоставлять представления: соответствующие этапы остаются в указанном допуске и описывают одну последовательность событий. Расширенный режим - экспериментальная конфигурация интервалов, а не новая идентичность с seed.
Конфигурацию интервалов следует рассматривать как экспериментальные тестовые данные. Стабильное резюме относится к неизменяемому запросу сырых временных данных, а не к глобальному или страничному seed, и не делает детерминированными нагрузку сервера, планирование ОС или меняющийся JavaScript-бандл. При сравнении запусков сохраняйте эти переменные.
Что наблюдает страница
Performance предоставляет длительности и записи с учётом точности и ограничений приватности браузера. Можно видеть этапы навигации, загрузки ресурсов, собственные метки и старый объект, если он доступен. Можно сравнивать порядок, нулевые и ненулевые состояния и связи между записями.
Это сведения о текущем документе и его загрузке, а не надёжная оценка процессора или личности. Кэш, фоновые задачи и политика браузера меняют измерения. В руководстве по временным сигналам эта поверхность рассматривается вместе с другими, но не смешивается с ними.
Такое разделение полезно при разборе инцидента. Медленный ресурс может быть следствием промаха кэша, маршрута или работы приложения после ответа. Начните с жизненного цикла и владельца измерения, а соседние сигналы проверяйте только для другого вопроса.
Пересечение с прокси и anti-bot
Время - лишь один слой. Сервис может сопоставлять этапы браузера со временем прихода запросов на сервер, повторным использованием соединений, перенаправлениями и заголовками кэша. Прокси способен добавить задержку или изменить маршрут, не меняя локальные API. Правдоподобные локальные значения не исправляют несогласованные маршрут, TLS-профиль или репутацию IP.
В авторизованной проверке сравнивайте категории: записи браузера, отметки сервера и события состояния прокси должны отвечать на один операционный вопрос. Задавайте допуски для конкретной нагрузки и не публикуйте пороги детектирования. При пропавшем ресурсе нужен рабочий запасной путь. Дополнительный контекст есть в руководстве по сетевой согласованности.
При расхождении сохраняйте исходную категорию и временную отметку, а не сводите всё к метке «бот». Это позволяет исправить маршрут, политику кэша или регрессию страницы без лишнего изменения режима времени.
Ограничения и ответственное применение
Флаг не расширяет поддержку Performance, не делает разные ОС одинаковыми и не устраняет всю вариативность. Он не выдаёт доступ и не доказывает, что сессия принадлежит человеку. Используйте режимы для воспроизводимых тестов, согласованности профиля и проверки приватности. Не связывайте сырые трассы с аккаунтом и не храните их дольше диагностической задачи.
Перед выпуском проверьте упорядоченные ненулевые этапы, согласие современных и старых представлений и запасной путь при задержке ресурса. Фиксируйте режим и конфигурацию интервалов как параметры теста, а не как идентификатор. После обновления браузера перепроверьте публичный контракт.
Сделайте фикстуру наблюдаемой, но не идентифицирующей. Короткого идентификатора запуска, версии браузера, ревизии профиля и названия нагрузки достаточно, чтобы связать записи страницы, сервера и шлюза. Ограничьте ключ одним запуском, удаляйте параметры запросов перед экспортом и после диагностики храните только агрегаты. Так изменение времени объяснимо без постоянного межсессионного сигнала.
Регрессионная проверка должна сохранять параметры теста, версию браузера и агрегированный результат. Такое разделение позволяет повторить диагностику, не превращая измерение времени в идентификатор.
Безопасное чтение записи навигации
Запись описывает один запрос документа, но фазы имеют разные значения. Перенаправление, служебный воркер, кэш и предварительный рендер меняют видимый цикл. Читайте запись как историю жизненного цикла, а не как один сетевой замер.
Сначала проверьте поддержку API и обработайте пустой список. Восстановление из back-forward cache или ещё не завершённая фаза могут временно не иметь нужных полей. Отсутствие необязательного измерения не должно блокировать задачу и не требует нового идентификатора.
Ресурсное время без лишних выводов
Записи помогают найти медленный скрипт, изображение или запрос, но не являются полной трассировкой сети. Точность, Timing-Allow-Origin, служебный воркер и переполнение буфера могут скрыть или удалить записи.
Для результатов используйте агрегаты вроде «предпросмотр завершён» или «виден запасной шрифт». Явно согласуйте сбор трассы, ограничьте срок хранения и удалите лишние параметры и идентификаторы.
Метки, измерения и работа приложения
performance.mark() и performance.measure() описывают работу, названную самой страницей, а не этапы навигации. Долгое измерение может включать планирование, ввод пользователя или фоновую вкладку.
Сохраняйте стабильные имена и описывайте границы измерения. Отмену и повтор запроса фиксируйте отдельно, чтобы результат был полезен и не создавал межсессионный профиль.
Точность, приватность и повторяемость
Браузер снижает точность часов; изоляция, политика безопасности, фоновые ограничения и обновления меняют разрешение. Проверяйте порядок, разумные ненулевые значения и связи, а не точную дробь.
Расширенный режим подходит для документированных интервалов в контролируемой нагрузке. Записывайте режим, конфигурацию интервалов, версию и профиль теста. Стабильное резюме описывает неизменяемый запрос сырых временных данных, а не свойство пользователя. Нагрузка сервера и сеть всё равно меняются, поэтому сравнивайте диапазоны.
Проверка пути через прокси
Разделяйте ответственность: браузер владеет локальными записями, сервер - временем приёма и статусом, шлюз - состоянием маршрута и сбоями. Сопоставление ищет медленный сегмент, но не обвиняет один слой во всех задержках.
Используйте авторизованный стенд с тёплым и холодным кэшем, перенаправлением, отказом необязательного ресурса и повтором. Сравнивайте фазы и результаты, а сетевые изменения рассматривайте отдельно.
Anti-bot сигналы не являются одним API
Системы могут объединять API браузера, наблюдения сервера, историю аккаунта, частоту и транспортные данные. Флаг исправляет согласованность браузера, но не меняет IP, TLS, cookie или события входа.
В авторизованной интеграции фиксируйте измеримое и неизвестное, не копируйте частную логику испытаний. Проверьте работоспособность при сниженной точности, пропавшей записи или медленном маршруте.
Ограниченный план внедрения
Начните с базового режима и проверьте записи в поддерживаемых браузерах; добавляйте расширенный только для документированного теста с экспериментальными интервалами. Для каждого режима храните проверку современных и старых представлений.
Сравнивайте завершение, отмену, повторы и восстановление, но не сырые трассы пользователей. После обновления сначала проверьте API, точность, кэш и нагрузку, затем меняйте конфигурацию.
Храните короткую запись режима, конфигурации интервалов, версии, фикстуры и агрегата. Если приложение работает без необязательного сигнала, оставьте этот запасной путь.
Ожидаемый запасной путь фиксируйте в критериях приёмки.
Считайте отсутствие записи допустимым результатом при известной политике точности.
Отделяйте состояние кэша от сетевого сбоя.
Связывайте каждую проверку с видимым результатом приложения.
Не меняйте конфигурацию интервалов для компенсации общей потери точности.
Записывайте владельца каждой временной отметки.
Источники
Похожие статьи
Переведите BotBrowser из исследований в продакшн
Используйте эти руководства, чтобы понять модель, а затем перейти к кроссплатформенной валидации, изолированным контекстам и масштабируемому браузерному развертыванию.