프록시 대역폭 비용 절감 방법: GB 요금 60-90% 절감하기
GB당 과금되는 프록시에서는 청구서가 요청이 아닌 바이트로 계산됩니다. 그리고 대부분의 바이트는 파싱하지 않는 이미지와 폰트입니다. 이를 제거하고 주거용 GB 요금을 절반 이상 줄이는 방법을 소개합니다.
GB당 과금되는 프록시에서는 청구서가 요청이 아닌 바이트로 계산됩니다. 불편한 진실은 대부분의 바이트가 파싱하지 않는 이미지, 폰트 및 스타일시트라는 것입니다. 단일 고해상도 제품 사진은 2.2 MB일 수 있으며, 전체 브라우저 렌더링은 한 페이지당 2-5 MB입니다. 실제로 추출하는 간결한 HTML은 종종 150 KB 미만입니다. 나머지를 제거하면 주거용 GB 요금이 60-90% 감소합니다. 이 가이드는 실용적인 플레이북입니다: 자산 차단, 변경되지 않은 페이지 건너뛰기, 압축, HTML 대신 JSON으로 라우팅.
먼저, 청구되는 항목을 알아야 합니다
주거용 대역폭은 요청 헤더와 요청 본문, 응답 헤더와 응답 본문을 포함한 양방향으로 전송된 데이터의 합계로 측정됩니다. 즉, 페이지가 불러오는 모든 자산 — 이미지, 폰트 및 추적 스크립트가 모두 청구서에 포함됩니다. 최적화 목표는 간단합니다: 추출하는 바이트만 다운로드하세요. 나머지는 낭비이며, 비용을 지불하고 있는 것입니다.
헤드리스 브라우저에서 자산 차단
브라우저를 구동하는 경우, 이것이 가장 큰 레버입니다. Playwright와 Puppeteer는 요청을 가로채고 필요하지 않은 리소스 유형을 중단할 수 있습니다. 이미지, 미디어, 폰트 및 스타일시트를 차단하면 페이지 무게가 대부분 줄어듭니다 — DOM은 여전히 생성되므로 선택자와 모든 하이드레이션 JSON은 살아남습니다:
// Playwright: abort the resource types you never parse
await page.route('**/*', (route) => {
const type = route.request().resourceType();
if (['image', 'media', 'font', 'stylesheet'].includes(type)) {
return route.abort();
}
return route.continue();
});
await page.goto(url, { waitUntil: 'domcontentloaded' });
두 가지 주의 사항: 데이터를 가져오는 XHR/fetch 호출을 차단하지 말고, 페이지가 여전히 필요한 것을 렌더링하는지 테스트하세요 — 과도한 차단은 사이트 자체의 논리를 깨뜨릴 수 있습니다. 브라우저를 일반 요청과 비교하고 있다면, 렌더링 비용 대 HTTP 요청 비용에 대한 우리의 분석은 이 결정이 중요한 10-50배 차이를 보여줍니다.

변경되지 않은 페이지 건너뛰기
가장 저렴한 바이트는 다운로드하지 않는 바이트입니다. 모니터링 작업에서 재요청 낭비를 줄이는 두 가지 기술이 있습니다. HEAD 요청은 전체 GET을 수행하기 전에 Content-Length 또는 Last-Modified를 확인하기 위해 헤더만 가져옵니다. 더 나은 방법은 조건부 GET이 마지막 시간의 ETag 또는 타임스탬프를 보내고 서버가 변경되지 않았을 때 빈 본문으로 304 Not Modified를 응답하는 것입니다 — 전체 페이지 대신 몇 바이트의 헤더에 대한 비용을 지불합니다:
import requests
# conditional GET: 304 = near-zero bytes when unchanged
headers = {"If-None-Match": last_etag,
"If-Modified-Since": last_seen}
r = requests.get(url, headers=headers, proxies=proxies, timeout=20)
if r.status_code == 304:
pass # unchanged, no body downloaded, no GB spent
else:
process(r.content)
last_etag = r.headers.get("ETag")
매일 같은 페이지를 다시 확인하는 스크래퍼의 경우, 조건부 GET만으로도 대역폭을 크게 줄일 수 있습니다, 대부분의 페이지는 실행 간에 변경되지 않기 때문입니다.
항상 압축을 수락하세요
텍스트는 잘 압축됩니다 — HTML, JSON 및 CSS는 gzip 또는 brotli로 70-90% 축소됩니다 — 그리고 실제로 전송되는 압축된 크기로 청구됩니다. Accept-Encoding 헤더를 보내고 서버가 압축하도록 하세요. Python의 requests에서는 기본적으로 활성화되어 있으며, 원시 클라이언트에서는 명시적으로 요청하세요:
headers = {"Accept-Encoding": "gzip, deflate, br"}
r = requests.get(url, headers=headers, proxies=proxies, timeout=20)
# requests transparently decompresses; you're billed on the small size
JSON으로 라우팅, HTML이 아닌
가장 큰 구조적 승리는 렌더링된 페이지를 완전히 건너뛰는 것입니다. 많은 사이트는 동일한 데이터를 훨씬 적은 바이트로 전달하는 JSON 엔드포인트에서 하이드레이션합니다 — 3 MB 렌더링된 페이지 대신 10 KB API 응답으로 제품의 가격과 재고를 전달합니다. 브라우저의 네트워크 탭에서 XHR 호출을 찾아 직접 접근하세요. Shopify 스토어가 고전적인 예입니다: products.json 엔드포인트는 HTML 없이 전체 카탈로그를 제공합니다. API를 읽을 수 있을 때는 그렇게 하세요 — 레코드당 킬로바이트와 메가바이트의 차이입니다.
API가 바이트를 계산하게 하세요
사이트별로 차단 규칙을 세밀하게 조정하고 싶지 않다면, 필요할 때만 렌더링하고 파싱된 markdown 또는 JSON을 반환하는 Scraper API가 자산 제거를 대신 해줍니다 — 추출된 콘텐츠를 받게 되며, 그것이 나온 메가바이트는 아닙니다. 그리고 GB당 과금되는 주거용 프록시에서는 절감이 직접적입니다: 전송되는 바이트가 적을수록 청구서의 금액도 줄어들며, 보유하는 데이터에서 손실되는 것은 없습니다. 기가바이트가 실제로 무엇을 구매하는지에 대한 전체 그림은 GB당 가격 설명을 참조하세요.

