Oyun yazarı vs Kuklacı vs istekler: 1000 sayfa üzerindeki trafik

Eğer proxy trafiği için GB başına ödeme yapıyorsanız, headless tarayıcı ile normal bir HTTP istemcisi arasındaki fark, aynı 1000 sayfalık veri setinde size 15-20 kat daha fazla maliyet çıkarabilir. Bu makalede, Playwright, Puppeteer ve Python requests kütüphanesi için gerçek trafik tüketim ölçümleri, testler için kod ve veri kaybı olmadan veri miktarını azaltmanın etkili yolları bulunmaktadır.

Trafik tüketiminin önemi

Çoğu proxy sağlayıcısı, konut ve mobil havuzlar dahil, trafiği GB başına fiyatlandırır, istek sayısına göre değil. Bu, kullandığınız aracın, web sitesini tararken projenizin bütçesini doğrudan etkilediği anlamına gelir. Headless tarayıcı, sayfayı tamamen yükler: HTML, CSS, JavaScript, görseller, yazı tipleri, analitik scriptler, reklam bannerları ve izleyiciler. requests gibi HTTP istemcisi ise yalnızca açıkça talep ettiğiniz şeyleri indirir — genellikle bu, temiz bir HTML belgesidir.

Fark özellikle ölçeklendirme açısından belirgindir. Eğer Wildberries veya Ozon'daki ürün kartlarını tarıyorsanız, rakip fiyatlarını topluyorsanız veya Google arama sonuçlarını izliyorsanız, 1000 sayfa hacmi, bir script için tipik bir günlük normdur. Aylık birkaç yüz bin sayfa ile çalışırken, trafik tasarrufu önemli bir maliyet kalemi haline gelir, özellikle de konut proxy'leri kullanılıyorsa, burada GB maliyeti veri merkezlerinden daha yüksektir.

Ek bir zorluk, modern web sitelerinin botlara karşı aktif olarak korunmasıdır: JavaScript render'ını, fare davranışını, canvas parmak izini kontrol ederler. Bu, geliştiricilerin basit HTTP isteklerinden, Playwright veya Puppeteer gibi tam tarayıcılara geçmelerini zorunlu kılar, bu da trafik açısından çok daha fazla yer kaplar. Kesin rakamları anlamak, proxy için bütçeyi önceden hesaplamaya ve belirli bir görev için doğru aracı seçmeye yardımcı olur.

Trafik ölçüm metodolojisi

Adil bir karşılaştırma için, 1000 URL'lik aynı listeyi kullandım — ortalama karmaşıklıkta ürün kartları, görseller, analitik scriptler ve birkaç üçüncü taraf widget ile (e-ticaret sitesinin tipik yapısı). Trafik ölçümü, sistem ağ izleyicisi ve her araçta yerleşik istek günlüğü araçları aracılığıyla gerçekleştirildi.

Deneyin önemli koşulları:

Tarayıcı önbelleği kapalı — her sayfa "sıfırdan" yüklenir, bu da farklı IP'lerle proxy döndürme ile çalışırken olur
Headless modu tüm tarayıcı testlerinde açık — çoğu üretim scriptinin çalıştığı şekil budur
Temel senaryoda kaynak engellemesi yok — "temiz" tüketimi optimizasyon olmadan göstermek için
Aynı ağ ve aynı sayfa seti, üç araç için de kullanıldı

Bu yaklaşım, kendi durumunuza uygulayabileceğiniz karşılaştırılabilir rakamlar sağlar — projenizdeki sayfa sayısı ile çarparak ve proxy tarifesinin hacmine bölerek.

requests: minimum trafik tüketimi

Python'daki requests kütüphanesi yalnızca HTTP yanıtının gövdesini indirir — açıkça talep ettiğiniz şey. Hiçbir JavaScript, hiçbir görsel, hiçbir CDN'ye ek istek yok. Testimde bir e-ticaret ürün kartının ortalama HTML sayfa boyutu yaklaşık 180-250 KB sıkıştırılmamış HTML'dir.

import requests

proxies = {
    "http": "http://user:pass@proxy_host:port",
    "https": "http://user:pass@proxy_host:port",
}

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}

total_bytes = 0
urls = load_urls_from_file("urls.txt")  # 1000 bağlantı listesi

for url in urls:
    response = requests.get(url, headers=headers, proxies=proxies, timeout=15)
    total_bytes += len(response.content)

print(f"Toplam indirilen: {total_bytes / 1024 / 1024:.2f} MB")

1000 sayfa için toplam tüketim 190-230 MB oldu — yani 0,25 GB'den daha az. Bu en ekonomik seçenek, ancak kritik bir sınırlaması var: Eğer site içeriği JavaScript (React, Vue, dinamik fiyat yüklemesi) ile render ediyorsa, requests gerekli veriler olmadan sayfanın boş iskeletini alır. Statik HTML veya SSR ile siteler için bu, trafik ve sonuç açısından ideal bir seçimdir.

Puppeteer: headless Chrome ne kadar yer kaplıyor

