كاتب المسرح مقابل دمى مقابل الطلبات: حركة المرور على 1000 صفحة

إذا كنت تدفع مقابل ترافيك البروكسي بالجيجابايت، فإن الفرق بين المتصفح بدون واجهة المستخدم وعميل HTTP العادي قد يكلفك 15-20 مرة أكثر على نفس مجموعة البيانات المكونة من 1000 صفحة. في هذه المقالة - قياسات حقيقية لاستهلاك الترافيك لـ Playwright و Puppeteer ومكتبة Python requests، كود للاختبارات وطرق فعالة لتقليل حجم البيانات دون فقدان المحتوى.

لماذا يعتبر استهلاك الترافيك حرجًا لتحليل البيانات

معظم مزودي البروكسي، بما في ذلك التجمعات السكنية والمحمولة، يقومون بتسعير الترافيك بالجيجابايت، وليس بعدد الطلبات. هذا يعني أن الأداة التي تستخدمها لتحليل الموقع تؤثر مباشرة على ميزانية المشروع. يقوم المتصفح بدون واجهة المستخدم بتحميل الصفحة بالكامل: HTML و CSS و JavaScript والصور والخطوط والسكريبتات التحليلية والإعلانات والمتعقبين. بينما يقوم عميل HTTP مثل requests بتحميل فقط ما طلبته بوضوح - عادة ما يكون ذلك مستند HTML نظيف.

الفرق يكون ملحوظًا بشكل خاص على نطاق واسع. إذا كنت تقوم بتحليل بطاقات المنتجات على Wildberries أو Ozon، أو تجمع أسعار المنافسين أو تراقب نتائج Google، فإن حجم 1000 صفحة هو المعدل اليومي النموذجي لسكريبت واحد. عند العمل مع عدة مئات من الآلاف من الصفحات شهريًا، يصبح التوفير في الترافيك بندًا ملحوظًا في النفقات، خاصة إذا كانت البروكسي السكنية مستخدمة، حيث تكون تكلفة الجيجابايت أعلى من مراكز البيانات.

تعقيد إضافي هو أن المواقع الحديثة تحمي نفسها بنشاط من الروبوتات: تتحقق من عرض JavaScript وسلوك الماوس وبصمة canvas. هذا يجبر المطورين على الانتقال من طلبات HTTP البسيطة إلى متصفحات كاملة مثل Playwright أو Puppeteer، التي تستهلك الترافيك بشكل أكبر بكثير. فهم الأرقام الدقيقة يساعد على حساب ميزانية البروكسي مسبقًا واختيار الأداة الصحيحة للمهمة المحددة.

منهجية قياس الترافيك

من أجل مقارنة عادلة، استخدمت نفس القائمة المكونة من 1000 عنوان URL - بطاقات منتجات متوسطة التعقيد مع الصور وسكريبتات التحليل وبعض الويدجتات الخارجية (هيكل نموذجي لموقع التجارة الإلكترونية). تم قياس الترافيك من خلال مراقب الشبكة النظامي ووسائل تسجيل الطلبات المدمجة في كل أداة.

الشروط المهمة للتجربة:

تم إيقاف تشغيل ذاكرة التخزين المؤقت للمتصفح - يتم تحميل كل صفحة "من الصفر"، كما يحدث عند العمل من خلال تدوير البروكسي مع عناوين IP مختلفة
تم تشغيل وضع عدم الواجهة في جميع اختبارات المتصفح - هكذا تعمل معظم السكريبتات الإنتاجية
بدون حظر الموارد في السيناريو الأساسي - لإظهار "الاستهلاك النظيف" بدون تحسينات
نفس الشبكة ونفس مجموعة الصفحات لجميع الأدوات الثلاثة

هذه الطريقة تعطي أرقامًا قابلة للمقارنة يمكن تطبيقها على حالتك الخاصة - بضربها في عدد الصفحات في مشروعك وتقسيمها على حجم تسعيرة البروكسي.

requests: الحد الأدنى لاستهلاك الترافيك

مكتبة requests في Python تقوم بتحميل فقط جسم استجابة HTTP - ما طلبته بوضوح. لا يوجد JavaScript، لا صور، لا طلبات إضافية إلى CDN. متوسط وزن صفحة HTML واحدة لبطاقة التجارة الإلكترونية في اختباري كان حوالي 180-250 كيلوبايت من HTML غير المضغوط.

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} ميغابايت")

