Penulis drama vs Pengendali boneka vs permintaan: lalu lintas ke 1000 halaman

Jika Anda membayar untuk trafik proxy per GB, perbedaan antara browser headless dan klien HTTP biasa bisa membuat Anda mengeluarkan uang 15-20 kali lebih banyak pada dataset yang sama dari 1000 halaman. Dalam artikel ini — pengukuran nyata penggunaan trafik untuk Playwright, Puppeteer, dan pustaka Python requests, kode untuk pengujian, dan cara-cara efektif untuk mengurangi volume data tanpa kehilangan konten.

Mengapa penggunaan trafik sangat penting untuk penguraian

Sebagian besar penyedia proxy, termasuk pool residensial dan mobile, mengenakan biaya trafik per GB, bukan berdasarkan jumlah permintaan. Ini berarti bahwa alat yang Anda gunakan untuk mengurai situs secara langsung mempengaruhi anggaran proyek. Browser headless memuat halaman secara keseluruhan: HTML, CSS, JavaScript, gambar, font, skrip analitik, iklan, dan pelacak. Klien HTTP seperti requests hanya mengunduh apa yang Anda minta secara eksplisit — biasanya ini adalah dokumen HTML murni.

Perbedaan ini sangat terlihat pada skala besar. Jika Anda mengurai kartu produk di Wildberries atau Ozon, mengumpulkan harga pesaing, atau memantau hasil Google, volume 1000 halaman adalah norma harian yang umum untuk satu skrip. Ketika bekerja dengan beberapa ratus ribu halaman per bulan, penghematan pada trafik menjadi pos pengeluaran yang signifikan, terutama jika menggunakan proxy residensial, di mana biaya per GB lebih tinggi dibandingkan dengan data center.

Kesulitan tambahan adalah bahwa situs modern secara aktif melindungi diri dari bot: memeriksa rendering JavaScript, perilaku mouse, dan canvas fingerprint. Ini memaksa pengembang untuk beralih dari permintaan HTTP sederhana ke browser penuh seperti Playwright atau Puppeteer, yang "memakan" lebih banyak trafik. Memahami angka yang tepat membantu merencanakan anggaran untuk proxy dan memilih alat yang tepat untuk tugas tertentu.

Metodologi pengukuran trafik

Untuk perbandingan yang adil, saya menggunakan daftar yang sama dari 1000 URL — kartu produk dengan tingkat kesulitan sedang yang memiliki gambar, skrip analitik, dan beberapa widget pihak ketiga (struktur tipikal untuk situs e-commerce). Pengukuran trafik dilakukan melalui pemantauan sistem jaringan dan alat logging permintaan yang terintegrasi di setiap alat.

Syarat penting dari eksperimen:

Cache browser dimatikan — setiap halaman dimuat "dari awal", seperti yang terjadi saat bekerja melalui rotasi proxy dengan IP yang berbeda
Mode headless diaktifkan di semua pengujian browser — ini adalah cara kerja sebagian besar skrip produksi
Tanpa pemblokiran sumber daya dalam skenario dasar — untuk menunjukkan penggunaan "bersih" tanpa optimasi
Jaringan yang sama dan kumpulan halaman yang sama untuk ketiga alat

Pendekatan ini memberikan angka yang dapat dibandingkan yang dapat diterapkan pada kasus Anda sendiri — dengan mengalikan jumlah halaman dalam proyek Anda dan membaginya dengan volume tarif proxy.

requests: penggunaan trafik minimum

Pustaka requests di Python hanya mengunduh tubuh respons HTTP — apa yang Anda minta secara eksplisit. Tidak ada JavaScript, tidak ada gambar, tidak ada permintaan tambahan ke CDN. Rata-rata berat satu halaman HTML kartu e-commerce dalam pengujian saya adalah sekitar 180-250 KB HTML yang tidak terkompresi.

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")  # daftar 1000 tautan

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

print(f"Total diunduh: {total_bytes / 1024 / 1024:.2f} MB")

Pada 1000 halaman, total penggunaan adalah 190-230 MB — yaitu kurang dari 0,25 GB. Ini adalah opsi paling hemat, tetapi memiliki batasan kritis: jika situs merender konten melalui JavaScript (React, Vue, pemuatan harga dinamis), requests akan mendapatkan kerangka kosong halaman tanpa data yang diperlukan. Untuk HTML statis atau situs dengan SSR, ini adalah pilihan ideal dalam hal rasio trafik dan hasil.