GB당 과금되는 주거용 프록시에서 더 간결하게 스크래핑하기
자주 묻는 질문
프록시 대역폭은 어떻게 계산되나요?
양방향으로 전송된 총 바이트로 계산됩니다: 요청 헤더와 요청 본문, 응답 헤더와 응답 본문. 따라서 페이지가 로드하는 모든 이미지, 폰트 및 스크립트가 사용량에 포함되며, 파싱하는 HTML만 포함되는 것이 아닙니다. 사용되지 않는 자산을 차단하고 변경되지 않은 페이지를 건너뛰는 것이 GB당 요금제에서 청구서를 직접 줄이는 이유입니다.
이미지를 차단하면 스크래핑이 깨지나요?
주의하면 그렇지 않습니다. 이미지를 차단하고, 미디어, 폰트 및 스타일시트를 차단해도 DOM과 JavaScript는 그대로 남아 있으므로 선택자와 모든 하이드레이션 JSON은 여전히 작동합니다 — 시각적 페이로드만 건너뛰는 것입니다. 위험은 과도한 차단입니다: 데이터를 가져오는 XHR/fetch 호출을 절대 중단하지 말고, 대규모로 실행하기 전에 페이지가 여전히 필요한 것을 생성하는지 테스트하세요.
가장 큰 대역폭 절감은 무엇인가요?
존재하는 경우, 전체 페이지를 렌더링하는 대신 JSON 엔드포인트로 라우팅하는 것입니다. 10 KB API 응답이 동일한 레코드에 대해 3 MB 렌더링을 대체할 수 있으며 — 99% 절감입니다. 그 후, 헤드리스 브라우저에서 자산을 차단하고 재크롤 시 조건부 GET을 사용하는 것이 가장 큰 승리입니다. 압축은 거의 무료이며 항상 켜져 있어야 합니다.
실제로 얼마나 절감할 수 있나요?
자산 차단은 일반적으로 렌더링된 페이지의 무게를 절반 이상 줄이며; 조건부 GET은 변경되지 않은 페이지에 대한 재크롤 대역폭을 거의 0으로 줄일 수 있으며; HTML에서 JSON 경로로 전환하면 종종 레코드당 90% 이상의 절감이 가능합니다. 이를 모두 결합하면, 주거용 GB 요금서를 60-90% 절감하는 것이 대부분의 프로젝트에서 현실적인 목표입니다.
이 중 어느 것도 추출하는 것을 변경하지 않습니다 — 추출하는 데 드는 비용을 변경합니다. 읽지 않는 자산을 차단하고, 이동하지 않은 페이지를 건너뛰고, 압축을 수락하고, 전체 렌더링 대신 JSON 경로를 선호하세요. GB당 과금되는 프록시에서는 이 네 가지 습관이 청구서를 절반 이상 줄이는 데 자주 사용됩니다. 수백만 페이지에 걸쳐 이를 확장하는 아키텍처에 대해서는 대규모 스크래핑 아키텍처에 대한 가이드를 참조하세요.