تكاد كل قائمة بعنوان «أفضل أداة استخراج بيانات مفتوحة المصدر» تقع في نفس الخطأ الهادئ: لا أحد يختبر الأدوات على الصفحات نفسها. يُختبر Scrapy على مقال إخباري، وPlaywright على نموذج متجر إلكتروني، وColly على أي شيء كان متاحاً للكاتب، ثم تُصفّ هذه الأدوات وجهاً لوجه وكأن الأرقام تقيس الشيء نفسه. هذا النوع من الترتيب يخبرك أكثر عن الصفحات نفسها مما يخبرك عن الأدوات.
لذلك فعلت الشيء الواضح والممل الذي تتجاوزه أغلب القوائم: أنشأت مجموعة اختبار واحدة، ومرّرت من خلالها جميع الأدوات التسع. صفحة ثابتة لكتالوج منتجات، وصفحة يُعاد بناؤها عبر JavaScript، ومقال مختبئ وسط عناصر تنقّل وتذييل لا لزوم لهما، واستجابة HTTP 500 مقصودة، ومخطط زحف بروابط داخلية، إلى جانب موقعين عامّين للتدريب. نفس الحقيقة المرجعية، ونفس القياسات، في كل مرة. والسكريبتات والمخرجات الخام كلها موجودة في مستودع عام واحد للقياس حتى تتمكن من إعادة التجربة بنفسك. والنتيجة ليست لوحة صدارة مرتبة كما تعدك هذه القوائم — لا يوجد فائز واحد. هناك ثلاث مهام مختلفة، والأدوات التسع تتوزع بينها تقريباً بشكل طبيعي.
جرّب Thunderbit لاستخراج بيانات الويب
كيف أُجري الاختبار، وما هو القيد الوحيد الذي أصرّح به بوضوح
تعاملت كل أداة مع الأشكال نفسها من الاختبارات: 12 منتجاً ثابتاً موزعة على صفحتين، و8 منتجات تُحقن عبر JavaScript بعد تأخير، ومقال حقيقي محاط بحشو التنقل والتذييل لكنه يحتوي على ثلاث فقرات فعلية، واستجابة خادم 500 مقصودة، ومخطط روابط داخلية. هذا التصميم هو ما يجعل النتائج متقاربة: عبارة «8/8 منتجات ديناميكية» تعني الشيء نفسه تماماً سواء تم إنتاجها بواسطة Puppeteer أو Crawlee.
وهنا الحد الذي تتجاهله معظم المقارنات. كل حزمة من حزم الاختبار تعكس نسختها الخاصة من هذه العينات، لذلك فإن أعداد الأحرف المطلقة ليست قابلة للمقارنة الصارمة بين الأدوات — اقرأها كمؤشرات داخل كل أداة، لا كدرجة مشتركة بين الأدوات. الأرقام القابلة للمقارنة فعلاً هي الاسترجاع، ونجاح/فشل JavaScript، والسلوك البنيوي. وهناك ملاحظة نطاق مهمة بنفس الروح: اختبار Crawl4AI للكتالوج الثابت شمل الصفحة الأولى فقط، لذلك فإن 6/6 هنا تعني استرجاعاً كاملاً ضمن نطاق أضيق، بينما جابت الأدوات الأخرى الصفحتين لتحقق 12/12 — نطاق أصغر، لا فقدان جزئي. التفسير الكامل، حالة بحالة، موجود في شرح المنهجية.
وتوجد ملاحظة احترازية أخرى قبل الأرقام. كل حزمة تتضمن أيضاً درجة بحثية أولية، لكنني أتعمد عدم عرضها كجدول ترتيب. كانت هذه الدرجات أدوات داخلية لمراجعة كل أداة مقابل أدلتها الخاصة، وليست جدول دوري؛ ونشرها كترتيب واحد سيعيد تماماً مشكلة الدقة الزائفة التي أُنشئ هذا الاختبار لتجنبها. ما يلي هو خلاصة لما أظهره الاختبار، لا لوحة نتائج.
المشهد كاملاً على اختبار واحد
إذا قرأت العمودين «هل يعرض JavaScript؟» و«هل لديه قائمة زحف مدمجة؟» ستجد أن المهام الثلاث تكشف عن نفسها تقريباً وحدها.
| الأداة | اللغة | هل يعرض JavaScript؟ | الاسترجاع الثابت | المخرجات البنيوية | قائمة زحف مدمجة | وزن الإعداد | الرخصة |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | نعم (متصفح) | 6/6 (الصفحة 1) | مخطط CSS | BFS/DFS مدمجة | ثقيل (حزمتا متصفح) | Apache-2.0 |
| Firecrawl | مستضاف ذاتياً | نعم (playwright-service) | Markdown كامل | نعم | /v1/crawl | الأثقل (6 حاويات) | AGPL-3.0 |
| trafilatura | Python | لا | 3/3 مقال | لا (نص فقط) | لا | خفيف | Apache-2.0 |
| Crawlee | Node/TS | اختياري حسب المحرك | 12/12 | عبر الاستخراج | نعم (RequestQueue) | متوسط (+~80 MiB) | Apache-2.0 |
| Playwright | Node/multi | نعم | 12/12 | يدوي | لا (BFS مكتوبة يدوياً) | متوسط (متصفح) | Apache-2.0 |
| Puppeteer | Node | نعم (Chrome) | 12/12 | يدوي | لا (BFS مكتوبة يدوياً) | متوسط (Chrome) | Apache-2.0 |
| Scrapy | Python | لا | 12/12 | تصدير Feed (JSON/CSV/XML) | نعم (مدمجة) | متوسط (اعتماد Twisted) | BSD-3 |
| Colly | Go | لا | 12/12 | عبر callbacks | تحكم بالعمق | خفيف (ملف ثنائي واحد + Go) | Apache-2.0 |
| Scrapling | Python | لا (جالب HTTP) | 12/12 | نعم | لا | متوسط ([fetchers]) | BSD-3 |
ملاحظة على البيانات الوصفية في هذا الجدول وما بعده: أعداد النجوم وإصدارات الحزم تم التقاطها في أوائل يوليو 2026، وكلاهما يتغير بسرعة. حدّثها من صفحات GitHub وpackage الخاصة بكل مشروع قبل اعتبارها بيانات حالية.
فهرس المراجعات المنفصلة لكل أداة
لكل مشروع في هذه المقارنة مراجعة تفصيلية منفصلة:
- مراجعة Crawl4AI
- مراجعة Firecrawl
- مراجعة trafilatura
- مقارنة Playwright وPuppeteer
- مراجعة Crawlee
- مراجعة Scrapy
- مراجعة Colly
- مراجعة Scrapling
وهذه هي أغلفة المراجعات — بالإضافة إلى لقطتين حقيقيتين من اختبار عرض JavaScript، حتى لا تبقى عبارة «8/8 ديناميكية» مجرد رقم على الصفحة.
المهمة الأولى: تحويل الصفحة إلى نص جاهز لنماذج LLM
إذا كان ما تريده هو Markdown نظيف لتغذية خط RAG، فهناك ثلاث أدوات تتنافس — وأكثر ما يميزها أنها مختلفة تماماً في الشكل.
Crawl4AI هو، خلف التسويق، مولد Markdown يعتمد على المتصفح. ومن المفيد هنا إسقاط حكاية «الذكاء التكيفي ومحددات التعلم الذاتي» التي تلاحقه في نتائج البحث: لا يوجد لديه شيء بهذا الاسم — تلك خدعة تخص مكتبة أخرى بالكامل (وسأعود إلى ذلك عند الحديث عن Scrapling). لكن ما يفعله فعلاً يفعله جيداً. على موقع Books to Scrape العملي أخرج 13,476 حرفاً من Markdown، ويدعم استخراج CSS schema لعمليات السحب البنيوية، كما أن الزحف العميق BFS المدمج لديه جاب 5 صفحات في مخطط الزحف مع عرض صفحة JavaScript والتقاط لقطة شاشة. لكن توجد مشكلتان واضحتان. فـ Markdown الخام لديه يحمل الحشو الخاص بالصفحة ما لم تفعل فلتر المحتوى، والاستجابة 500 المقصودة عادت كـ success=false — ليس لأن Crawl4AI أمسك خطأ HTTP بشكل أنيق، بل لأن هيورستك المحتوى لديه نظر إلى جسم الخطأ الصغير ووسمه minimal_text ... blocked. كما أن الإعداد يضع حزمتين للمتصفح على القرص. الإصدار 0.9.0، رخصة Apache-2.0، وحوالي 71 ألف نجمة في أوائل يوليو.
Firecrawl هو الأثقل هنا، واستضافته ذاتياً تعمل بالفعل — وأقول «بالفعل» لأن مجموعة الحاويات الست (api وplaywright-service وredis وrabbitmq وnuq-postgres وfoundationdb) اشتغلت فعلاً وأنتجت 9,222 حرفاً من Markdown جاهز لنماذج LLM من صفحة Books to Scrape نفسها. كما عرض صفحة JavaScript عبر playwright-service المدمج لديه، وظهرت عبارة Einstein بعد السكربت في المخرجات، وهذا أثبت أن العرض كان حقيقياً. المشكلتان اللتان واجهتهما كانتا بسبب البيئة لا Firecrawl، وأريد أن أكون دقيقاً حتى لا ينسخ أحد الحل الخاطئ: البناء من المصدر تعثر بسبب خلل عابر في containerd snapshotter تحت colima (فانتقلت إلى الصور الجاهزة)، كما أن نطاق DNS في colima من نوع 198.18.x.x فعّل حماية Firecrawl من SSRF، وتم تجاوز ذلك عبر ALLOW_LOCAL_WEBHOOKS=true — وهو حل محلي للتطوير، وليس شيئاً يجب تعطيله في بيئة حقيقية. كما أن النواة المستضافة ذاتياً لا تتضمن Fire-engine، طبقة مكافحة الحظر السحابية، ولم أختبر واجهة السحابة. والإشارة الأكبر هنا هي الرخصة: النواة المستضافة ذاتياً في Firecrawl هي AGPL-3.0، وهذا يتطلب مراجعة قانونية حقيقية قبل أي استخدام تجاري، وليس مجرد هامش صغير. وحوالي 148 ألف نجمة في أوائل يوليو.
trafilatura هو الطرف المخالف في هذه المجموعة، وهو أيضاً الأداة التي تنساها القوائم المهووسة بـ AI باستمرار. لا متصفح. لا صفوف بنيوية. فقط نص مقالات سريع ونظيف بلغة Python الخالصة. على اختبار المقال استخرج العنوان بالإضافة إلى كل الفقرات الثلاث الفعلية من أصل 3، ونظّف الحشو بالكامل — لم يتسلل شيء مثل "Login" أو "Subscribe" أو "Copyright" — كما استخرج المؤلف والتاريخ أيضاً. وعلى صفحة منتج عامة أعاد 1,324 حرفاً من النص النظيف. وحدّه هو بالضبط ما يوحي به تصميمه: إذا وجهته إلى كتالوج، فسيعيد 12 اسم منتج كنص لكن 0 صفوف بنيوية — النص موجود، لكن البنية غير موجودة، ولا يعرض JavaScript. الإصدار 2.1.0 (الإصدار الحالي)، Apache-2.0، وحوالي 6.2 ألف نجمة. لاستخراج المقالات الخالصة، فهو أول خيار سأفكر فيه.
العددان الخاصان بـ Markdown — 13,476 من Crawl4AI و9,222 من Firecrawl — جاءا من الصفحة العامة نفسها، لكن لا تقرأهما كفارق في الجودة. إنهما يعكسان استراتيجيتين مختلفتين لكتابة Markdown (كمية الحشو الذي يحتفظ به كل منهما)، لا حكماً على أي الناتجين أفضل. هذه هي قاعدة «المؤشر داخل كل أداة» التي تحدثنا عنها سابقاً، لكن هنا بشكل واضح.
المهمة الثانية: عرض JavaScript بشكل موثوق
بعض البيانات لا تظهر في HTML إلا بعد تشغيل السكربتات، وهنا يصبح المتصفح الحقيقي غير اختياري. ثلاث أدوات تتولى هذه المهمة — واتضح أن اثنتين منها تكادان تكونان الأداة نفسها.
Playwright وPuppeteer تعادلا في كل اختبار وضعته أمامهما. كلاهما عرض 8/8 منتجات ديناميكية في الاختبار المحلي و10 على موقع Quotes JS العام، وكلاهما حقق 12/12 في الاسترجاع الثابت، وكلاهما تعامل مع 500 بشكل سليم (Puppeteer يعيد كائن response بدلاً من رمي استثناء). ولا واحدة منهما تأتي مع قائمة زحف، لذا اضطررت لكتابة BFS يدوياً، والذي وصل إلى 12 صفحة عبر العمق 0–2 في مخطط الزحف. الفرق الحقيقي الوحيد هو نطاق الاستخدام: Playwright يدعم Chromium وFirefox وWebKit ويتحدث Python و.NET، بينما Puppeteer متمحور حول Chrome ومقتصر على Node. وملاحظة مهمة لأن الإصدارات هنا تتغير بسرعة: اختبرت Playwright 1.56.0 مقابل إصدار حديث 1.61.1 واستخدمت Chromium فقط، كما اختبرت Puppeteer 24.16.0 مقابل إصدار حديث 25.3.0 — أعد الاختبار أو خفّض الوزن بحسب ذلك. كلاهما Apache-2.0؛ مع نحو 92 ألف و95 ألف نجمة على الترتيب.
Crawlee هو من يحل مشكلة قائمة الزحف التي تتركها الأداتان الأخريان مفتوحة. فهو يضم محرك Cheerio (HTTP) ومحرك Playwright (المتصفح) تحت واجهة واحدة، والفارق في صفحة واحدة يشرح الفكرة كلها: محرك Cheerio لم يرَ 0 من العناصر المحقونة عبر JavaScript، بينما محرك Playwright رأى 8/8 محلياً (و10 على الموقع العام)، والتبديل بينهما لا يحتاج سوى سطر واحد. كما أنه يمنحك RequestQueue حقيقية، ولذلك يدخل في هذه الفئة لا في الفئة الثالثة. لكن هناك تفصيلة لا يذكرها العنوان: محرك المتصفح يحتاج إلى npx playwright install منفصلة، أي نحو 80 MiB لا يجلبها npm install crawlee تلقائياً. الإصدار 3.17.0، TypeScript، Apache-2.0، وحوالي 24.6 ألف نجمة.
المهمة الثالثة: الزحف السريع بلا متصفح
إذا لم يكن هناك JavaScript على الصفحة، فالمتصفح يكون تبذيراً مكلفاً. ثلاث أدوات تعتمد على HTTP تتنافس هنا، كل واحدة من فلسفة لغوية مختلفة، وهي تختلف بطرق مثيرة للاهتمام.
Scrapy هو الإطار الأشد هندسية في المجموعة — spiders، وتصدير feeds إلى JSON/CSV/XML، وAutoThrottle، وكل ما يلزم. حقق 12/12 في الاسترجاع الثابت، واستخرج الفقرات الثلاث من 3 في المقال، وجاب 11 صفحة عبر العمق 0–2 في مخطط الزحف، والتقط 500 عبر handle_httpstatus_list. لكن ما يميزه حقاً هو فلسفته: هو لا يعرض الصفحة، بل يعيد تنفيذ الطلب. وعندما وُجّه إلى صفحة JavaScript حصل على 0 عقدة — ثم أعطته واجهة JSON خلف الصفحة نفسها 8/8. هذه هي فلسفة Scrapy في نقطة بيانات واحدة: ابحث عن الطلب الذي تنفذه الصفحة وأعد تشغيله، ولا تقُد متصفحاً. الكلفة هي حزمة اعتماد كبيرة نسبياً (Twisted وlxml وparsel)، ولم أختبره إلا على عينات صغيرة. الإصدار 2.17.0، BSD-3-Clause، وحوالي 63 ألف نجمة.
Colly هو الجواب بلغة Go، وهو صريح جداً بشأن ما هو عليه: ملف ثنائي واحد، يعتمد على callbacks عبر OnHTML وOnResponse وOnError، مع تحكم في العمق. أصاب 12/12 في الاسترجاع الثابت، واستخرج 8/8 من واجهة JSON عبر OnResponse, والتقط 500 عبر OnError, ووصل إلى 17 صفحة ضمن زحف بعمق 2 — وأتعمّد صياغتها هكذا لأن عدد الصفحات هذا هو عدّاد الهarness نفسه، وليس ضماناً بالكمال يقدمه Colly. ما لا يفعله هو JavaScript: فالاختبار الديناميكي وموقع Quotes JS كلاهما عاد بـ 0، وهو أمر مقصود. ستحتاج إلى Go toolchain للبناء، وإصدار الوحدة (v2.3.0) يتقدم حالياً على الإصدار الموسوم (v2.2.0). Apache-2.0، وحوالي 25 ألف نجمة.
Scrapling هو المتخصص، ويستحق هذا الوصف. فالمحددات التكيفية لديه مبنية لإيجاد العنصر مجدداً بعد تغيّر الـ markup — لذلك عندما غيّرت فئة HTML المستهدفة من product-name إلى product-title، التقط المحدد العادي 0، بينما أعاد الربط التكيفي العثور على العنصر الذي نتابعه على أي حال. وعلى استخراج HTTP البسيط حقق 12/12 في الثابت و8/8 في واجهة JSON. والجزء الذي لا تخفيه وثائقه: في اختبار اصطناعي متعدد العناصر استعاد 1 من 3 — هذه مقاومة لتغيّر العناصر، وليست استعادة شاملة، فلا تبالغ في تقديرها. كما أن pip install scrapling الأساسي يحتاج أيضاً إلى الإضافة [fetchers] لكي يبدأ، وStealthyFetcher الخاص به هو ملاحظة امتثال، لا ميزة أضعها في شريحة عرض. الإصدار 0.4.10 (الإصدار الحالي)، BSD-3-Clause، وحوالي 68.7 ألف نجمة.
النمط الكامن وراء المهام الثلاث
ضع الأدوات التسع جنباً إلى جنب وستظهر الصورة بوضوح. الاسترجاع الثابت الكامل — أي 12/12 — هو الحد الأدنى لأي أداة تعتمد على HTTP؛ لم تتعثر أي واحدة في الحالة السهلة، لذلك هذه ليست نقطة تمييز. أدوات المتصفح لا تستحق وزنها الإضافي إلا عندما يدخل JavaScript فعلاً في المشهد، وهي كلها تدفع الثمن في الإعداد: حزمة متصفح، أو تثبيت إضافي، أو أسطول حاويات كامل. وعمود «قائمة الزحف المدمجة» هو في الحقيقة الخط الفاصل بين إطار عمل ومحرك — Scrapy وCrawlee يقدمان التنسيق، بينما يجبرك Playwright وPuppeteer على كتابة BFS بنفسك. هذه هي بنية المجال. لا أحد يفوز بشكل عام لأن أحداً لا يلعب اللعبة نفسها.
إذاً، أي أداة تختار فعلياً؟
الاختبار يرفض تتويج فائز واحد لأن الإجابة الصحيحة ليست أداة، بل سؤال: أي واحدة من المهام الثلاث تنفذ؟
- تريد Markdown جاهزاً لنماذج LLM؟ اختر trafilatura عندما يكون المطلوب نص مقال نظيف، وCrawl4AI عندما تريد أيضاً استخراج CSS وعرض JavaScript في مكتبة واحدة، وFirecrawl عندما تريد خدمة مستضافة ذاتياً وتستطيع التعامل مع رخصة AGPL-3.0 ومع ثقل الحاويات الست.
- تحتاج إلى عرض JavaScript؟ استخدم Playwright أو Puppeteer للعرض الخام — اختر حسب المحرك واللغة لأنهما متعادلان تقريباً — واختر Crawlee عندما تريد أيضاً تنسيق الزحف دون كتابة BFS يدوياً.
- تزحف صفحات ثابتة أو واجهات API قابلة لإعادة الإنتاج وعلى نطاق واسع؟ Scrapy إذا كنت تريد إطار Python متكامل، وColly إذا كنت تريد سرعة Go في ملف ثنائي واحد، وScrapling إذا كانت مشكلتك المتكررة هي النجاة من تغيّر الـ markup.
طابق الأداة مع المهمة، وستكون كل واحدة من هذه الخيارات مبررة. لكن إن أخذت أداة من الفئة الخطأ — أداة متصفح لصفحات ثابتة، أو محلل HTTP لتطبيق JavaScript — فلن تنقذك أعلى مكتبة تقييماً على الإنترنت.
أين يدخل API الذكي المُدار بدلاً من ذلك
كل أداة مما سبق مجانية ومفتوحة المصدر وتستطيع تشغيلها بنفسك. وهذه أيضاً هي المقايضة المشتركة التي كشفها الاختبار مراراً: أنت تتحمل بيئة المتصفح، وكتابة الكود الخاص بالزحف، وحرب مكافحة الحظر، وكل أعمال الصيانة. بالنسبة لكثير من الفرق، هذا التحكم هو بالضبط الهدف، كما أن خريطة التراخيص مهمة عند تبني هذا الخيار — فمعظم المجال مرن في الترخيص (Apache-2.0 لدى Crawl4AI وCrawlee وPlaywright وPuppeteer وColly، وBSD-3 لدى Scrapy وScrapling)، مع كون النواة المستضافة ذاتياً لـ Firecrawl تحت AGPL-3.0 هي الحالة التي تحتاج مراجعة حقيقية قبل الاستخدام التجاري.
لكن لاحظ أيضاً ما الذي وثّقه الاختبار: ما الذي لا تفعله هذه الأدوات. العرض، والزحف، والبناء البنيوي، والتبديل حول الحظر — نادراً ما تجتمع كلها، ولا تحدث من دون صيانة منك. أما API مدارة لاستخراج البيانات بالذكاء الاصطناعي فتلغي هذا التراكم إلى نداء واحد. واجهتنا للمطورين في Thunderbit هي أحد الخيارات هنا، وبالنسبة للجمهور التقني فالمهم هو API وخادم MCP وCLI، لا ملحق المتصفح. POST /distill يعيد Markdown نظيفاً، وPOST /extract يعيد JSON محدداً بمخطط، مع عرض JavaScript ومكافحة الحظر على الخادم بدلاً من جهازك. ويوجد خادم MCP رسمي للوكلاء ومساعدي البرمجة — thunderbit_suggest_fields يعمل مجاناً لتخطيط الاستخراج، ثم thunderbit_distill (برصيد 1) وthunderbit_extract (20 رصيداً) يتوليان التنفيذ — كما توجد أداة CLI يمكن تثبيتها عبر npx @thunderbit/thunderbit-cli لمهام الطرفية والمهام المجدولة. ولغير المطورين في فريقك هناك أيضاً ملحق Chrome بدون كود، وتغطي الأسعار كلا البعدين.
والمقايضة هنا هي نفسها التي يدور حولها هذا الاختبار كله: إما أن تشغّل وتُدير حتى تسع مكتبات بنفسك دون كلفة لكل طلب، أو تسلّم طبقة البنية الأساسية وتدفع مقابل كل طلب. لا أحد الخيارين خطأ. الأمر يعتمد على مقدار الجزء من الـ stack الذي تريد امتلاكه فعلياً. وإذا كنت تفضّل مشاهدة شكل الاستخراج عملياً، فإن قناة Thunderbit على YouTube تشرح ذلك خطوة بخطوة.
الحكم النهائي
لا يوجد أفضل أداة استخراج بيانات مفتوحة المصدر بشكل مطلق، وأي قائمة تمنحك واحدة بثقة تخفي بهدوء السؤال الذي يحسم الأمر فعلاً: أي واحدة من المهام الثلاث تنفذ؟ حوّل صفحة إلى نص، أو اعرض JavaScript، أو ازحف بسرعة من دون متصفح — يتوزع المجال بوضوح إلى هذه الفئات، وداخل كل فئة يتحدد الاختيار بناءً على اللغة ووزن الإعداد، لا على بطل عالمي واحد.
إذا أخذت عادة واحدة من كل هذا، فلتكن هذه: اختبر على صفحاتك أنت قبل أن تلتزم بأي شيء. كل رقم هنا قابل لإعادة الإنتاج في مستودع القياس لهذا السبب تحديداً — لأن الأداة التي تتصدر قائمة عامة ليست دائماً هي نفسها التي تنجو مع أهدافك الحقيقية.
جرّب Thunderbit لاستخراج بيانات الويب Get Started Free
الأسئلة الشائعة
ما أفضل أداة مفتوحة المصدر لاستخراج بيانات الويب؟ لا توجد أداة واحدة تناسب كل الحالات — فذلك يعتمد على المهمة. للنص الجاهز لنماذج LLM، trafilatura أو Crawl4AI؛ ولعرض JavaScript، Playwright أو Puppeteer أو Crawlee؛ وللزحف السريع عبر HTTP، Scrapy أو Colly. على منصة اختبار مشتركة، كانت كل أداة أقوى داخل فئتها وأضعف بوضوح خارجها، ولهذا فإن التصنيفات العامة الموحّدة مضللة.
أي أدوات الاستخراج المفتوحة المصدر تعرض JavaScript؟ Crawl4AI وFirecrawl وPlaywright وPuppeteer ومحرك Playwright في Crawlee كلها تعرض JavaScript. أما Scrapy وColly وtrafilatura وجالب HTTP الافتراضي في Scrapling فلا تفعل ذلك — إما أنها تحتاج إلى API يمكن إعادة تنفيذه خلف الصفحة (وهو نهج Scrapy الذي حصل على 8/8 من نقطة JSON النهاية) أو إلى وضع متصفح منفصل.
هل أحتاج إلى متصفح headless لاستخراج موقع؟ فقط إذا كانت البيانات تظهر بعد تشغيل JavaScript. إذا كان طلب HTTP عادي مع محلل قادرين على الوصول إلى المحتوى، فالمتصفح يكون تبذيراً مكلفاً؛ Scrapy أو Colly أو Scrapling ستكون أخف وأسرع بكثير في هذه الحالة.
أي هذه الأدوات تملك ترخيصاً أكثر ملاءمة للاستخدام التجاري؟ معظمها مرن: Apache-2.0 (Crawl4AI وCrawlee وPlaywright وPuppeteer وColly) أو BSD-3-Clause (Scrapy وScrapling). الاستثناء هو النواة المستضافة ذاتياً في Firecrawl، والتي تأتي تحت AGPL-3.0 وتستحق مراجعة ترخيص حقيقية قبل بناء منتج تجاري عليها.
هل أرقام هذا الاختبار قابلة لإعادة الإنتاج؟ نعم. كل runner وكل fixture وكل نتيجة خام موجودة في مستودع عام برخصة MIT. لكن هناك ملاحظة واحدة مهمة: الاسترجاع والنتائج البنيوية قابلة للمقارنة بين الأدوات، أما أعداد الأحرف المطلقة فهي مؤشرات داخل كل أداة فقط، لأن كل حزمة تعكس عيناتها الخاصة بدلاً من مشاركة نسخة معيارية واحدة — لذا قارن النسب ونتائج النجاح/الفشل، لا إجمالي الأحرف الخام.