Puppeteer: berapa berat headless Chrome

Puppeteer mengendalikan mesin Chromium yang nyata, sehingga memuat halaman secara penuh: HTML, CSS, font, gambar, skrip pelacakan, iframe iklan. Bahkan dalam mode headless, browser melakukan semua permintaan jaringan yang akan dilakukan oleh pengguna biasa di Chrome.

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 tautan

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

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

Dalam pengujian saya, rata-rata berat satu halaman melalui Puppeteer adalah 2,8-4,5 MB, tergantung pada jumlah gambar dan skrip pihak ketiga. Pada 1000 halaman, ini menghasilkan 3,1-4,2 GB — 15-18 kali lebih banyak daripada requests. Sebagian besar trafik diambil oleh gambar (biasanya 40-55% dari berat halaman) dan skrip analitik, iklan, dan widget chat pihak ketiga (20-30%).

Playwright: trafik di berbagai browser

Playwright bekerja dengan cara yang mirip, tetapi mendukung tiga mesin — Chromium, Firefox, dan WebKit. Penggunaan trafik di antara mereka berbeda: WebKit dalam mode headless biasanya sedikit lebih hemat karena pemrosesan media yang berbeda, sementara Firefox kadang-kadang memuat lebih banyak data karena perbedaan dalam caching sumber daya antara permintaan.

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"Total trafik: {total_bytes / 1024 / 1024:.2f} MB")
    browser.close()

Pada Chromium melalui Playwright, hasilnya mendekati Puppeteer — 2,9-4,3 GB untuk 1000 halaman, yang masuk akal, karena kedua alat menggunakan mesin yang sama. Pada WebKit, penggunaan adalah 10-15% lebih rendah, sekitar 2,6-3,7 GB, sedangkan pada Firefox sedikit lebih tinggi, 3,3-4,6 GB. Perbedaan ini dijelaskan oleh perbedaan dalam pemrosesan font, dekode gambar, dan perilaku stack jaringan dari setiap mesin browser.

Tabel perbandingan: GB untuk 1000 halaman

Di bawah ini adalah tabel ringkasan untuk semua opsi yang diuji, dibulatkan ke rentang praktis. Angka-angka ini relevan untuk halaman e-commerce rata-rata dengan gambar dan kumpulan skrip pihak ketiga yang tipikal — di situs berita atau landing page dengan video, penggunaan akan lebih tinggi.

Alat	Trafik untuk 1000 halaman	JS-rendering	Menghindari deteksi bot
requests (Python)	0,19-0,23 GB	Tidak	Lemah
Playwright (WebKit)	2,6-3,7 GB	Ya	Sedang
Puppeteer (Chromium)	3,1-4,2 GB	Ya	Sedang
Playwright (Chromium)	2,9-4,3 GB	Ya	Baik
Playwright (Firefox)	3,3-4,6 GB	Ya	Sedang

Kesimpulan kunci: jika situs tidak memerlukan rendering JavaScript untuk mendapatkan data yang diperlukan, requests menghemat trafik 15-20 kali dibandingkan dengan solusi berbasis browser mana pun. Namun, jika konten dimuat secara dinamis atau situs secara aktif memeriksa perilaku browser — Anda harus membayar untuk trafik rendering browser.

Bagaimana mengurangi penggunaan trafik 5-10 kali lipat

Bahkan jika Anda memerlukan browser penuh, penggunaan trafik dapat dikurangi secara radikal tanpa kehilangan data yang diperlukan. Berikut adalah teknik-teknik yang telah saya uji pada kumpulan yang sama dari 1000 halaman.

1. Pemblokiran gambar, font, dan media. Gambar biasanya menyusun lebih dari setengah berat halaman, dan untuk mengurai data teks, mereka tidak diperlukan.

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

Teknik ini bekerja sama di Playwright dan Puppeteer dan mengurangi trafik sebesar 40-60% tanpa kehilangan HTML dan data teks.

2. Pemblokiran domain pihak ketiga. Jaringan iklan, analitik, dan widget chat memuat skrip dan gambar mereka sendiri yang tidak Anda butuhkan. Anda dapat memfilter permintaan berdasarkan domain, hanya menyisakan sumber daya utama dan CDN-nya.

