Cara Mengurangi Lalu Lintas Parser Hingga 5 Kali Tanpa Kehilangan Data: 7 Teknik untuk Data Engineer

Setiap megabyte lalu lintas parser yang tidak perlu — baik itu pembayaran kepada penyedia proxy, atau risiko terkena batasan dan mendapatkan pemblokiran IP. Jika Anda mengumpulkan harga dari Wildberries, Ozon, atau memantau iklan di Avito melalui ratusan alamat proxy, penghematan lalu lintas secara langsung mempengaruhi anggaran proyek. Dalam artikel ini — teknik teknis konkret yang memungkinkan untuk mengurangi volume data yang ditransfer hingga 4-5 kali, sambil mempertahankan kelengkapan dan akurasi informasi yang diekstrak.

Mengapa Lalu Lintas Parser Memengaruhi Anggaran

Sebagian besar penyedia proxy mengenakan biaya untuk proxy residensial dan seluler berdasarkan volume gigabyte yang ditransfer, bukan berdasarkan waktu penggunaan. Jika parser Anda memuat halaman produk Wildberries secara keseluruhan — dengan gambar, skrip rekomendasi, pelacak analitik, dan font — Anda membayar 2-3 MB untuk satu kartu, padahal yang sebenarnya dibutuhkan hanya 15-20 KB teks: nama, harga, peringkat, ketersediaan.

Saat skala meningkat hingga 50.000-100.000 kartu per hari, perbedaan antara "memuat semuanya" dan "memuat hanya yang diperlukan" berubah menjadi puluhan gigabyte lalu lintas yang tidak perlu setiap hari. Ini bukan hanya biaya untuk proxy, tetapi juga beban yang meningkat pada situs target, yang meningkatkan kemungkinan terkena perlindungan anti-bot dan mendapatkan captcha atau pemblokiran IP sementara. Optimasi lalu lintas adalah penghematan uang sekaligus mengurangi risiko pemblokiran.

Ada juga efek ketiga: semakin sedikit data yang ditransfer dalam satu permintaan, semakin cepat permintaan itu sendiri dieksekusi. Ini memungkinkan peningkatan paralelisme — menjalankan lebih banyak aliran pada jumlah proxy yang sama tanpa melebihi batas kecepatan yang ditetapkan oleh browser anti-detect seperti Dolphin Anty atau AdsPower saat bekerja dengan sesi.

Teknik 1: Pemblokiran Gambar, CSS, dan Font

Jika parser bekerja melalui browser headless (Playwright, Puppeteer, Selenium) — cara tercepat untuk mengurangi lalu lintas 2-3 kali adalah dengan memblokir pemuatan sumber daya statis yang tidak memengaruhi data di DOM. Gambar produk, font situs web, video, dan gaya CSS menyita hingga 70% berat halaman, tetapi tidak berpartisipasi dalam ekstraksi teks dan atribut.

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()

Logika serupa diimplementasikan di Puppeteer melalui page.setRequestInterception(true) dan di Selenium melalui pengaturan profil Chrome dengan parameter profile.managed_default_content_settings.images: 2. Dalam praktiknya, pengaturan ini langsung memotong 50% hingga 70% lalu lintas saat parsing marketplace, di mana halaman dibanjiri dengan konten visual dan iklan banner.

Teknik 2: Permintaan HTTP Alih-alih Browser Penuh

Banyak yang menggunakan Selenium atau Playwright di tempat yang tidak perlu. Jika halaman tidak memerlukan eksekusi JavaScript untuk merender data (ini mudah diperiksa dengan membuka "Lihat Kode Halaman" alih-alih DevTools), jauh lebih menguntungkan untuk mengambil HTML langsung melalui pustaka requests atau httpx di Python. Permintaan semacam itu hanya berat kilobyte, bukan megabyte, karena tidak melibatkan rendering mesin browser, panggilan jaringan untuk pelacak, dan sumber daya sekunder.

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), "byte diterima")

Beralih dari emulasi browser ke permintaan HTTP langsung di mana situs memberikan HTML siap tanpa rendering klien, mengurangi lalu lintas 3-8 kali. Satu-satunya nuansa — permintaan semacam itu lebih mudah dibedakan dari pengguna nyata, jadi untuk situs dengan perlindungan anti-bot yang ketat, sebaiknya kombinasikan metode ini dengan proxy residensial berkualitas, yang memberikan IP dari penyedia rumah yang nyata dan mengurangi kemungkinan pemblokiran permintaan.

