यदि आप GB के हिसाब से प्रॉक्सी ट्रैफ़िक के लिए भुगतान कर रहे हैं, तो headless ब्राउज़र और सामान्य HTTP क्लाइंट के बीच का अंतर आपको 1000 पृष्ठों के एक ही डेटासेट पर 15-20 गुना अधिक खर्च कर सकता है। इस लेख में - Playwright, Puppeteer और Python लाइब्रेरी requests के लिए ट्रैफ़िक खपत के वास्तविक माप, परीक्षण के लिए कोड और डेटा की मात्रा को बिना सामग्री खोए कम करने के कार्यशील तरीके शामिल हैं।
क्यों ट्रैफ़िक की खपत पार्सिंग के लिए महत्वपूर्ण है
अधिकांश प्रॉक्सी प्रदाता, जिसमें आवासीय और मोबाइल पूल शामिल हैं, ट्रैफ़िक को GB के हिसाब से चार्ज करते हैं, न कि अनुरोधों की संख्या के अनुसार। इसका मतलब है कि जिस उपकरण का आप वेबसाइट को पार्स करने के लिए उपयोग करते हैं, वह प्रोजेक्ट के बजट पर सीधे प्रभाव डालता है। Headless ब्राउज़र पूरी पृष्ठ को लोड करता है: HTML, CSS, JavaScript, छवियाँ, फ़ॉन्ट, विश्लेषणात्मक स्क्रिप्ट, विज्ञापन बैनर और ट्रैकर्स। HTTP क्लाइंट जैसे requests केवल वही डाउनलोड करता है जो आपने स्पष्ट रूप से अनुरोध किया है - आमतौर पर यह एक शुद्ध HTML दस्तावेज़ होता है।
अंतर विशेष रूप से पैमाने पर स्पष्ट है। यदि आप Wildberries या Ozon पर उत्पाद कार्ड पार्स कर रहे हैं, प्रतिस्पर्धियों की कीमतें इकट्ठा कर रहे हैं या Google के परिणामों की निगरानी कर रहे हैं, तो 1000 पृष्ठों की मात्रा एक स्क्रिप्ट के लिए एक सामान्य दैनिक मानक है। यदि आप प्रति माह कई सौ हजार पृष्ठों के साथ काम कर रहे हैं, तो ट्रैफ़िक पर बचत एक महत्वपूर्ण खर्च बन जाती है, विशेष रूप से यदि आवासीय प्रॉक्सी का उपयोग किया जा रहा है, जहाँ GB की लागत डेटा सेंटर की तुलना में अधिक होती है।
अतिरिक्त जटिलता यह है कि आधुनिक वेबसाइटें सक्रिय रूप से बॉट्स से सुरक्षा करती हैं: JavaScript का रेंडरिंग, माउस का व्यवहार, कैनवास फिंगरप्रिंट की जांच करती हैं। यह डेवलपर्स को सरल HTTP अनुरोधों से Playwright या Puppeteer जैसे पूर्ण ब्राउज़रों पर जाने के लिए मजबूर करता है, जो ट्रैफ़िक में बहुत अधिक "वजन" रखते हैं। सटीक आंकड़ों को समझना प्रॉक्सी पर बजट की पूर्व गणना करने में मदद करता है और विशिष्ट कार्य के लिए सही उपकरण चुनने में मदद करता है।
ट्रैफ़िक मापने की विधि
निष्पक्ष तुलना के लिए, मैंने 1000 URL की एक ही सूची का उपयोग किया - औसत जटिलता के उत्पाद कार्ड जिनमें छवियाँ, विश्लेषणात्मक स्क्रिप्ट और कुछ तृतीय-पक्ष विजेट शामिल हैं (e-commerce वेबसाइट के लिए सामान्य संरचना)। ट्रैफ़िक मापने का कार्य प्रणाली के नेटवर्क मॉनिटर और प्रत्येक उपकरण में अनुरोधों के लॉगिंग के अंतर्निहित साधनों के माध्यम से किया गया।
प्रयोग की महत्वपूर्ण शर्तें:
- ब्राउज़र कैश बंद है - प्रत्येक पृष्ठ "शून्य" से लोड होता है, जैसा कि विभिन्न IP के साथ प्रॉक्सी रोटेशन के माध्यम से काम करते समय होता है
- सभी ब्राउज़र परीक्षणों में headless मोड सक्षम है - अधिकांश उत्पादन स्क्रिप्ट इस तरह काम करती हैं
- बुनियादी परिदृश्य में संसाधनों को अवरुद्ध नहीं किया गया है - अनुकूलन के बिना "शुद्ध" खपत दिखाने के लिए
- सभी तीन उपकरणों के लिए एक ही नेटवर्क और एक ही पृष्ठों का सेट
इस दृष्टिकोण से तुलनीय आंकड़े मिलते हैं, जिन्हें आप अपने स्वयं के मामले पर लागू कर सकते हैं - अपने प्रोजेक्ट में पृष्ठों की संख्या से गुणा करके और प्रॉक्सी के टैरिफ की मात्रा से विभाजित करके।
requests: न्यूनतम ट्रैफ़िक खपत
Python में requests लाइब्रेरी केवल HTTP प्रतिक्रिया का शरीर डाउनलोड करती है - जो आपने स्पष्ट रूप से अनुरोध किया है। कोई JavaScript नहीं, कोई छवियाँ नहीं, कोई अतिरिक्त CDN अनुरोध नहीं। मेरे परीक्षण में e-commerce कार्ड के एक HTML पृष्ठ का औसत वजन लगभग 180-250 KB बिना संकुचन के था।
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 लिंक की सूची
for url in urls:
response = requests.get(url, headers=headers, proxies=proxies, timeout=15)
total_bytes += len(response.content)
print(f"कुल डाउनलोड किया गया: {total_bytes / 1024 / 1024:.2f} MB")
1000 पृष्ठों पर कुल खपत 190-230 MB थी - यानी 0.25 GB से कम। यह सबसे किफायती विकल्प है, लेकिन इसका एक महत्वपूर्ण सीमितता है: यदि वेबसाइट JavaScript के माध्यम से सामग्री को रेंडर करती है (React, Vue, गतिशील मूल्य लोडिंग), तो requests आवश्यक डेटा के बिना पृष्ठ का खाली ढांचा प्राप्त करेगा। स्थिर HTML या SSR वाले साइटों के लिए यह ट्रैफ़िक और परिणाम के अनुपात में आदर्श विकल्प है।
Puppeteer: headless Chrome का वजन कितना है
Puppeteer वास्तविक Chromium इंजन को नियंत्रित करता है, इसलिए यह पूरी पृष्ठ को लोड करता है: HTML, CSS, फ़ॉन्ट, छवियाँ, ट्रैकिंग स्क्रिप्ट, विज्ञापन iframe। यहां तक कि headless मोड में, ब्राउज़र सभी नेटवर्क अनुरोध करता है जो एक सामान्य उपयोगकर्ता 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 लिंक
for (const url of urls) {
await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });
}
console.log(`कुल ट्रैफ़िक: ${(totalBytes / 1024 / 1024).toFixed(2)} MB`);
await browser.close();
})();
मेरे परीक्षण में Puppeteer के माध्यम से एक पृष्ठ का औसत वजन 2.8-4.5 MB था, जो छवियों और तृतीय-पक्ष स्क्रिप्टों की संख्या पर निर्भर करता है। 1000 पृष्ठों पर, इसने 3.1-4.2 GB का परिणाम दिया - जो requests की तुलना में 15-18 गुना अधिक है। ट्रैफ़िक का मुख्य हिस्सा छवियों द्वारा लिया जाता है (आमतौर पर पृष्ठ के वजन का 40-55%) और तृतीय-पक्ष विश्लेषण, विज्ञापन और चैट विजेट स्क्रिप्ट (20-30%) द्वारा।
Playwright: विभिन्न ब्राउज़रों में ट्रैफ़िक
Playwright इसी तरह काम करता है, लेकिन तीन इंजन - Chromium, Firefox और WebKit का समर्थन करता है। उनके बीच ट्रैफ़िक की खपत भिन्न होती है: headless मोड में WebKit पारंपरिक रूप से मीडिया सामग्री के अलग तरीके से संसाधित करने के कारण थोड़ा अधिक किफायती होता है, जबकि Firefox कभी-कभी अनुरोधों के बीच संसाधनों के कैशिंग में भिन्नताओं के कारण अधिक डेटा लोड करता है।
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_bytes / 1024 / 1024:.2f} MB")
browser.close()
Chromium के माध्यम से Playwright के परिणाम Puppeteer के करीब थे - 2.9-4.3 GB 1000 पृष्ठों पर, जो तार्किक है, क्योंकि दोनों उपकरण एक ही इंजन का उपयोग करते हैं। WebKit पर खपत 10-15% कम थी, लगभग 2.6-3.7 GB, और Firefox पर थोड़ा अधिक, 3.3-4.6 GB। यह अंतर फ़ॉन्ट्स के संसाधन, छवियों के डिकोडिंग और प्रत्येक ब्राउज़र इंजन के नेटवर्क स्टैक के व्यवहार में भिन्नताओं के कारण है।
तुलनात्मक तालिका: 1000 पृष्ठों पर GB
नीचे सभी परीक्षण किए गए विकल्पों के लिए एक सारणी है, व्यावहारिक रेंज में गोलाई के साथ। ये आंकड़े औसत e-commerce पृष्ठ के लिए प्रासंगिक हैं जिनमें छवियाँ और तृतीय-पक्ष स्क्रिप्टों का सामान्य सेट शामिल है - समाचार साइटों या वीडियो वाले लैंडिंग पृष्ठों पर खपत अधिक होगी।
| उपकरण | 1000 पृष्ठों पर ट्रैफ़िक | JS-रेंडरिंग | बॉट्स की पहचान को बायपास करना |
|---|---|---|---|
| requests (Python) | 0.19-0.23 GB | नहीं | कमजोर |
| Playwright (WebKit) | 2.6-3.7 GB | हाँ | मध्यम |
| Puppeteer (Chromium) | 3.1-4.2 GB | हाँ | मध्यम |
| Playwright (Chromium) | 2.9-4.3 GB | हाँ | अच्छा |
| Playwright (Firefox) | 3.3-4.6 GB | हाँ | मध्यम |
मुख्य निष्कर्ष: यदि वेबसाइट को आवश्यक डेटा प्राप्त करने के लिए JavaScript का रेंडरिंग करने की आवश्यकता नहीं है, तो requests किसी भी ब्राउज़र समाधान की तुलना में 15-20 गुना अधिक ट्रैफ़िक बचाता है। लेकिन यदि सामग्री गतिशील रूप से लोड होती है या वेबसाइट सक्रिय रूप से ब्राउज़र के व्यवहार की जांच करती है - तो ब्राउज़र रेंडरिंग के लिए ट्रैफ़िक के लिए भुगतान करना पड़ेगा।
कैसे ट्रैफ़िक की खपत को 5-10 गुना कम करें
भले ही आपको पूर्ण ब्राउज़र की आवश्यकता हो, ट्रैफ़िक की खपत को बिना आवश्यक डेटा खोए नाटकीय रूप से कम किया जा सकता है। यहां कार्यशील तकनीकें हैं, जिन्हें मैंने 1000 पृष्ठों के उसी सेट पर परीक्षण किया है।
1. छवियों, फ़ॉन्ट और मीडिया को अवरुद्ध करना। छवियाँ आमतौर पर पृष्ठ के वजन का आधे से अधिक हिस्सा बनाती हैं, और पाठ डेटा को पार्स करने के लिए उनकी आवश्यकता नहीं होती है।
await page.route('**/*', (route) => {
const type = route.request().resourceType();
if (['image', 'font', 'media'].includes(type)) {
route.abort();
} else {
route.continue();
}
});
यह तकनीक Playwright और Puppeteer दोनों में समान रूप से काम करती है और बिना HTML और पाठ डेटा खोए ट्रैफ़िक को 40-60% कम करती है।
2. तृतीय-पक्ष डोमेन को अवरुद्ध करना। विज्ञापन नेटवर्क, विश्लेषण, चैट विजेट अपने स्वयं के स्क्रिप्ट और चित्र लोड करते हैं, जो आपकी आवश्यकता नहीं है। आप डोमेन के आधार पर अनुरोधों को फ़िल्टर कर सकते हैं, केवल मुख्य संसाधन और इसके CDN को छोड़कर।
3. "domcontentloaded" का उपयोग करना "networkidle" के बजाय। नेटवर्क की पूरी लोडिंग की प्रतीक्षा करना ब्राउज़र को सभी बैकग्राउंड अनुरोधों की प्रतीक्षा करने के लिए मजबूर करता है, जिसमें विश्लेषण और लेज़ी लोडिंग शामिल हैं। यदि डेटा पहले DOM में दिखाई देता है - तो पहले के इवेंट पर स्विच करना पार्सिंग को तेज करता है और अनावश्यक लोडिंग को कम करता है।
4. अनुरोधों के बीच स्थिर संसाधनों का कैश करना। यदि वेबसाइट सभी पृष्ठों पर समान CSS/JS फ़ाइलों का उपयोग करती है, तो ब्राउज़र कैश (हमारे परीक्षण की शर्तों के विपरीत) एक ही डोमेन के कई URL के अनुक्रमिक ब्राउज़िंग के दौरान महत्वपूर्ण मात्रा में बचत करता है।
5. हाइब्रिड दृष्टिकोण। कई टीमें पहले requests का प्रयास करती हैं, और केवल यदि डेटा की कमी होती है - तो Playwright या Puppeteer के माध्यम से विशिष्ट पृष्ठों पर स्विच करती हैं। यह ट्रैफ़िक की कम बुनियादी खपत को रेंडरिंग की संभावना के साथ संयोजित करता है जहाँ इसकी वास्तव में आवश्यकता होती है।
संसाधनों को सही तरीके से अवरुद्ध करने पर Puppeteer और Playwright का ट्रैफ़िक 3-4 GB से 0.6-1.2 GB तक 1000 पृष्ठों पर कम हो जाता है - अंतर requests की तुलना में स्पष्ट रूप से कम हो जाता है, जबकि JS-रेंडरिंग और एंटी-बॉट सुरक्षा के साथ काम करने की क्षमता बनी रहती है।
कैसे ट्रैफ़िक की मात्रा के लिए प्रॉक्सी चुनें
ट्रैफ़िक की गणना सीधे प्रॉक्सी के प्रकार के चयन को प्रभावित करती है। स्थिर वेबसाइटों पर requests के माध्यम से हल्के HTTP अनुरोधों के लिए डेटा सेंटर प्रॉक्सी अच्छी तरह से उपयुक्त हैं - वे तेज़, ट्रैफ़िक में सस्ते हैं और पर्याप्त हैं यदि वेबसाइट व्यवहारिक संकेतों की जांच नहीं करती है।
यदि कार्य को एंटी-बॉट सिस्टम को बायपास करने के लिए Playwright या Puppeteer के माध्यम से पूर्ण रेंडरिंग की आवश्यकता है - जैसे कि मार्केटप्लेस पर कीमतें इकट्ठा करना या खोज इंजन के परिणामों की निगरानी करना - तो आवासीय प्रॉक्सी का उपयोग करना अधिक समझदारी है। ये IP प्रतिष्ठा के आधार पर कम अवरुद्ध होते हैं, जो महत्वपूर्ण है जब प्रत्येक अनुरोध "कई मेगाबाइट" का होता है और अवरोध के कारण डेटा का पुनः प्राप्त करना महंगा होता है।
उन परिदृश्यों के लिए जहाँ वेबसाइट IP और उपयोगकर्ता-एजेंट की सख्ती से जांच करती है (बैंकिंग सेवाएँ, मोबाइल सत्यापन के साथ ऐप), मोबाइल प्रॉक्सी पर विचार करना उचित है - ट्रैफ़िक की उच्च लागत के बावजूद, वे IP पते की अधिकतम विश्वसनीयता प्रदान करते हैं और बैन के कारण पुनः अनुरोधों की संख्या को कम करते हैं।
व्यावहारिक मार्गदर्शिका: "एक पृष्ठ का वजन × पृष्ठों की संख्या × त्रुटियों और बैन के कारण पुनरावृत्तियों का गुणांक" के सूत्र के अनुसार ट्रैफ़िक की मात्रा की गणना करें और अंतिम GB की तुलना प्रदाता के टैरिफ से करें। ऊपर वर्णित संसाधनों का अनुकूलन आमतौर पर प्रॉक्सी के सस्ते प्रकार के चयन की तुलना में अधिक बचत देता है - लेकिन सही उपकरण और सही प्रॉक्सी का संयोजन अधिकतम प्रभाव देता है।
निष्कर्ष
requests ट्रैफ़िक के लिए सबसे किफायती उपकरण बना हुआ है - 1000 पृष्ठों पर लगभग 0.2 GB, लेकिन गतिशील सामग्री वाली वेबसाइटों के लिए उपयुक्त नहीं है। Puppeteer और Playwright पूर्ण रेंडरिंग और सुरक्षा को बायपास करने में बेहतर हैं, लेकिन ट्रैफ़िक की खपत 1000 पृष्ठों पर 3-4.5 GB तक बढ़ जाती है। छवियों, फ़ॉन्ट और तृतीय-पक्ष डोमेन को अवरुद्ध करने से इस अंतर को 3-5 गुना कम किया जा सकता है, आवश्यक डेटा को बनाए रखते हुए।
बड़े पैमाने पर पार्सिंग शुरू करने से पहले, चयनित उपकरण के साथ अपेक्षित ट्रैफ़िक की मात्रा की गणना करें और इसे प्रॉक्सी के बजट में शामिल करें। यदि कार्य को JavaScript का रेंडरिंग और एंटी-बॉट सिस्टम के प्रति स्थिरता की आवश्यकता है, तो आवासीय प्रॉक्सी के माध्यम से छोटे पृष्ठों के सेट पर परीक्षण चलाने से वास्तविक GB खपत का सटीक अनुमान लगाने में मदद मिलेगी।