Кого обслуживает сайт на старте: пользователей или ботов? Как оценить производительность по реальным данным
Всё началось с экспериментов с искусственным интеллектом. С 2026 года ИИ-инструменты стали достаточно зрелыми, чтобы с их помощью самостоятельно собирать крупные проекты, практически не привлекая разработчиков. В моём случае основным рабочим инструментом стал Claude. А поскольку рынок ИИ развивается очень быстро, потребовался собственный способ постоянно отслеживать новости и изменения.
Так появился текстовый сайт-агрегатор публикаций об искусственном интеллекте. Проект подключён примерно к ста источникам: официальным блогам компаний, сайтам разработчиков, отраслевым медиа и новостным агрегаторам. Система собирает материалы, переводит неанглоязычные публикации, удаляет повторы, распределяет новости по тематическим рубрикам, переводит их на 15 языков и публикует в собственной ленте. Дополнительно русскоязычные записи отправляются в Telegram, а полный многоязычный поток доступен через RSS.
Для обработки контента используются несколько ИИ-сервисов, подключённых по API. При этом сам сайт предельно простой: только текст, без изображений, тяжёлых вычислений и сложного рендеринга. Казалось бы, такой проект не должен предъявлять серьёзных требований к серверу. Однако практика показала обратное.
Сайт размещён на виртуальной машине с Ubuntu без графической оболочки. Физический сервер располагает 64 ГБ оперативной памяти, 12 процессорными ядрами, SSD на 500 ГБ и сетевым каналом 1 Гбит/с. Изначально для проекта выделили два ядра и около 2 ГБ памяти. Через неделю после запуска выяснилось, что даже при наличии единственного реального пользователя сайт работает крайне медленно. Для стабильной работы пришлось увеличить доступную память примерно до 6 ГБ и добавить ещё два ядра.
Причина обнаружилась во время нескольких дней наблюдений. Сайт почти сразу после публикации начали посещать около 25 тысяч автоматизированных клиентов. География IP-адресов оказалась очень широкой: запросы поступали из разных стран, дата-центров и облачных сетей. Среди немногочисленных реальных посетителей были фактически только владелец проекта. Получалось, что сервер в основном обслуживал не людей, а роботов, сканеры и краулеры.
Такая ситуация важна не только для конкретного агрегатора. Владелец нового проекта может считать, что на старте у него почти нет аудитории и достаточно минимальных ресурсов. Но фактическая нагрузка нередко формируется автоматическими системами: поисковыми роботами, скраперами, сервисами анализа сайтов, сборщиками данных и ботами, которые извлекают контент для обучения собственных моделей. Поэтому [оценка реальной нагрузки сайта](https://habr.com/ru/articles/1073398/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1073398) должна учитывать не только число людей в статистике посещений.
Как отличить человека от автоматического клиента
Первый уровень анализа - заголовки HTTP-запроса. Обычный браузер отправляет достаточно характерный набор параметров. Примитивный скрапер часто ограничивается минимальным набором заголовков или копирует их неточно. Уже на этом этапе можно обнаружить часть автоматизированного трафика.
Отдельно стоит учитывать известных роботов. Поисковые системы, служебные краулеры и некоторые агрегаторы используют узнаваемые значения User-Agent. Однако полагаться исключительно на этот признак нельзя: злоумышленник или простой скрипт способен подменить строку браузера.
Более надёжный вариант - проверять выполнение JavaScript. Настоящий браузер исполняет код, загружает дополнительные элементы страницы и формирует характерную последовательность запросов. Примитивная программа, скачивающая HTML, обычно не повторяет такое поведение.
Ещё сильнее помогает анализ действий пользователя. Человек прокручивает страницу, нажимает кнопки, переключает язык, открывает несколько материалов и проводит на сайте некоторое время. Автоматический клиент чаще всего получает документ и завершает соединение за доли секунды. Само наличие прокрутки или другого действия не даёт стопроцентной гарантии, но в совокупности с остальными признаками заметно повышает точность фильтрации.
Полезен и анализ языковых версий. Пользователь обычно выбирает один понятный ему язык, а если нужного варианта нет, переходит на английскую версию. Робот, напротив, может последовательно запросить множество локализаций за короткий период. Посетитель, который за сутки обращается к страницам на десятке языков, скорее всего, является автоматизированной системой.
Интересный показатель - сочетание страны и языка. Для реальной аудитории обычно прослеживается естественная связь между географией и выбранной локализацией. Дата-центры и прокси-сети дают другую картину: множество стран, разные языки, минимальное время на странице и большое число запросов с каждого адреса.
Что делать с ботами
Есть несколько стратегий. Самая простая - ничего не менять, принять автоматический трафик как неизбежный и оставить увеличенные ресурсы сервера. Такой подход подходит, если стоимость инфраструктуры невелика, а боты не мешают пользователям.
Второй вариант - поставить сайт за CDN и защитный сервис, например Cloudflare. Он способен фильтровать часть подозрительных запросов ещё до того, как они попадут на сервер приложения. Однако для проектов, размещённых в России или ориентированных на российскую аудиторию, такой вариант может быть недоступен или неудобен из-за сетевых и организационных ограничений.
Третий путь - реализовать фильтрацию самостоятельно, на максимально раннем этапе обработки запроса. Важно не просто блокировать подозрительного клиента после формирования страницы, а отсекать его до того, как приложение потратит процессорное время, память и ресурсы базы данных.
Именно такой подход полезен как практический эксперимент. Он позволяет понять, какая часть нагрузки создаётся людьми, а какая - роботами, а также провести [тестирование нагрузки сайта](https://habr.com/ru/articles/1073398/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1073398) в условиях, близких к реальной эксплуатации.
Почему стандартной аналитики недостаточно
Счётчик посещений часто показывает только тех клиентов, которые выполнили JavaScript. Значительная часть краулеров в такую статистику не попадает. Серверные журналы, напротив, фиксируют каждый запрос, но без дополнительной классификации не объясняют, кто именно его отправил.
Поэтому для точного анализа нужно сопоставлять несколько источников: access-логи веб-сервера, User-Agent, IP-адреса, частоту запросов, длительность сессии, последовательность переходов, языковые версии и выполнение клиентских скриптов. Такой набор данных даёт более реалистичную картину, чем один показатель посещаемости.
На практике мониторинг нагрузки на сайт должен включать не только CPU и память, но и количество запросов, долю ответов по кодам HTTP, задержки, число одновременных соединений, сетевой трафик и распределение нагрузки между людьми и автоматическими клиентами. Иначе можно ошибочно решить, что серверу не хватает мощности, хотя проблема заключается в неотфильтрованном потоке роботов.
Дополнительные меры защиты
Помимо поведенческих признаков, полезно вводить ограничения частоты запросов. Для IP-адресов, подсетей, ASN и подозрительных User-Agent можно применять разные лимиты. При этом жёсткая блокировка по одному адресу не всегда эффективна: крупные боты используют распределённые сети и постоянно меняют точки выхода.
Стоит кешировать неизменяемые страницы и заголовки, чтобы повторный запрос не запускал весь процесс обработки. Для многоязычного текстового проекта это особенно важно: однажды сформированный материал может обслуживаться из кеша десяткам тысяч клиентов без повторного обращения к приложению.
Отдельный слой - защита административных и API-эндпоинтов. Если публичные новости можно отдавать относительно свободно, то служебные методы, генерация переводов и обращения к внешним ИИ-сервисам должны иметь строгую авторизацию, лимиты и очереди. Иначе бот способен не только перегрузить веб-сервер, но и увеличить расходы на сторонние API.
В результате оптимизация производительности сайта начинается не с бездумного увеличения числа ядер. Сначала необходимо понять структуру трафика и определить, кто именно потребляет ресурсы. Только после этого имеет смысл выбирать между кешированием, фильтрацией, CDN, ограничением запросов и масштабированием инфраструктуры. Такой подход обеспечивает ускорение сайта и повышение производительности без постоянного наращивания серверных мощностей.
Для публичных проектов, которые быстро становятся заметными поисковым системам и автоматическим сборщикам, защита сайта от ботов и DDoS-атак должна рассматриваться уже на этапе запуска. Даже простой сайт без изображений и сложной логики способен оказаться под значительной нагрузкой - не из-за реальных читателей, а из-за тысяч машин, которые начинают обходить его раньше первой человеческой аудитории.