3. Menggunakan "domcontentloaded" alih-alih "networkidle". Menunggu pemuatan jaringan penuh membuat browser menunggu semua permintaan latar belakang, termasuk analitik dan pemuatan malas. Jika data muncul di DOM lebih awal — beralih ke peristiwa yang lebih awal mempercepat penguraian dan mengurangi pemuatan tambahan yang tidak perlu.

4. Meng-cache sumber daya statis di antara permintaan. Jika situs menggunakan file CSS/JS yang sama di semua halaman, cache browser yang diaktifkan (berbeda dari kondisi pengujian kami) menghemat volume yang signifikan saat menjelajahi banyak URL dari satu domain secara berurutan.

5. Pendekatan hibrida. Banyak tim terlebih dahulu mencoba requests, dan hanya jika data tidak mencukupi — beralih ke halaman tertentu melalui Playwright atau Puppeteer. Ini menggabungkan pengeluaran trafik dasar yang rendah dengan kemampuan rendering di tempat yang benar-benar diperlukan.

Dengan pemblokiran sumber daya yang tepat, penggunaan trafik Puppeteer dan Playwright dapat turun dari 3-4 GB menjadi 0,6-1,2 GB untuk 1000 halaman — perbedaan ini menjadi jauh lebih kecil dibandingkan dengan requests, sambil tetap mempertahankan kemampuan untuk bekerja dengan rendering JS dan perlindungan anti-bot.

Bagaimana memilih proxy berdasarkan volume trafik

Perhitungan trafik secara langsung mempengaruhi pilihan jenis proxy. Untuk permintaan HTTP ringan melalui requests di situs statis, proxy data center sangat cocok — mereka cepat, murah dalam penggunaan trafik, dan cukup jika situs tidak memeriksa sinyal perilaku.

Jika tugas memerlukan rendering penuh melalui Playwright atau Puppeteer untuk menghindari sistem anti-bot — misalnya, saat mengumpulkan harga di marketplace atau memantau hasil pencarian — lebih bijaksana untuk menggunakan proxy residensial. Mereka jarang diblokir berdasarkan reputasi IP, yang krusial ketika setiap permintaan "berat" beberapa megabyte dan pengambilan data ulang karena pemblokiran menjadi mahal.

Untuk skenario di mana situs secara ketat memeriksa kesesuaian IP dan user-agent (layanan perbankan, aplikasi dengan verifikasi mobile), pertimbangkan proxy mobile — meskipun biaya trafiknya lebih tinggi, mereka memberikan kepercayaan maksimum pada alamat IP dan meminimalkan jumlah permintaan ulang karena pemblokiran.

Panduan praktis: hitung volume trafik menggunakan rumus "berat satu halaman × jumlah halaman × koefisien pengulangan karena kesalahan dan pemblokiran" dan bandingkan total GB dengan tarif penyedia. Optimasi sumber daya yang dijelaskan di atas biasanya memberikan lebih banyak penghematan daripada memilih jenis proxy yang lebih murah — tetapi kombinasi alat yang tepat dan proxy yang tepat memberikan efek maksimum.

Kesimpulan

requests tetap menjadi alat paling hemat dalam penggunaan trafik — sekitar 0,2 GB untuk 1000 halaman, tetapi tidak cocok untuk situs dengan konten dinamis. Puppeteer dan Playwright memberikan rendering penuh dan penghindaran perlindungan yang lebih baik, tetapi penggunaan trafik meningkat menjadi 3-4,5 GB untuk 1000 halaman yang sama. Pemblokiran gambar, font, dan domain pihak ketiga mengurangi kesenjangan ini 3-5 kali lipat, sambil mempertahankan data yang diperlukan.

Sebelum memulai penguraian besar-besaran, hitung volume trafik yang diharapkan dengan mempertimbangkan alat yang dipilih dan masukkan ke dalam anggaran untuk proxy. Jika tugas memerlukan rendering JavaScript dan ketahanan terhadap sistem anti-bot, mulailah dengan pengujian pada kumpulan halaman kecil melalui proxy residensial — ini akan memungkinkan Anda untuk menilai dengan tepat penggunaan GB yang sebenarnya sebelum meluncurkan pada volume data penuh.