Каждый лишний мегабайт трафика парсера — это либо оплата прокси-провайдеру, либо риск попасть под лимиты и получить бан по IP. Если вы собираете цены с Wildberries, Ozon или мониторите объявления на Авито через сотни прокси-адресов, экономия трафика напрямую влияет на бюджет проекта. В этой статье — конкретные технические приёмы, которые позволяют сократить объём передаваемых данных в 4-5 раз, сохранив при этом полноту и точность извлекаемой информации.
Почему трафик парсера бьёт по бюджету
Большинство прокси-провайдеров тарифицируют резидентные и мобильные прокси по объёму переданных гигабайт, а не по времени использования. Если ваш парсер грузит страницу товара Wildberries полностью — с картинками, скриптами рекомендаций, трекерами аналитики и шрифтами — вы платите за 2-3 МБ на одну карточку, хотя реально нужны 15-20 КБ текста: название, цена, рейтинг, наличие.
При масштабировании до 50 000-100 000 карточек в сутки разница между «грузить всё» и «грузить только нужное» превращается в десятки гигабайт лишнего трафика ежедневно. Это не только расходы на прокси, но и повышенная нагрузка на целевой сайт, что увеличивает шанс попасть под антибот-защиту и получить капчу или временный бан IP. Оптимизация трафика — это одновременно экономия денег и снижение риска блокировок.
Есть и третий эффект: чем меньше данных передаётся за один запрос, тем быстрее выполняется сам запрос. Это позволяет увеличить параллелизм — запускать больше потоков на том же количестве прокси без превышения лимитов скорости, которые выставляют антидетект-браузеры типа Dolphin Anty или AdsPower при работе с сессиями.
Приём 1: Блокировка картинок, CSS и шрифтов
Если парсер работает через headless-браузер (Playwright, Puppeteer, Selenium) — самый быстрый способ сократить трафик в 2-3 раза — заблокировать загрузку статических ресурсов, которые не влияют на данные в DOM. Изображения товаров, шрифты веб-сайта, видео и CSS-стили занимают до 70% веса страницы, но никак не участвуют в извлечении текста и атрибутов.
from playwright.sync_api import sync_playwright
def block_heavy_resources(route, request):
if request.resource_type in ["image", "media", "font", "stylesheet"]:
route.abort()
else:
route.continue_()
with sync_playwright() as p:
browser = p.chromium.launch(headless=True)
page = browser.new_page()
page.route("**/*", block_heavy_resources)
page.goto("https://example.com/product/123")
html = page.content()
browser.close()
Аналогичная логика реализуется в Puppeteer через page.setRequestInterception(true) и в Selenium через настройку профиля Chrome с параметром profile.managed_default_content_settings.images: 2. На практике эта одна настройка сразу срезает от 50% до 70% трафика при парсинге маркетплейсов, где страницы перегружены визуальным контентом и рекламными баннерами.
Приём 2: HTTP-запросы вместо полноценного браузера
Многие используют Selenium или Playwright там, где это не нужно. Если страница не требует выполнения JavaScript для отрисовки данных (это легко проверить, открыв «Просмотр кода страницы» вместо DevTools), гораздо выгоднее забирать HTML напрямую через библиотеки requests или httpx в Python. Такой запрос весит килобайты, а не мегабайты, потому что не тянет за собой рендеринг движка браузера, сетевые вызовы для трекеров и второстепенные ресурсы.
import httpx
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
"Accept-Encoding": "gzip, br",
"Accept": "text/html,application/xhtml+xml"
}
proxies = {"http://": "http://user:pass@proxy_host:port",
"https://": "http://user:pass@proxy_host:port"}
with httpx.Client(headers=headers, proxies=proxies, http2=True) as client:
response = client.get("https://example.com/catalog/item/456")
print(len(response.content), "байт получено")Переход с браузерной эмуляции на прямые HTTP-запросы там, где сайт отдаёт готовый HTML без клиентского рендеринга, снижает трафик в 3-8 раз. Единственный нюанс — такие запросы легче отличить от настоящего пользователя, поэтому для сайтов с жёсткой антибот-защитой стоит комбинировать этот метод с качественными резидентными прокси, которые выдают IP реальных домашних провайдеров и снижают вероятность блокировки запроса.
Приём 3: Парсинг через скрытые JSON API
Практически все современные маркетплейсы — включая Wildberries, Ozon и Яндекс.Маркет — отрисовывают карточки товаров и списки через внутренние JSON API, которые вызывает фронтенд. Найти эти эндпоинты можно через вкладку Network в DevTools, отфильтровав запросы по типу XHR/Fetch. Как правило, один такой запрос отдаёт JSON на 5-30 КБ с чистыми данными: id товара, цена, скидка, остатки, рейтинг — без единого байта HTML-разметки или CSS.
Разница в объёме передаваемых данных между полной HTML-страницей и прямым обращением к JSON API может достигать 10-15 раз. Дополнительный плюс — JSON проще парсить программно: не нужны XPath-селекторы, достаточно обратиться к нужному полю по ключу словаря. Минус — такие эндпоинты часто требуют специфических заголовков, токенов сессии или параметров подписи запроса, которые нужно предварительно извлечь из основной страницы или мобильного приложения.
Совет практикам
Перед тем как строить парсер вокруг скрытого API, проверьте мобильную версию сайта или приложение через прокси-перехватчик (Charles Proxy, Fiddler) — мобильные API часто отдают более компактный и стабильный JSON, чем десктопная версия сайта.
Приём 4: Сжатие Gzip и Brotli
Даже если вы вынуждены забирать полный HTML, включение правильного сжатия способно сократить размер передачи на 60-80%. Многие самописные парсеры не отправляют заголовок Accept-Encoding: gzip, br, из-за чего сервер отдаёт неупакованный ответ. Библиотеки requests и httpx распаковывают Gzip и Brotli автоматически — важно лишь явно указать поддержку сжатия в заголовках запроса.
Brotli в среднем сжимает текстовый HTML сильнее, чем Gzip, на 15-20%, но не все серверы поддерживают этот алгоритм — стоит запрашивать оба варианта и позволить серверу выбрать оптимальный. Для JSON API эффект от сжатия ещё заметнее: повторяющиеся ключи словарей («price», «name», «rating») сжимаются практически идеально, снижая вес ответа в разы.
Приём 5: Условные запросы и кэширование
Если вы мониторите цены на одних и тех же товарах несколько раз в день, большая часть карточек между проверками не меняется. Используйте заголовки If-Modified-Since и If-None-Match с значением ETag, полученным при первом запросе. Если контент не изменился, сервер отдаёт статус 304 Not Modified практически без тела ответа — экономия трафика доходит до 95% на неизменившихся страницах.
import httpx
etag_store = {}
def fetch_with_cache(url, client):
headers = {}
if url in etag_store:
headers["If-None-Match"] = etag_store[url]
resp = client.get(url, headers=headers)
if resp.status_code == 304:
return None # данные не изменились
etag_store[url] = resp.headers.get("ETag", "")
return resp.contentНе все сайты поддерживают ETag корректно, но для тех, что поддерживают, этот приём становится самым эффективным способом сократить трафик при регулярном мониторинге — вы фактически платите только за реальные изменения данных, а не за повторную загрузку неизменного контента.
Приём 6: Выборочный парсинг нужных полей
Иногда сократить входящий трафик со стороны сервера невозможно — сайт отдаёт полную страницу целиком независимо от запроса. В этом случае оптимизация происходит на этапе обработки: не загружайте страницу повторно только для того, чтобы извлечь ещё одно поле. Спроектируйте XPath или CSS-селекторы так, чтобы за один проход по DOM извлекать сразу все нужные атрибуты — цену, название, артикул, наличие, рейтинг — вместо повторных запросов к тому же URL с разными парсерами под разные задачи.
Также полезно ограничивать глубину обхода вложенных страниц. Если для мониторинга цен достаточно данных со страницы категории (списка товаров), не переходите на карточку каждого товара отдельно — это дублирующий трафик, который часто не даёт новой информации, кроме описания и отзывов, не влияющих на цену и наличие.
Приём 7: Оптимизация паттерна обхода
Дедупликация URL — базовый, но часто игнорируемый приём. Каталоги маркетплейсов генерируют множество ссылок с одинаковым содержанием, но разными параметрами сортировки, UTM-метками или ID сессии. Нормализация URL перед постановкой в очередь (удаление трекинговых параметров, сортировка query-параметров) убирает 10-30% избыточных запросов при обходе крупных каталогов.
Приоритизация обхода по частоте изменения данных также экономит трафик: товары с высоким спросом и волатильной ценой стоит проверять каждый час, а редкие позиции — раз в сутки. Такой адаптивный график вместо равномерного обхода всех карточек с одинаковой периодичностью снижает общий объём запросов в 2-4 раза без потери актуальности критичных данных.
Как это сочетается со стратегией прокси
Сокращение трафика напрямую влияет на выбор типа прокси. Если вы парсите крупный объём страниц с прямых HTTP-запросов без сложной антибот-защиты, достаточно быстрых и дешёвых прокси дата-центров — они дают высокую скорость передачи при низкой стоимости за гигабайт, что критично при масштабном парсинге тысяч карточек в день.
Для сайтов с жёсткой защитой от ботов, где важно имитировать поведение реального пользователя, лучше использовать резидентные прокси — совмещая их с приёмами блокировки лишних ресурсов, вы получаете и низкий трафик, и высокую степень доверия сайта к запросу. А если парсинг ведётся через мобильные версии API маркетплейсов, где данные компактнее и антибот-система ориентируется на мобильные IP-диапазоны, стоит рассмотреть мобильные прокси для дополнительного снижения риска блокировок.
Комбинация «минимальный трафик на запрос» + «правильный тип прокси под задачу» позволяет одновременно сократить расходы на инфраструктуру и увеличить скорость сбора данных без потери надёжности.
Сравнительная таблица приёмов
| Приём | Снижение трафика | Сложность внедрения |
|---|---|---|
| Блокировка картинок/CSS/шрифтов | 50-70% | Низкая |
| HTTP-запросы вместо браузера | 3-8 раз | Средняя |
| Скрытые JSON API | 10-15 раз | Высокая |
| Gzip/Brotli сжатие | 60-80% | Низкая |
| Условные запросы (ETag) | до 95% на неизменных страницах | Средняя |
| Дедупликация URL и приоритизация | 2-4 раза | Средняя |
Чек-лист внедрения
- Проверить, требует ли целевая страница JavaScript-рендеринг, или можно забирать HTML напрямую через
httpx/requests - Настроить блокировку image/media/font/stylesheet в headless-браузере, если браузер всё же нужен
- Найти внутренние JSON API через DevTools → Network → XHR/Fetch
- Добавить заголовки
Accept-Encoding: gzip, brво все запросы - Реализовать хранение ETag/Last-Modified для условных запросов на повторяющихся URL
- Нормализовать и дедуплицировать очередь URL перед обходом
- Настроить адаптивную частоту обхода по важности и волатильности данных
- Подобрать тип прокси под итоговый профиль трафика — дата-центр, резидентные или мобильные
Заключение
Сокращение трафика парсера в 5 раз — реалистичная цель, если применять приёмы последовательно: убрать лишние ресурсы, перейти на прямые HTTP-запросы или JSON API там, где это возможно, включить сжатие, использовать условные запросы для неизменных данных и оптимизировать сам паттерн обхода. Каждый из этих шагов даёт измеримый эффект, а в совокупности они кардинально меняют экономику проекта по сбору данных с маркетплейсов и других сайтов.
После оптимизации трафика важно правильно подобрать инфраструктуру прокси под новый профиль нагрузки. Для быстрого и дешёвого сбора больших объёмов данных подойдут прокси дата-центров, а для работы с сайтами со строгой антибот-защитой — резидентные прокси с реальными IP-адресами домашних провайдеров, которые снижают риск блокировки даже при интенсивном парсинге.