Puppeteer, gerçek Chromium motorunu yönetir, bu nedenle sayfayı tamamen yükler: HTML, CSS, yazı tipleri, görseller, izleme scriptleri, reklam iframe'leri. Headless modda bile tarayıcı, normal bir kullanıcı gibi Chrome'da yapacağı tüm ağ isteklerini gerçekleştirir.

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({
    headless: 'new',
    args: ['--proxy-server=http://proxy_host:port']
  });

  const page = await browser.newPage();
  await page.authenticate({ username: 'user', password: 'pass' });

  let totalBytes = 0;
  page.on('response', async (response) => {
    try {
      const buffer = await response.buffer();
      totalBytes += buffer.length;
    } catch (e) {}
  });

  const urls = require('./urls.json'); // 1000 bağlantı

  for (const url of urls) {
    await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });
  }

  console.log(`Toplam trafik: ${(totalBytes / 1024 / 1024).toFixed(2)} MB`);
  await browser.close();
})();

Testimde Puppeteer ile bir sayfanın ortalama boyutu 2,8-4,5 MB arasında değişti, bu da görsel ve üçüncü taraf script sayısına bağlıdır. 1000 sayfa için bu, 3,1-4,2 GB sonuç verdi — requests'ten 15-18 kat daha fazla. Trafiğin ana kısmını görseller (genellikle sayfa ağırlığının %40-55'i) ve analitik, reklam ve sohbet widget'ları için üçüncü taraf scriptler (yüzde 20-30) alır.

Playwright: farklı tarayıcılardaki trafik

Playwright benzer bir şekilde çalışır, ancak üç motoru destekler — Chromium, Firefox ve WebKit. Trafik tüketimi arasında farklılıklar vardır: WebKit headless modda geleneksel olarak medya içeriğini farklı işleme şekli nedeniyle biraz daha ekonomiktir, Firefox ise bazen istekler arasındaki kaynak önbellekleme farklılıkları nedeniyle daha fazla veri yükleyebilir.

from playwright.sync_api import sync_playwright

total_bytes = 0

def handle_response(response):
    global total_bytes
    try:
        body = response.body()
        total_bytes += len(body)
    except Exception:
        pass

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=True,
        proxy={"server": "http://proxy_host:port", "username": "user", "password": "pass"}
    )
    page = browser.new_page()
    page.on("response", handle_response)

    urls = load_urls_from_file("urls.txt")
    for url in urls:
        page.goto(url, wait_until="networkidle", timeout=30000)

    print(f"Toplam trafik: {total_bytes / 1024 / 1024:.2f} MB");
    browser.close()

Chromium üzerinden Playwright ile sonuç, Puppeteer'a yakın çıktı — 2,9-4,3 GB 1000 sayfa için, bu mantıklıdır çünkü her iki araç da aynı motoru kullanır. WebKit'te tüketim %10-15 daha düşük, yaklaşık 2,6-3,7 GB, Firefox'ta ise biraz daha yüksek, 3,3-4,6 GB olarak ölçüldü. Fark, yazı tiplerinin işlenmesi, görsellerin dekodlanması ve her tarayıcı motorunun ağ yığını davranışındaki farklılıklardan kaynaklanmaktadır.

Karşılaştırma tablosu: 1000 sayfa başına GB

Aşağıda, test edilen tüm seçenekler için özet bir tablo bulunmaktadır, pratik aralıklara yuvarlanmıştır. Rakamlar, görseller ve tipik bir üçüncü taraf script seti ile ortalama bir e-ticaret sayfası için geçerlidir — haber siteleri veya video içeren açılış sayfalarında tüketim daha yüksek olacaktır.

Araç	1000 sayfa başına trafik	JS render'ı	Bot tespitini aşma
requests (Python)	0,19-0,23 GB	Hayır	Zayıf
Playwright (WebKit)	2,6-3,7 GB	Evet	Orta
Puppeteer (Chromium)	3,1-4,2 GB	Evet	Orta
Playwright (Chromium)	2,9-4,3 GB	Evet	İyi
Playwright (Firefox)	3,3-4,6 GB	Evet	Orta

Ana sonuç: Eğer bir site, gerekli verileri elde etmek için JavaScript render'ı gerektirmiyorsa, requests, herhangi bir tarayıcı çözümüne kıyasla trafik tasarrufu sağlar. Ancak içerik dinamik olarak yükleniyorsa veya site tarayıcı davranışını aktif olarak kontrol ediyorsa — tarayıcı render'ı için trafik ödemek zorunda kalacaksınız.

Trafik tüketimini 5-10 kat nasıl azaltabilirsiniz

Tam bir tarayıcıya ihtiyaç duysanız bile, trafik tüketimini önemli ölçüde azaltmak mümkündür, gerekli verileri kaybetmeden. İşte aynı 1000 sayfa setinde test ettiğim etkili yöntemler.

1. Görsellerin, yazı tiplerinin ve medyanın engellenmesi. Görseller genellikle sayfanın ağırlığının yarısından fazlasını oluşturur ve metin verilerini taramak için gerekli değildir.

