كيفية تقليل حركة مرور المتصفح بمقدار 5 مرات دون فقدان البيانات: 7 طرق لمهندسي البيانات

كل ميغابايت إضافي من حركة مرور المتصفح يعني إما دفع ثمن لمزود البروكسي، أو خطر الوصول إلى الحدود والحصول على حظر من IP. إذا كنت تجمع الأسعار من Wildberries أو Ozon أو تراقب الإعلانات على Avito من خلال مئات عناوين البروكسي، فإن توفير حركة المرور يؤثر بشكل مباشر على ميزانية المشروع. في هذه المقالة، نقدم تقنيات فنية محددة تسمح بتقليل حجم البيانات المنقولة بمقدار 4-5 مرات، مع الحفاظ على كمال ودقة المعلومات المستخرجة.

لماذا تؤثر حركة مرور المتصفح على الميزانية

معظم مزودي البروكسي يقومون بتسعير البروكسيات السكنية والمحمولة بناءً على حجم الجيجابايت المنقولة، وليس على مدة الاستخدام. إذا كان المتصفح الخاص بك يقوم بتحميل صفحة منتج Wildberries بالكامل — مع الصور، ونصوص التوصيات، وأدوات التحليل، والخطوط — فإنك تدفع مقابل 2-3 ميغابايت لكل بطاقة، بينما تحتاج فعليًا فقط إلى 15-20 كيلوبايت من النص: الاسم، السعر، التقييم، التوفر.

عند التوسع إلى 50,000-100,000 بطاقة يوميًا، فإن الفرق بين "تحميل الكل" و"تحميل فقط ما هو ضروري" يتحول إلى عشرات الجيجابايت من حركة المرور الزائدة يوميًا. هذه ليست فقط نفقات على البروكسي، ولكن أيضًا زيادة الحمل على الموقع المستهدف، مما يزيد من فرصة التعرض لحماية مضادة للروبوتات والحصول على CAPTCHA أو حظر مؤقت من 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 في Python. مثل هذا الطلب يزن كيلوبايت، وليس ميغابايت، لأنه لا يتطلب محرك عرض المتصفح، أو استدعاءات الشبكة لأدوات التحليل، أو الموارد الثانوية.

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 الداخلية التي يستدعيها الواجهة الأمامية. يمكن العثور على هذه النقاط النهائية من خلال علامة التبويب Network في أدوات المطورين، عن طريق تصفية الطلبات حسب نوع XHR/Fetch. عادةً ما تعيد مثل هذه الطلبات JSON بحجم 5-30 كيلوبايت مع بيانات نظيفة: id المنتج، السعر، الخصم، المخزون، التقييم — بدون أي بايت من HTML أو CSS.

يمكن أن يصل الفرق في حجم البيانات المنقولة بين صفحة HTML كاملة والاتصال المباشر بـ JSON API إلى 10-15 مرة. ميزة إضافية — من الأسهل برمجيًا استخراج JSON: لا حاجة إلى محددات XPath، يكفي الوصول إلى الحقل المطلوب باستخدام مفتاح القاموس. العيب هو أن هذه النقاط النهائية غالبًا ما تتطلب رؤوسًا محددة، أو رموز جلسة، أو معلمات توقيع الطلب، والتي يجب استخراجها مسبقًا من الصفحة الرئيسية أو التطبيق المحمول.

الطريقة 4: ضغط Gzip وBrotli

حتى إذا كنت مضطرًا لاسترداد HTML الكامل، فإن تضمين الضغط الصحيح يمكن أن يقلل من حجم النقل بنسبة 60-80%. العديد من أدوات الاستخراج المكتوبة يدويًا لا ترسل رأس Accept-Encoding: gzip, br، مما يجعل الخادم يرسل استجابة غير مضغوطة. المكتبات requests وhttpx تقوم بفك ضغط Gzip وBrotli تلقائيًا — المهم هو تحديد دعم الضغط بوضوح في رؤوس الطلب.

عادةً ما يضغط Brotli النص HTML بشكل أقوى من Gzip بنسبة 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، أو معرفات الجلسة. تطبيع URL قبل وضعه في قائمة الانتظار (إزالة معلمات التتبع، فرز معلمات الاستعلام) يزيل 10-30% من الطلبات الزائدة عند الزحف عبر كتالوجات كبيرة.

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

كيف يتناسب ذلك مع استراتيجية البروكسي

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

بالنسبة للمواقع ذات الحماية الصارمة ضد الروبوتات، حيث من المهم تقليد سلوك المستخدم الحقيقي، من الأفضل استخدام بروكسيات سكنية — من خلال دمجها مع طرق حظر الموارد الزائدة، ستحصل على حركة مرور منخفضة ودرجة عالية من ثقة الموقع في الطلب. وإذا كان الاستخراج يتم عبر النسخ المحمولة من APIs الأسواق، حيث تكون البيانات أكثر إحكامًا ونظام الحماية ضد الروبوتات يركز على نطاقات IP المحمولة، فمن الأفضل النظر في البروكسيات المحمولة لتقليل مخاطر الحظر.

الجمع بين "أقل حركة مرور لكل طلب" + "نوع البروكسي الصحيح للغرض" يسمح بتقليل تكاليف البنية التحتية وزيادة سرعة جمع البيانات دون فقدان الموثوقية.

جدول مقارنة الطرق

الطريقة	تقليل حركة المرور	صعوبة التنفيذ
حظر الصور/CSS/الخطوط	50-70%	منخفضة
طلبات HTTP بدلاً من المتصفح	3-8 مرات	متوسطة
JSON API المخفية	10-15 مرة	عالية
ضغط Gzip/Brotli	60-80%	منخفضة
الطلبات الشرطية (ETag)	حتى 95% على الصفحات غير المتغيرة	متوسطة
إزالة التكرار من URL وأولوية الزحف	2-4 مرات	متوسطة

قائمة التحقق للتنفيذ

• تحقق مما إذا كانت الصفحة المستهدفة تتطلب عرض JavaScript، أو يمكن استرداد HTML مباشرة عبر httpx/requests
• قم بإعداد حظر الصور/الوسائط/الخطوط/أنماط CSS في المتصفح بدون واجهة، إذا كان المتصفح لا يزال مطلوبًا
• ابحث عن JSON API الداخلية عبر أدوات المطورين → الشبكة → XHR/Fetch
• أضف رؤوس Accept-Encoding: gzip, br إلى جميع الطلبات
• قم بتنفيذ تخزين ETag/Last-Modified للطلبات الشرطية على URL المتكررة
• قم بتطبيع وإزالة التكرار من قائمة URL قبل الزحف
• قم بإعداد تردد زحف تكيفي بناءً على أهمية وتغير البيانات
• اختر نوع البروكسي وفقًا لملف حركة المرور النهائي — مركز بيانات، سكني أو محمول

الخاتمة

تقليل حركة مرور المتصفح بمقدار 5 مرات هو هدف واقعي إذا تم تطبيق الطرق بشكل متسلسل: إزالة الموارد الزائدة، الانتقال إلى طلبات HTTP المباشرة أو JSON API حيثما كان ذلك ممكنًا، تفعيل الضغط، استخدام الطلبات الشرطية للبيانات غير المتغيرة وتحسين نمط الزحف نفسه. كل خطوة من هذه الخطوات تعطي تأثيرًا قابلًا للقياس، وفي مجموعها تغير بشكل جذري اقتصاديات المشروع لجمع البيانات من الأسواق ومواقع أخرى.

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