Teknik 3: Parsing Melalui API JSON Tersembunyi

Hampir semua marketplace modern — termasuk Wildberries, Ozon, dan Yandex.Market — merender kartu produk dan daftar melalui API JSON internal yang dipanggil oleh frontend. Anda dapat menemukan endpoint ini melalui tab Jaringan di DevTools, dengan memfilter permintaan berdasarkan jenis XHR/Fetch. Biasanya, satu permintaan semacam itu memberikan JSON sebesar 5-30 KB dengan data bersih: id produk, harga, diskon, stok, peringkat — tanpa satu byte pun markup HTML atau CSS.

Perbedaan dalam volume data yang ditransfer antara halaman HTML lengkap dan akses langsung ke API JSON dapat mencapai 10-15 kali. Keuntungan tambahan — JSON lebih mudah diparsing secara programatik: tidak perlu pemilih XPath, cukup akses ke bidang yang diperlukan berdasarkan kunci kamus. Kekurangan — endpoint semacam itu sering kali memerlukan header spesifik, token sesi, atau parameter tanda tangan permintaan, yang perlu diekstrak sebelumnya dari halaman utama atau aplikasi seluler.

Teknik 4: Kompresi Gzip dan Brotli

Bahkan jika Anda terpaksa mengambil HTML lengkap, mengaktifkan kompresi yang tepat dapat mengurangi ukuran transfer sebesar 60-80%. Banyak parser buatan sendiri tidak mengirimkan header Accept-Encoding: gzip, br, yang menyebabkan server memberikan respons yang tidak terkompresi. Pustaka requests dan httpx secara otomatis mengekstrak Gzip dan Brotli — yang penting adalah secara eksplisit menyatakan dukungan kompresi dalam header permintaan.

Brotli rata-rata mengompresi HTML teks lebih kuat daripada Gzip, sekitar 15-20%, tetapi tidak semua server mendukung algoritma ini — sebaiknya minta kedua opsi dan biarkan server memilih yang optimal. Untuk API JSON, efek dari kompresi bahkan lebih terlihat: kunci kamus yang berulang ("price", "name", "rating") terkompresi hampir sempurna, mengurangi berat respons secara signifikan.

Teknik 5: Permintaan Bersyarat dan Caching

Jika Anda memantau harga pada produk yang sama beberapa kali sehari, sebagian besar kartu tidak berubah di antara pemeriksaan. Gunakan header If-Modified-Since dan If-None-Match dengan nilai ETag yang diperoleh pada permintaan pertama. Jika konten tidak berubah, server memberikan status 304 Not Modified hampir tanpa badan respons — penghematan lalu lintas dapat mencapai 95% pada halaman yang tidak berubah.

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  # data tidak berubah
    etag_store[url] = resp.headers.get("ETag", "")
    return resp.content

Tidak semua situs mendukung ETag dengan benar, tetapi untuk yang mendukung, teknik ini menjadi cara paling efektif untuk mengurangi lalu lintas saat pemantauan rutin — Anda sebenarnya hanya membayar untuk perubahan data yang nyata, bukan untuk memuat ulang konten yang tidak berubah.

Teknik 6: Parsing Selektif Bidang yang Diperlukan

Terkadang mengurangi lalu lintas masuk dari sisi server tidak mungkin — situs memberikan halaman lengkap terlepas dari permintaan. Dalam hal ini, optimasi terjadi pada tahap pemrosesan: jangan memuat halaman lagi hanya untuk mengekstrak satu bidang lagi. Rancang XPath atau pemilih CSS sehingga dalam satu lintasan DOM dapat mengekstrak semua atribut yang diperlukan — harga, nama, artikel, ketersediaan, peringkat — alih-alih melakukan permintaan berulang ke URL yang sama dengan parser yang berbeda untuk tugas yang berbeda.

Juga berguna untuk membatasi kedalaman crawling halaman yang bersarang. Jika untuk memantau harga sudah cukup dengan data dari halaman kategori (daftar produk), jangan masuk ke kartu setiap produk secara terpisah — ini adalah lalu lintas duplikat yang sering kali tidak memberikan informasi baru, kecuali deskripsi dan ulasan, yang tidak memengaruhi harga dan ketersediaan.

Teknik 7: Optimasi Pola Crawling

Deduplication URL — teknik dasar, tetapi sering diabaikan. Katalog marketplace menghasilkan banyak tautan dengan konten yang sama, tetapi dengan parameter pengurutan, label UTM, atau ID sesi yang berbeda. Normalisasi URL sebelum dimasukkan dalam antrean (menghapus parameter pelacakan, mengurutkan parameter query) menghilangkan 10-30% permintaan berlebih saat menjelajahi katalog besar.