await page.route('**/*', (route) => {
  const type = route.request().resourceType();
  if (['image', 'font', 'media'].includes(type)) {
    route.abort();
  } else {
    route.continue();
  }
});

Bu yöntem, Playwright ve Puppeteer'de eşit şekilde çalışır ve HTML ve metin verilerini kaybetmeden trafiği %40-60 oranında azaltır.

2. Üçüncü taraf alanların engellenmesi. Reklam ağları, analitik, sohbet widget'ları kendi scriptlerini ve görsellerini yükler, bunlara ihtiyacınız yok. Ana kaynak ve CDN'yi bırakıp, alan adına göre istekleri filtreleyebilirsiniz.

3. "domcontentloaded" yerine "networkidle" kullanımı. Ağın tamamen yüklenmesini beklemek, tarayıcıyı analitik ve tembel yükleme dahil tüm arka plan isteklerini bekletir. Eğer veriler DOM'da daha önce görünüyorsa — daha erken bir olaya geçmek, taramayı hızlandırır ve gereksiz yüklemeleri azaltır.

4. İstekler arasında statik kaynakların önbelleğe alınması. Eğer site tüm sayfalarda aynı CSS/JS dosyalarını kullanıyorsa, tarayıcı önbelleği (test koşullarımızın aksine) büyük bir alan tasarrufu sağlar.

5. Hibrit yaklaşım. Birçok ekip önce requests'i dener, eğer veriler yetersizse — belirli sayfalara Playwright veya Puppeteer ile geçer. Bu, düşük temel trafik tüketimini, gerçekten ihtiyaç duyulan yerlerde render etme imkanı ile birleştirir.

Kaynakların akıllıca engellenmesi durumunda, Puppeteer ve Playwright'in trafik tüketimi 1000 sayfa için 3-4 GB'dan 0,6-1,2 GB'a düşer — bu, requests ile karşılaştırıldığında farkı belirgin şekilde azaltır ve JS render'ı ve anti-bot koruması ile çalışma imkanı sunar.

Trafik miktarına uygun proxy nasıl seçilir

Trafik hesaplaması, proxy türünü seçmeyi doğrudan etkiler. Statik sitelerde requests ile hafif HTTP istekleri için veri merkezi proxy'leri iyi bir seçimdir — hızlıdırlar, trafik açısından ucuzdur ve site davranışsal sinyalleri kontrol etmiyorsa yeterlidirler.

Eğer görev, anti-bot sistemlerini aşmak için Playwright veya Puppeteer ile tam render gerektiriyorsa — örneğin, pazar yerlerinde fiyat toplarken veya arama motoru sonuçlarını izlerken — konut proxy'leri kullanmak daha mantıklıdır. IP itibarına göre daha az engellenirler, bu da her isteğin birkaç megabayt "ağırlığında" olduğu ve engelleme nedeniyle verilerin yeniden alınmasının pahalı olduğu durumlarda kritik öneme sahiptir.

Özellikle IP ve user-agent uyumunu sıkı bir şekilde kontrol eden siteler için (bankacılık hizmetleri, mobil doğrulama gerektiren uygulamalar) mobil proxy'leri değerlendirilmelidir — daha yüksek trafik maliyetine rağmen, IP adresinin güvenilirliğini artırır ve yasaklar nedeniyle tekrar eden isteklerin sayısını minimize eder.

Pratik bir kılavuz: "bir sayfanın ağırlığı × sayfa sayısı × hata ve yasaklar nedeniyle tekrar oranı" formülü ile trafik hacmini hesaplayın ve toplam GB'yi sağlayıcının tarifesi ile karşılaştırın. Yukarıda açıklanan kaynak optimizasyonu genellikle daha ucuz bir proxy türü seçmekten daha fazla tasarruf sağlar — ancak doğru aracın ve doğru proxy'nin kombinasyonu maksimum etkiyi sağlar.

Sonuç

requests, trafik açısından en ekonomik araç olmaya devam ediyor — 1000 sayfa için yaklaşık 0,2 GB, ancak dinamik içerikli siteler için uygun değil. Puppeteer ve Playwright, tam render sağlar ve korumayı aşmada daha iyidir, ancak trafik tüketimi aynı 1000 sayfa için 3-4,5 GB'a kadar yükselir. Görsellerin, yazı tiplerinin ve üçüncü taraf alanların engellenmesi, bu farkı 3-5 kat azaltır ve gerekli verileri korur.

Büyük ölçekli bir tarama başlatmadan önce, seçtiğiniz aracın dikkate alındığı beklenen trafik hacmini hesaplayın ve bunu proxy bütçenize dahil edin. Eğer görev, JavaScript render'ı ve anti-bot sistemlerine karşı dayanıklılık gerektiriyorsa, konut proxy'leri aracılığıyla küçük bir sayfa setinde test koşusu yaparak başlayın — bu, tam veri hacmine geçmeden önce gerçek GB tüketimini doğru bir şekilde değerlendirmeyi sağlar.