يلتقي معظم الناس بـ Crawlee وهم يحاولون يجاوبوا على سؤال مختلف: «أي متصفح بدون واجهة لازم أستخدم؟». لكن هذا هو السؤال الغلط، وCrawlee هو السبب. لأنه أصلًا مو متصفح، بل إطار عمل لـ Node/TypeScript يلفّ على المتصفح وقت تحتاجه، ويتخطاه وقت ما تكون ما تحتاجه.
قضيت يومين أختبر Crawlee 3.17.0 على مجموعة مضبوطة من الملفات التجريبية وبعض مواقع العرض العامة، باستخدام Node v22.22.3 وmacOS. الفكرة الأساسية — مكتبة واحدة، وواجهة واحدة، مع وجود زاحف HTTP أو متصفح حقيقي في الخلفية — كانت أكثر شيء حبيت أختبره تحت الضغط، لأنها الفكرة اللي تحدد إذا كان Crawlee يستاهل تضيفه إلى منظومتك أو الأفضل تروح مباشرة إلى Playwright. الخلاصة السريعة: قصة «محركين» صامدة فعلًا، مع كم ملاحظة برجع لها لاحقًا.
ما هو Crawlee فعلًا، وما ليس كذلك
يعرّف Crawlee نفسه كـ مكتبة لأتمتة المتصفح و استخراج بيانات الويب داخل Node.js، ومصممة لبناء زواحف موثوقة. والتموضع الرسمي واسع جدًا: استخراج البيانات لتطبيقات الذكاء الاصطناعي وLLMs وRAG أو GPTs؛ تنزيل ملفات HTML وPDF وJPG وPNG وغيرها؛ دعم Puppeteer وPlaywright وCheerio وJSDOM وHTTP الخام؛ تشغيل بواجهة أو بدونها؛ مع تدوير البروكسي مدمجًا. هذه مساحة كبيرة، لذلك من المفيد أيضًا نوضح وش اللي مو Crawlee.
هو مو محرك عرض. وما عنده متصفح خاص فيه. لما تحتاج تنفيذ JavaScript، Crawlee يشغّل Playwright أو Puppeteer، وهذولا بدورهم يشغّلون Chromium أو متصفح ثاني. وهو بعد مو خدمة مستضافة تستدعيها عبر الشبكة — هو اعتماد تثبّته وتديره بنفسك. طيب Crawlee وش هو بالضبط؟ هو الطبقة اللي فوق أداة الجلب: فئات الزحف، قائمة الطلبات، التخزين، ومنطق تتبّع الروابط. فكّر فيه كإطار عمل للزحف، مع فتحة قابلة للتبديل للمحرك اللي تحت.
وللتوضيح، النسخة اللي اختبرتها كانت 3.17.0 (صدرت في 2026-06-04)، ومكتوبة بـ TypeScript، ورخصتها Apache-2.0، وكان المستودع عنده حوالي 24.6 ألف نجمة بتاريخ 2026-07-09 على apify/crawlee. أرقام النجوم تتغير باستمرار — المستودع أخذ 53 نجمة خلال اليومين اللي كنت أراقبه فيهما — فتعامل مع الرقم كصورة لحظة معيّنة، مو كحقيقة ثابتة.
المحركان: CheerioCrawler مقابل PlaywrightCrawler
هنا يبان تصميمه الحقيقي، وهنا قضيت أغلب وقتي.
CheerioCrawler هو المسار المعتمد على HTTP. يجلب HTML الخام عبر الشبكة ثم يحلله باستخدام Cheerio — بلا متصفح، بلا تنفيذ JavaScript، بلا عرض مرئي. إنه سريع ورخيص. أما PlaywrightCrawler فهو المسار المعتمد على المتصفح. يفتح Chromium حقيقي، ويرسم الصفحة بما فيها أي JavaScript يبني DOM، ويقدر بعد يلتقط لقطات شاشة.
محركان مختلفان تمامًا بقدرات مختلفة فعلًا. النقطة اللي يطرحها Crawlee هي إنهم يلبسون نفس الثوب. كلاهما يقبل requestHandler. وكلاهما يوفر run(). وكلاهما يزحف عبر الروابط باستخدام enqueueLinks. والانتقال من محرك لآخر يعني تبديل فئة، مو إعادة كتابة — وقد تأكدت من هذا بأني خليت منطق الاستخراج نفسه حرفيًا، وغيرت فئة الزاحف فقط.
في نقطة لازم تنقال بدقة، لأنها الخط الفاصل اللي عنده تنتهي المساواة: طريقة الوصول للمحتوى تختلف. داخل معالج CheerioCrawler تحصل على $ — DOM ثابت ومحلل مسبقًا، تستعلم عنه مثل jQuery. أما داخل معالج المتصفح فتحصل على كائن page حي. يعني تظل قائمة الانتظار، والتوجيه، ومنطق «ادفع هذه البيانات واتبع تلك الروابط» كما هو، لكن السطر اللي تقرأ منه الصفحة فعليًا يختلف شكله. وثائق Crawlee نفسها تقول هذا؛ فهي تحدد الواجهة المشتركة في الزحف، وتعتبر الوصول إلى المحتوى هو الجزء المتغير.
| المحرك | طريقة الجلب | هل ينفّذ JavaScript؟ | نتيجتي (صفحة ديناميكية واحدة) | الأنسب لـ |
|---|---|---|---|---|
CheerioCrawler | HTTP خام + تحليل عبر Cheerio | لا | حوالي 0.035 ثانية | HTML ثابت، واجهات JSON، السرعة |
PlaywrightCrawler | Chromium حقيقي عبر Playwright | نعم | حوالي 4.967 ثانية | الصفحات المعتمدة على JavaScript، لقطات الشاشة |
هذه الأرقام جاية من جهاز واحد وتشغيل واحد — مو اختبار أداء، بل مجرد توضيح لشكل المقايضة. مسار المتصفح كلّف تقريبًا فرق رتبتين من الزمن على نفس الرابط. هذا هو ثمن العرض، لذلك ما تلجأ له تلقائيًا.
الاختبار: نفس الرابط، 0 مقابل 8/8
الوعود سهلة. سبب ثقتي بقصة المحركين هو إني قدرت أكسرها وبعدين أصلحها بمجرد تبديل فئة واحدة.
أنشأت ملفًا تجريبيًا محليًا ديناميكيًا — صفحة كتالوج تنحقن بطاقاتها بواسطة JavaScript بعد التحميل، وهو النوع اللي صار الشكل الافتراضي للويب الحديث. وجهت CheerioCrawler له. النتيجة كانت 0 بطاقات منتجات. هذا مو خطأ؛ بل نتيجة طبيعية. Cheerio ما شغّل JavaScript أصلًا، لذلك البطاقات ما كانت موجودة في HTML اللي تم تحليله. بعدين وجهت PlaywrightCrawler لنفس الرابط تمامًا، بدون ما أغير أي شيء ثاني، فقام بعرض 8 من 8 منتجات والتقاط صورة شاشة تثبت ذلك.
وللتأكد إن الموضوع مو مجرد خاصية غريبة في ملفي التجريبي، كررت نفس النمط على موقع عام — صفحة العرض التوضيحي Quotes to Scrape المعتمدة على JavaScript، والتي تبني الاقتباسات من جهة العميل. وكانت النتيجة نفسها بنفس الاتجاه: CheerioCrawler شاف 0 اقتباسات، بينما PlaywrightCrawler استعاد 10.
أبي أكون دقيق بخصوص وش يثبته هذا. هو إعادة إنتاج واضحة لادعاء يذكره Crawlee مسبقًا — فالإطار يشترك في نفس الفئة الأساسية ونفس الواجهة بين أنواع الزواحف منذ الإصدار 3.0. يعني هذا تحقق، مو اكتشاف. لكن هذه بالضبط هي القيمة: عبارة «واجهة واحدة، HTTP أو متصفح» مو مجرد تسويق، وهذا الدليل يبين الانتقال من 0 إلى البيانات الكاملة على ملف أتحكم فيه وعلى موقع ما أتحكم فيه.
أين يتفوق مسار HTTP
ممكن اللي سبق يخليك تقول: «طيب استخدم المتصفح دائمًا». لا تسويها. السبب كله وراء أهمية التصميم ثنائي المحرك هو أن المتصفح هو الخيار الاحتياطي المكلف، مو الإعداد الافتراضي.
في المحتوى الثابت، كان CheerioCrawler دقيقًا وسريعًا. ملف الكتالوج الثابت رجّع 12 من 12 منتج بدقة كاملة، مع تتبّع الترقيم عبر enqueueLinks({ selector: '.next-page' })، وذلك في حوالي 0.155 ثانية. أما صفحة مقال فقد قدّمت العنوان وجميع فقراتها 3 من 3، مع فصل واضح بين المحتوى وبين العبارات الجاهزة مثل تسجيل الدخول والاشتراك وحقوق النشر.
وأهم نقطة لازم تثبت هنا: الصفحة اللي تُحمّل بياناتها عبر JavaScript غالبًا خلفها API بصيغة JSON مباشرة. بيانات ملفي الديناميكي كانت موجودة على نقطة نهاية، ولما وجهت CheerioCrawler مباشرة إلى تلك الـ API استعاد 8 من 8 منتجات — بلا متصفح، وفي حوالي 0.035 ثانية. نفس البيانات اللي احتاج مسار المتصفح تقريبًا خمس ثواني عشان يعرضها. والدرس قديم لكنه ما زال صحيح: إذا قدرت تعيد بناء الطلب الأساسي، فسوّها بدل ما تشغل Chromium. وCrawlee يخليك تتخذ هذا القرار لكل زاحف على حدة من غير ما تغير إطار العمل.
جزء إطار الزحف في Crawlee (السبب الحقيقي لاختياره بدل مكتبة متصفح فقط)
لو كنت تحتاج فقط عرض صفحة واحدة، ما كنت تحتاج Crawlee — كنت بتستخدم Playwright أو Puppeteer لحاله. اللي ما تعطيك إياه مكتبة متصفح خام هو الزحف: قائمة انتظار، إزالة التكرار، التحكم في العمق، وإعادة المحاولة. هذا هو الجزء في Crawlee اللي ما يتعلق بالمحركات أصلًا.
نفذت زحفًا داخل نفس المضيف من جذر ملف تجريبي باستخدام enqueueLinks مع تتبّع العمق. قام Crawlee بزيارة 11 صفحة موزعة على الأعماق {0:1, 1:3, 2:7} — صفحة جذر واحدة، وثلاث صفحات على بعد نقرة، وسبع صفحات على بعد نقرتين — وطبّق maxRequestsPerCrawl كشرط إيقاف. تولى RequestQueue أعمال التسجيل والمتابعة. ولما وجهت طلبًا إلى صفحة تعيد HTTP 500، أعاد Crawlee المحاولة ثم مرّر الفشل عبر failedRequestHandler بدل ما يبلعه بصمت أو يطيح التشغيل.
هذه أقوى حجة لصالح Crawlee مقارنة بأداة متصفح مستقلة: تنسيق الزحف مدمج فيه، والأهم أنه نفسه سواء كان المحرك في الأسفل HTTP أو متصفح. تكتب منطق قائمة الانتظار وتتبع الروابط مرة واحدة. بعدين تقرر بشكل منفصل إذا كان كل زاحف سيعرض JavaScript أو لا.
التثبيت وتنزيل المتصفح المخفي
كان التثبيت في الغالب سلس، مع فخ واحد ممكن يورط المستخدم لأول مرة.
npm install crawlee playwright تم بنجاح — من دون أي ثغرات مذكورة. لكن PlaywrightCrawler لن يشتغل قبل ما تشغّل أيضًا npx playwright install chromium، وهذا يحمل نسخة Chromium بحجم يقارب 81.7 ميغابايت. تثبيت حزمة crawlee وحده ما يجيب متصفح. وإذا تخطيت هذه الخطوة ورحت مباشرة إلى زاحف المتصفح، بتواجه خطأ تشغيل قد ما يكون واضح إذا ما كنت تعرف نموذج تغليف Playwright مسبقًا. هذا سلوك موروث من Playwright، مو عيب في Crawlee، لكنه احتكاك حقيقي في أول تشغيل يستاهل التنبيه.
وملاحظة تشغيلية ثانية: Crawlee يكتب افتراضيًا إلى مجلد محلي باسم storage/. اختباري وجّه هذا التخزين إلى مجلد مؤقت معطّل الحفظ للحفاظ على النظافة، لكن التشغيل العادي بيترك مجلد storage/ داخل مشروعك. مو مشكلة، بس شيء لازم تعرفه قبل ما تشوفه في git status.
المحرك الثالث، باختصار
قصة التماثل في Crawlee ما توقف عند Cheerio وPlaywright. فيه أيضًا PuppeteerCrawler، وتحققت إلى أي مدى تمتد فكرة «نفس الواجهة» إليه — على مستوى الفئة وواجهة الـ API، لا عبر زحف حي.
كل الفئات الثلاث ترجع إلى الفئة الأساسية نفسها BasicCrawler. CheerioCrawler يمر عبر HttpCrawler، بينما PlaywrightCrawler وPuppeteerCrawler يمران عبر BrowserCrawler مشترك. وعند فحص الحزمة المثبتة، وجدت 24 طريقة عامة مشتركة بين المحركات الثلاثة، بما في ذلك عمليات قائمة الانتظار والتخزين اللي يقوم عليها التصميم كله — run, addRequests, pushData, getData, getDataset, exportData, getRequestQueue, useState, stop. كما أن PuppeteerCrawler وPlaywrightCrawler يعرضان فعليًا مجموعة طرق عامة متطابقة. الفروقات الوحيدة بين المحركات تظهر عند الحد الفاصل بين HTTP والمتصفح، وهذا بالضبط المكان المتوقع لها.
والحد اللي لازم ينقال بوضوح: ما شغّلت زحف حي عبر PuppeteerCrawler. اعتماد puppeteer الإضافي اختياري وما كان مثبتًا في حزمة الاختبار، وتشغيله كان يعني أيضًا تنزيل متصفح آخر. لذلك تم التحقق هنا من تكافؤ Puppeteer بنيويًا — نفس الفئة الأساسية، نفس الطرق المشتركة، نفس شكل سياق المعالج — لا عبر تشغيل فعلي. وحتى لما تتطابق الواجهة، السلوك الداخلي مو متطابق تمامًا: إرشادات Crawlee نفسها تشير إلى أن Playwright ينتظر العناصر تلقائيًا، بينما يطلب منك Puppeteer تنتظر صراحةً. هذه سمة في المحرك، مو في Crawlee، لكنها تعني أن «نفس الـ API» مو معناها «نفس الكود داخل كل معالج».
ما الذي لم أختبره
هذا اللي خليته عمدًا خارج النطاق، عشان ما تنقرأ نتائجي على أنها أوسع مما هي عليه.
- النطاق الكبير. كل شيء جرى على ملفات تجريبية صغيرة وزحوف عامة قصيرة. ما سويت تشغيل طويل من 100 إلى 1000 صفحة، لذلك ما أقدر أحكم على التحجيم التلقائي أو الاستقرار تحت أحمال حقيقية.
- استمرارية قائمة الانتظار والاستئناف. ما وقفت زحف في منتصفه عشان أشوف إذا كانت
RequestQueueبتستأنف بسلاسة بعد تعطل. هذه قدرة أساسية للمهام الطويلة، وما اختبرتها هنا. - تصدير Dataset وKeyValueStore. كتبت تصدير JSON/CSV يدويًا داخل بيئة الاختبار. ما اختبرت سهولة التصدير المدمجة في
DatasetوKeyValueStore، وهي ربما من أهم مزايا استخدام الإطار. - تجمعات البروكسي والجلسات. Crawlee يجي بميزات تدوير البروكسي والبصمة الرقمية. أتعامل معها هنا بوصفها موضوع امتثال وتشغيل، لا كوسيلة لتجاوز الحظر، وما خضعتها لاختبار ضغط بأي اتجاه.
وكمان الأوقات المذكورة طوال المقال جاية من جهاز واحد وتشغيل واحد. هي توضح شكل تكلفة HTTP مقابل المتصفح، وليست اختبارات أداء، وما راح أقتبسها على أنها كذلك.
الإيجابيات والسلبيات
الإيجابيات
- واجهة واحدة بين الزحف عبر HTTP والمتصفح — تبديل المحرك فعلًا مجرد تغيير فئة، وهذا تأكد من 0 إلى البيانات الكاملة على ملف محلي وعلى موقع عام.
- إطار زحف حقيقي:
RequestQueueوenqueueLinksمع التحكم في العمق، وإعادة المحاولة، وfailedRequestHandler، وليس مجرد عارض صفحات. - استخراج دقيق عبر HTTP عندما لا يكون JavaScript عائقًا: 12/12 في المحتوى الثابت، 3/3 في فقرات المقال، و8/8 عبر JSON API.
- مسار المتصفح يستعيد المحتوى الذي لا يمكن لـ HTTP رؤيته فعليًا، ويمكنه التقاط لقطات شاشة.
- رخصة Apache-2.0، وTypeScript، وصيانة نشطة.
السلبيات
- يحتاج زاحف المتصفح إلى
npx playwright install chromiumمنفصل (~81.7 ميغابايت)، وهو شيءnpm install crawleeما يعالجه — سهل تنساه. - عرض المتصفح يفرض تكلفة حقيقية على كل صفحة (~5 ثوانٍ مقابل أقل من ثانية في اختباري لصفحة واحدة).
- التشغيل العادي يترك مجلد
storage/كأثر جانبي افتراضي. - ما أثبت في اختباري النطاق الكبير، أو الاستئناف بعد التعطل، أو سهولة التصدير المدمج.
- لازم استخدام ميزات البروكسي والبصمة ضمن شروط الموقع والقانون — مسؤولية تشغيلية، مو ميزة تعتمد عليها بشكل أعمى.
متى تختار Crawlee ومتى تختار API مُدارة
Crawlee أداة تبنيها بنفسك، وهذا القرار مناسب جدًا لكثير من الفرق. اختره لما تبغى تملك الزاحف داخل قاعدة كود Node الخاصة بك، وتدمج الزحف عبر HTTP والمتصفح في مشروع واحد من غير تبديل الأطر، وتتحكم بنفسك في قائمة الانتظار والتخزين. إذا كنت مرتاح لتشغيل أسطول متصفحات ثم توسيعه لاحقًا، فـ Crawlee يعطيك هيكل نظيف ومحكم التصميم تبني عليه.
أما المسار الثاني فهو ألا تدير أي جزء من هذه البنية التحتية. إذا ما كنت تبغى تتعامل مع حالات Chromium، وتدوير البروكسي، ومعالجة الحظر، فهناك بديل هو API مُدارة — وهنا يجي دور حزمة المطورين الخاصة بنا في Thunderbit. للمستخدمين التقنيين، Thunderbit مو إضافة Chrome؛ بل هو API لاستخراج البيانات بالذكاء الاصطناعي، وMCP server، وCLI. تقدر تستدعي POST /distill لتحويل الصفحة إلى Markdown نظيف جاهز لـ LLM، أو POST /extract مع JSON Schema للحصول على بيانات منظمة، مع renderMode بقيم none أو basic أو full عشان تقرر متى يستحق الأمر عرض متصفح كامل. يتيح MCP server لوكيل ذكاء اصطناعي — مثل Claude أو Cursor أو غيرهم من عملاء MCP — ينفذ الاستخراج أثناء المهمة، بينما تعمل أداة CLI من الطرفية أو CI:
جرّب Thunderbit لاستخراج بيانات الويب
npx -y @thunderbit/thunderbit-cli distill "<url>" -f markdown > out.md
الفرق المهم للمطورين: Crawlee يعطيك المادة الخام — HTML معروض وعُقد محللة — وأنت تمتلك خط المعالجة؛ أما الـ API المُدارة فترجع JSON منظم مطابق للمخطط، مع معالجة العرض وCAPTCHA ومكافحة الحظر على الخادم. وظيفتان مختلفتان. إذا كنت تبغى أقصى قدر من التحكم وما تمانع العبء التشغيلي، فاختر Crawlee. وإذا كنت تبغى البيانات من غير إدارة أسطول متصفحات، فالطريق المُدار هو الأنسب. كثير من الفرق تنتهي باستخدام الاثنين معًا: واحد للزحوف المخصصة، وآخر لحالات «أعطني البيانات المنظمة فقط». وتقدر تشوف فارق التكلفة في تسعير Thunderbit.
الحكم النهائي
هل لازم تستخدم Crawlee؟ نعم — إذا كنت مطور Node أو TypeScript وتبغى إطارًا واحدًا يغطي الزحف عبر HTTP والمتصفح مع قائمة زحف حقيقية في الأسفل. وعد المحركين هو سبب اختياره، وقد أثبت نفسه بوضوح في اختباري: نفس الرابط انتقل من 0 إلى البيانات الكاملة بمجرد تبديل فئة واحدة، والاستخراج الثابت كان دقيقًا وسريعًا، والزحف بالقائمة والعمق اشتغل مثل ما هو موثق.
لكن ادخل وأنت متذكر شيئين. خصص ميزانية لتنزيل المتصفح المخفي عند أول استخدام لـ PlaywrightCrawler، ولا تفترض أن الأجزاء اللي ما اختبرتها — مثل النطاق الكبير، والاستئناف بعد التعطل، والتصدير المدمج — راح تشتغل بنفس جودة الأجزاء اللي اختبرتها قبل ما تشغلها على عبء العمل الحقيقي عندك. كأساس تبني عليه زاحفك الخاص، Crawlee قطعة هندسية قوية ومحكمة. أما كخط بيانات نهائي جاهز بدون تدخل، فهو نقطة بداية لا محطة وصول.
جرّب Thunderbit لاستخراج بيانات الويب Get Started Free
الأسئلة الشائعة
هل Crawlee مجاني، وما هي رخصته؟
نعم. Crawlee مشروع مفتوح المصدر برخصة Apache-2.0، ويمكن تثبيته عبر npm (npm install crawlee). النسخة اللي اختبرتها كانت 3.17.0. تشغيل زواحف المتصفح يتطلب تنزيل Chromium منفصل عبر Playwright، وهو أيضًا مجاني لكن يضيف حوالي 81.7 ميغابايت إلى إعدادك.
CheerioCrawler أم PlaywrightCrawler — أيهما أستخدم؟
استخدم CheerioCrawler عندما تكون البيانات موجودة في HTML الخام أو في JSON API أساسي — فهو أسرع بكثير وما يشغّل متصفح أبدًا. استخدم PlaywrightCrawler عندما يكون المحتوى معروضًا بواسطة JavaScript، وتقدر تلاحظ هذا عندما يرجّع مسار HTTP نتائج فارغة. في اختباري رجّع محرك HTTP صفر عنصر على صفحة معروضة بـ JavaScript، بينما رجّع محرك المتصفح كل شيء. وبما أنهما يشتركان في نفس الـ API، فالتبديل مجرد تغيير فئة، مو إعادة كتابة.
هل يحتاج Crawlee إلى متصفح ليعمل؟
فقط لزواحف المتصفح. CheerioCrawler ما يحتاج أي متصفح. أما PlaywrightCrawler وPuppeteerCrawler فيحتاجان إلى ملف متصفح ثنائي — ثبّته عبر npx playwright install chromium. انتبه إن npm install crawlee وحده ما يجيب متصفح، وهذه أكثر مفاجأة شائعة في أول تشغيل.
هل يستطيع Crawlee التعامل مع الترقيم والزحف عبر صفحات متعددة؟
نعم، وهذا واحد من الأسباب الجوهرية لاختياره بدل مكتبة متصفح مستقلة. enqueueLinks يتابع الروابط (بما في ذلك محددات الترقيم مثل .next-page)، وRequestQueue يمنع التكرار ويدير الزحف، ومعه تحصل على التحكم في العمق وحدود maxRequestsPerCrawl. في الاختبار، زحف على نفس المضيف عبر 11 صفحة من العمق 0 إلى 2، وكانت الطلبات الفاشلة تظهر عبر failedRequestHandler.
كيف يقارن Crawlee مع API لاستخراج البيانات مستضافة؟
Crawlee يشتغل على خادمك أنت: أنت تكتب الزاحف وتشغله، وأنت تتحمل مسؤولية التوسّع والبروكسي ومعالجة الحظر. أما API مُدارة مثل نقاط Thunderbit distill وextract فترجع Markdown نظيف أو JSON منظم مطابق للمخطط، مع معالجة العرض ومكافحة الحظر على الخادم، ومتاحة عبر API وMCP server وCLI. اختر Crawlee لما تبغى أقصى سيطرة على خطك الخاص؛ واختر API مُدارة لما ما تبغى تدير بنية المتصفح وتوسيعها بنفسك.