Memprioritaskan crawling berdasarkan frekuensi perubahan data juga menghemat lalu lintas: produk dengan permintaan tinggi dan harga yang fluktuatif sebaiknya diperiksa setiap jam, sedangkan posisi langka — sekali sehari. Jadwal adaptif semacam ini, alih-alih menjelajahi semua kartu dengan frekuensi yang sama, mengurangi total volume permintaan 2-4 kali tanpa kehilangan relevansi data kritis.

Bagaimana Ini Sesuai dengan Strategi Proxy

Mengurangi lalu lintas secara langsung memengaruhi pilihan jenis proxy. Jika Anda parsing volume halaman besar dari permintaan HTTP langsung tanpa perlindungan anti-bot yang rumit, cukup gunakan proxy data center yang cepat dan murah — mereka memberikan kecepatan transfer tinggi dengan biaya rendah per gigabyte, yang sangat penting saat parsing besar ribuan kartu setiap hari.

Untuk situs dengan perlindungan ketat terhadap bot, di mana penting untuk meniru perilaku pengguna nyata, lebih baik menggunakan proxy residensial — dengan menggabungkannya dengan teknik pemblokiran sumber daya yang tidak perlu, Anda mendapatkan lalu lintas rendah dan tingkat kepercayaan tinggi dari situs terhadap permintaan. Dan jika parsing dilakukan melalui versi seluler API marketplace, di mana data lebih kompak dan sistem anti-bot berfokus pada rentang IP seluler, sebaiknya pertimbangkan proxy seluler untuk mengurangi risiko pemblokiran lebih lanjut.

Kombinasi "lalu lintas minimal per permintaan" + "jenis proxy yang tepat untuk tugas" memungkinkan untuk mengurangi biaya infrastruktur dan meningkatkan kecepatan pengumpulan data tanpa kehilangan keandalan.

Tabel Perbandingan Teknik

Teknik	Pengurangan Lalu Lintas	Tingkat Kesulitan Implementasi
Pemblokiran Gambar/CSS/Font	50-70%	Rendah
Permintaan HTTP Alih-alih Browser	3-8 kali	Sedang
API JSON Tersembunyi	10-15 kali	Tinggi
Kompresi Gzip/Brotli	60-80%	Rendah
Permintaan Bersyarat (ETag)	hingga 95% pada halaman yang tidak berubah	Sedang
Deduplication URL dan Prioritas	2-4 kali	Sedang

Daftar Periksa Implementasi

• Periksa apakah halaman target memerlukan rendering JavaScript, atau dapat mengambil HTML langsung melalui httpx/requests
• Atur pemblokiran image/media/font/stylesheet di browser headless, jika browser tetap diperlukan
• Temukan API JSON internal melalui DevTools → Jaringan → XHR/Fetch
• Tambahkan header Accept-Encoding: gzip, br ke semua permintaan
• Implementasikan penyimpanan ETag/Last-Modified untuk permintaan bersyarat pada URL yang berulang
• Normalisasi dan deduplikasi antrean URL sebelum crawling
• Atur frekuensi crawling adaptif berdasarkan pentingnya dan volatilitas data
• Pilih jenis proxy sesuai dengan profil lalu lintas akhir — data center, residensial, atau seluler

Kesimpulan

Mengurangi lalu lintas parser hingga 5 kali lipat adalah tujuan yang realistis jika menerapkan teknik secara berurutan: menghapus sumber daya yang tidak perlu, beralih ke permintaan HTTP langsung atau API JSON di mana pun memungkinkan, mengaktifkan kompresi, menggunakan permintaan bersyarat untuk data yang tidak berubah, dan mengoptimalkan pola crawling itu sendiri. Setiap langkah ini memberikan efek yang terukur, dan secara keseluruhan mereka secara radikal mengubah ekonomi proyek pengumpulan data dari marketplace dan situs lainnya.

Setelah mengoptimalkan lalu lintas, penting untuk memilih infrastruktur proxy yang tepat untuk profil beban baru. Untuk pengumpulan data besar yang cepat dan murah, proxy data center cocok, sedangkan untuk bekerja dengan situs dengan perlindungan anti-bot yang ketat — proxy residensial dengan alamat IP nyata dari penyedia rumah, yang mengurangi risiko pemblokiran bahkan saat parsing intensif.