على 1000 صفحة، كان الاستهلاك النهائي 190-230 ميغابايت - أي أقل من 0.25 جيجابايت. هذه هي الخيار الأكثر اقتصادًا، ولكن لديه قيود حرجة: إذا كان الموقع يقوم بعرض المحتوى عبر JavaScript (React، Vue، تحميل الأسعار الديناميكي)، ستحصل requests على هيكل فارغ من الصفحة بدون البيانات المطلوبة. بالنسبة لـ HTML الثابت أو المواقع ذات SSR، هذا هو الخيار المثالي من حيث نسبة الترافيك والنتيجة.

Puppeteer: كم يزن Chrome بدون واجهة المستخدم

Puppeteer يدير محرك Chromium الحقيقي، لذلك يقوم بتحميل الصفحة بالكامل: HTML و CSS والخطوط والصور وسكريبتات التتبع وإعلانات iframe. حتى في وضع عدم الواجهة، يقوم المتصفح بتنفيذ جميع الطلبات الشبكية التي كان سيقوم بها المستخدم العادي في 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)} ميغابايت`);
  await browser.close();
})();

في اختباري، كان متوسط وزن صفحة واحدة عبر Puppeteer حوالي 2.8-4.5 ميغابايت، اعتمادًا على عدد الصور وسكريبتات الطرف الثالث. على 1000 صفحة، كان هذا يعطي نتيجة 3.1-4.2 جيجابايت - أي 15-18 مرة أكثر من requests. الجزء الأكبر من الترافيك يأتي من الصور (عادة 40-55% من وزن الصفحة) وسكريبتات التحليل والإعلانات وويدجتات الدردشة (20-30%).

Playwright: الترافيك في المتصفحات المختلفة

يعمل Playwright بطريقة مشابهة، ولكنه يدعم ثلاثة محركات - Chromium و Firefox و WebKit. يختلف استهلاك الترافيك بينها: 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} ميغابايت")
    browser.close()

على Chromium عبر Playwright، كانت النتيجة قريبة من Puppeteer - 2.9-4.3 جيجابايت على 1000 صفحة، وهو منطقي، حيث تستخدم الأداتان نفس المحرك. على WebKit، كان الاستهلاك أقل بنسبة 10-15%، حوالي 2.6-3.7 جيجابايت، بينما على Firefox كان أعلى قليلاً، 3.3-4.6 جيجابايت. الفرق يفسر باختلافات في معالجة الخطوط، وفك تشفير الصور وسلوك كومة الشبكة لكل محرك متصفح.

جدول المقارنة: جيجابايت لكل 1000 صفحة

أدناه جدول ملخص لجميع الخيارات التي تم اختبارها، مع تقريب إلى نطاقات عملية. الأرقام صالحة لصفحة تجارة إلكترونية متوسطة مع صور ومجموعة نموذجية من سكريبتات الطرف الثالث - على مواقع الأخبار أو الصفحات المقصودة مع الفيديو، سيكون الاستهلاك أعلى.

الأداة	الترافيك على 1000 صفحة	عرض JavaScript	تجاوز كشف الروبوتات
requests (Python)	0.19-0.23 جيجابايت	لا	ضعيف
Playwright (WebKit)	2.6-3.7 جيجابايت	نعم	متوسط
Puppeteer (Chromium)	3.1-4.2 جيجابايت	نعم	متوسط
Playwright (Chromium)	2.9-4.3 جيجابايت	نعم	جيد
Playwright (Firefox)	3.3-4.6 جيجابايت	نعم	متوسط

الاستنتاج الرئيسي: إذا كان الموقع لا يتطلب عرض 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 وتقلل الترافيك بنسبة 40-60% دون فقدان HTML والبيانات النصية.

2. حظر النطاقات الخارجية. تقوم الشبكات الإعلانية والتحليلات وويدجتات الدردشة بتحميل سكريبتاتها وصورها الخاصة، والتي ليست ضرورية لك. يمكنك تصفية الطلبات حسب النطاق، مع ترك المورد الرئيسي و CDN الخاص به فقط.

3. استخدام "domcontentloaded" بدلاً من "networkidle". الانتظار لتحميل الشبكة بالكامل يجبر المتصفح على الانتظار لجميع الطلبات الخلفية، بما في ذلك التحليلات والتحميل البطيء. إذا ظهرت البيانات في DOM في وقت مبكر - فإن التبديل إلى حدث أبكر يسرع التحليل ويقلل من التحميلات الزائدة.

4. تخزين الموارد الثابتة بين الطلبات. إذا كان الموقع يستخدم نفس ملفات CSS/JS على جميع الصفحات، فإن تشغيل ذاكرة التخزين المؤقت للمتصفح (على عكس شروط اختبارنا) يوفر حجمًا كبيرًا عند المرور المتسلسل عبر عدد كبير من عناوين URL لنفس النطاق.

5. نهج هجيني. العديد من الفرق تبدأ باستخدام requests، وإذا كانت البيانات غير كافية - تنتقل إلى صفحات محددة عبر Playwright أو Puppeteer. هذا يجمع بين انخفاض الاستهلاك الأساسي للترافيك مع إمكانية العرض حيثما كان ذلك ضروريًا.

مع حظر الموارد بشكل صحيح، ينخفض استهلاك الترافيك لـ Puppeteer و Playwright من 3-4 جيجابايت إلى 0.6-1.2 جيجابايت لكل 1000 صفحة - يصبح الفرق أقل بكثير مقارنة بـ requests، مع الحفاظ على إمكانية العمل مع عرض JavaScript وحماية ضد الروبوتات.

كيفية اختيار البروكسي حسب حجم الترافيك

يؤثر حساب الترافيك مباشرة على اختيار نوع البروكسي. لطلبات HTTP الخفيفة عبر requests على المواقع الثابتة، تعتبر بروكسي مراكز البيانات مناسبة جدًا - فهي سريعة ورخيصة من حيث الترافيك وكافية إذا لم يتحقق الموقع من إشارات السلوك.

إذا كانت المهمة تتطلب عرضًا كاملاً عبر Playwright أو Puppeteer لتجاوز أنظمة مكافحة الروبوتات - على سبيل المثال، عند جمع الأسعار في الأسواق أو مراقبة نتائج محركات البحث - من الأفضل استخدام بروكسي سكنية. فهي نادرًا ما يتم حظرها بناءً على سمعة IP، وهو أمر حرج عندما "يزن" كل طلب عدة ميغابايت وتكلفة إعادة جمع البيانات بسبب الحظر تكون مرتفعة.

بالنسبة للسيناريوهات التي يتحقق فيها الموقع بشكل صارم من تطابق IP و user-agent (الخدمات المصرفية، التطبيقات مع التحقق المحمول)، من المفيد النظر في بروكسي موبايل - على الرغم من تكلفة الترافيك الأعلى، فإنها توفر أقصى موثوقية لعنوان IP وتقلل من عدد الطلبات المتكررة بسبب الحظر.

كمرجع عملي: احسب حجم الترافيك باستخدام صيغة "وزن الصفحة الواحدة × عدد الصفحات × معامل التكرار بسبب الأخطاء والحظر" وقارن الجيجابايت النهائي بتسعيرة المزود. عادةً ما توفر تحسين الموارد الموضحة أعلاه المزيد من التوفير مقارنة باختيار نوع بروكسي أرخص - ولكن الجمع بين الأداة الصحيحة والبروكسي الصحيح يعطي أقصى تأثير.

الخاتمة

تظل requests الأداة الأكثر اقتصادًا من حيث الترافيك - حوالي 0.2 جيجابايت لكل 1000 صفحة، لكنها غير مناسبة للمواقع ذات المحتوى الديناميكي. توفر Puppeteer و Playwright عرضًا كاملاً وأفضل تجاوز للحماية، لكن استهلاك الترافيك يرتفع إلى 3-4.5 جيجابايت لنفس 1000 صفحة. يقلل حظر الصور والخطوط والنطاقات الخارجية من هذه الفجوة بمقدار 3-5 مرات، مع الحفاظ على البيانات المطلوبة.

قبل بدء تحليل واسع النطاق، احسب حجم الترافيك المتوقع مع الأخذ في الاعتبار الأداة المختارة وخصصه في ميزانية البروكسي. إذا كانت المهمة تتطلب عرض JavaScript والقدرة على مقاومة أنظمة مكافحة الروبوتات، ابدأ بتجربة اختبار على مجموعة صغيرة من الصفحات عبر بروكسي سكنية - سيسمح لك ذلك بتقييم الاستهلاك الفعلي للجيجابايت بدقة قبل البدء في معالجة البيانات الكاملة.