कैसे डेटा खोए बिना पार्सर के ट्रैफ़िक को 5 गुना कम करें

हर अतिरिक्त मेगाबाइट पार्सर ट्रैफ़िक का मतलब है या तो प्रॉक्सी प्रदाता को भुगतान, या सीमाओं के तहत आने और IP पर बैन लगने का जोखिम। यदि आप Wildberries, Ozon से कीमतें एकत्र कर रहे हैं या सैकड़ों प्रॉक्सी पते के माध्यम से Avito पर विज्ञापनों की निगरानी कर रहे हैं, तो ट्रैफ़िक की बचत सीधे प्रोजेक्ट के बजट पर प्रभाव डालती है। इस लेख में — विशिष्ट तकनीकी तरीके जो डेटा के संचारित मात्रा को 4-5 गुना कम करने की अनुमति देते हैं, जबकि निकाली गई जानकारी की पूर्णता और सटीकता को बनाए रखते हैं।

क्यों पार्सर ट्रैफ़िक बजट पर असर डालता है

अधिकांश प्रॉक्सी प्रदाता निवासी और मोबाइल प्रॉक्सी को भेजे गए गीगाबाइट के मात्रा के अनुसार चार्ज करते हैं, न कि उपयोग के समय के अनुसार। यदि आपका पार्सर Wildberries के उत्पाद पृष्ठ को पूरी तरह से लोड करता है — चित्रों, सिफारिश स्क्रिप्टों, एनालिटिक्स ट्रैकर्स और फ़ॉन्ट्स के साथ — तो आप प्रति कार्ड 2-3 MB के लिए भुगतान करते हैं, जबकि वास्तव में आपको 15-20 KB के टेक्स्ट की आवश्यकता होती है: नाम, कीमत, रेटिंग, उपलब्धता।

50,000-100,000 कार्डों के दैनिक स्केलिंग पर "सब कुछ लोड करना" और "केवल आवश्यक लोड करना" के बीच का अंतर प्रतिदिन दर्जनों गीगाबाइट अतिरिक्त ट्रैफ़िक में बदल जाता है। यह न केवल प्रॉक्सी पर खर्च है, बल्कि लक्षित साइट पर बढ़ी हुई लोडिंग भी है, जो एंटी-बॉट सुरक्षा के तहत आने और कैप्चा या अस्थायी IP बैन प्राप्त करने की संभावना को बढ़ाती है। ट्रैफ़िक का अनुकूलन पैसे की बचत और ब्लॉक होने के जोखिम को कम करने का एक साथ काम करता है।

एक तीसरा प्रभाव भी है: जितना कम डेटा एक अनुरोध में भेजा जाता है, उतना ही तेजी से अनुरोध पूरा होता है। यह समान प्रॉक्सी पर अधिक धारा शुरू करने की अनुमति देता है बिना एंटी-डिटेक्ट ब्राउज़रों जैसे Dolphin Anty या AdsPower द्वारा निर्धारित गति सीमाओं को पार किए बिना।

तरीका 1: चित्रों, CSS और फ़ॉन्ट्स को ब्लॉक करना

यदि पार्सर हेडलेस ब्राउज़र (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 निष्पादन की आवश्यकता नहीं है (यह आसानी से "पृष्ठ कोड देखें" खोलकर जांचा जा सकता है), तो HTML को सीधे requests या httpx जैसी लाइब्रेरी के माध्यम से लेना अधिक लाभदायक है। ऐसा अनुरोध किलोबाइट में होता है, मेगाबाइट में नहीं, क्योंकि यह ब्राउज़र के रेंडरिंग इंजन, ट्रैकर्स के लिए नेटवर्क कॉल और द्वितीयक संसाधनों को अपने साथ नहीं खींचता है।

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 और Yandex.Market शामिल हैं — उत्पाद कार्ड और सूचियों को आंतरिक JSON API के माध्यम से रेंडर करते हैं, जिसे फ्रंटएंड द्वारा कॉल किया जाता है। इन एंडपॉइंट्स को DevTools में Network टैब के माध्यम से XHR/Fetch प्रकार के अनुरोधों को फ़िल्टर करके पाया जा सकता है। आमतौर पर, एक ऐसा अनुरोध 5-30 KB का JSON देता है जिसमें साफ डेटा होता है: उत्पाद का 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 औसतन Gzip की तुलना में टेक्स्ट HTML को 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 को सामान्य करना (ट्रैकिंग पैरामीटर को हटाना, क्वेरी पैरामीटर को क्रमबद्ध करना) बड़े निर्देशिकाओं के क्रॉल के दौरान 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 को ब्लॉक करने की सेटिंग करें
DevTools → Network → XHR/Fetch के माध्यम से आंतरिक JSON API खोजें
सभी अनुरोधों में Accept-Encoding: gzip, br हेडर जोड़ें
दोहराए जाने वाले URL पर शर्तीय अनुरोधों के लिए ETag/Last-Modified को स्टोर करने का कार्यान्वयन करें
क्रॉलिंग से पहले URL की कतार को सामान्य और डुप्लिकेट करें
डेटा की महत्वपूर्णता और अस्थिरता के आधार पर अनुकूलित क्रॉलिंग आवृत्ति सेट करें
अंतिम ट्रैफ़िक प्रोफ़ाइल के अनुसार प्रॉक्सी प्रकार का चयन करें — डेटा सेंटर, निवासी या मोबाइल

निष्कर्ष

पार्सर ट्रैफ़िक को 5 गुना कम करना एक यथार्थवादी लक्ष्य है, यदि तरीकों को क्रमबद्ध तरीके से लागू किया जाए: अनावश्यक संसाधनों को हटाना, जहाँ संभव हो सीधे HTTP अनुरोधों या JSON API पर जाना, संकुचन को सक्षम करना, अपरिवर्तित डेटा के लिए शर्तीय अनुरोधों का उपयोग करना और क्रॉलिंग पैटर्न का अनुकूलन करना। इनमें से प्रत्येक कदम एक मापनीय प्रभाव देता है, और एक साथ वे मार्केटप्लेस और अन्य साइटों से डेटा संग्रह के प्रोजेक्ट की अर्थव्यवस्था को मौलिक रूप से बदल देते हैं।

ट्रैफ़िक के अनुकूलन के बाद, नए लोड प्रोफ़ाइल के लिए प्रॉक्सी बुनियादी ढांचे का सही चयन करना महत्वपूर्ण है। बड़े डेटा मात्रा के त्वरित और सस्ते संग्रह के लिए डेटा सेंटर प्रॉक्सी उपयुक्त हैं, जबकि कड़े एंटी-बॉट सुरक्षा वाले साइटों के लिए — निवासी प्रॉक्सी जो वास्तविक घरेलू प्रदाताओं के IP के साथ होते हैं, जो तीव्र पार्सिंग के दौरान भी ब्लॉक होने के जोखिम को कम करते हैं।