تبدأ معظم المقالات التي تقارن بين "Playwright وPuppeteer" من افتراض أن أحدهما لا بد أن يكون أفضل أداة للاستخراج. لكن هذا التصور يحمّل المقارنة أكثر مما تحتمل. لقد وضعت المكتبتين أمام المجموعة نفسها تمامًا من الصفحات — كتالوج ثابت، وكاتالوج معروض عبر JavaScript، ومقال، وخطأ 500، وبيان زحف صغير، وموقعين عامّين للتدريب — وكانت النتائج متطابقة تقريبًا. نفس نسبة الاسترجاع، نفس العرض، نفس لقطات الشاشة، ونفس الثغرات.
إذًا فهذه ليست تتويجًا لأحدهما. في المهام التي تحدد فعلًا ما إذا كانت أداة أتمتة المتصفح قادرة على استخراج الصفحة أم لا، لم يتقدّم أيٌّ منهما على الآخر. ما يلي هو الفرق الحقيقي الوحيد الذي ينبغي أن يوجّه اختيارك، والشيء الذي يتركه الاثنان لك لتبنيه بنفسك، مع ملاحظة عن فجوة الإصدارات التي اختبرتها (حتى تاريخ 2026-07-09).
لماذا المقارنة عادلة أصلًا
المقالات المقارنة ترتكب خطأً متكررًا: تختبر كل أداة على صفحات مختلفة ثم تعلن فائزًا — وهذا يخبرك أكثر عن الصفحات من الأدوات نفسها. تجنبت هذا الخطأ بتشغيل Playwright وPuppeteer على نفس خادم الاختبارات المحلي وعلى نفس العرضين العامين، Books to Scrape وQuotes to Scrape، بحيث تصطف كل الأرقام جنبًا إلى جنب.
هذه هي الطريقة الوحيدة التي تجعل ادعاء "التعادل" ذا معنى. إذا اختلفت العينات، فالتعادل مجرد ضجيج. أما عندما تكون الصفحات متطابقة حرفيًا، فالنتائج المتشابهة تصبح إشارة حقيقية إلى الأدوات نفسها.
ما هي كل أداة فعلًا
Puppeteer هي واجهة JavaScript للتحكم في Chrome عبر Chrome DevTools Protocol. ووصفها الرسمي يقول ذلك بوضوح: "واجهة JavaScript للتحكم في Chrome (ومع دعم تجريبي لـ Firefox)." وهي ناضجة، ومتمحورة حول Chrome، ومبنية على Node.
أما Playwright فتقدّم نفسها بصورة مختلفة — "إطار عمل لاختبار الويب والأتمتة" يشغّل Chromium وFirefox وWebKit عبر واجهة واحدة، مع عملاء رسميين في JavaScript وPython وJava و.NET. والأداتان بينهما صلة قرابة واضحة (Playwright خرجت من الفريق نفسه الذي بنى Puppeteer في Google قبل انتقاله إلى Microsoft)، ولهذا تشعر وكأنهما ابنتا عم أكثر من كونهما خصمين.
لكن من ناحية الاستخراج، تتصرفان بالطريقة نفسها. شغّل متصفحًا حقيقيًا، افتح الصفحة، دع السكربتات تعمل، ثم اقرأ DOM بعد العرض. هذه هي بالضبط السبب الذي يدفعك لاختيار أي منهما بدلًا من محلّل HTTP: أنت تريد الصفحة بعد تنفيذ JavaScript، لا الغلاف الفارغ قبل ذلك. وكل ما يأتي لاحقًا ينبع من هذه الآلية المشتركة — ولهذا كثير مما يفعلانه ينتهي إلى نتيجة متعادلة.
النتائج جنبًا إلى جنب
هنا تنهار بهدوء قصة "أحدهما أفضل بوضوح". نفس العينات، نفس الأرقام، في كل بند.
| الاختبار | Playwright | Puppeteer |
|---|---|---|
| كتالوج ثابت (12 منتجًا) | 12/12، الاسترجاع 1.0 | 12/12، الاسترجاع 1.0 |
| مقال (عنوان + 3 فقرات) | 3/3، فصل العناصر العامة | 3/3، فصل العناصر العامة |
| صفحة ديناميكية JS (عرض أصلي) | 8/8 + لقطة شاشة | 8/8 + لقطة شاشة |
| واجهة JSON الديناميكية | 8/8، الاسترجاع 1.0 | 8/8، الاسترجاع 1.0 |
| التعامل مع HTTP 500 | يمكن فحصه، دون رمي خطأ | يمكن فحصه، دون رمي خطأ |
| بيان الزحف (BFS مكتوب يدويًا) | 12 صفحة، الأعماق {0,1,2} | 12 صفحة، الأعماق {0,1,2} |
| Books to Scrape | 20 منتجًا | 20 منتجًا |
| Quotes JS (عام) | 10 اقتباسات | 10 اقتباسات |
كلاهما عرض JavaScript محليًا من دون أي إعدادات خاصة. وكلاهما التقط لقطات شاشة للصفحة كاملة. وكلاهما تعامل مع خطأ 500 بإرجاع كائن استجابة يمكن فحصه بدلًا من رمي استثناء — وهي نقطة صغيرة لكنها مهمة عندما تعمل على نطاق واسع وتريد تسجيل الحالة السيئة بدلًا من انهيار التشغيل.
وسأكرر تنبيهًا مهمًا لأنه سهل الإساءة فهمه: هذه ملاحظات من تشغيل واحد وعلى جهاز واحد، وليست اختبارات أداء معيارية. أنا لا أزعم أن أحدهما أسرع من الآخر ببضع ميلي ثوانٍ، لأن مؤقتًا على صفحة واحدة في جهاز محمول لا يساوي اختبار سرعة حقيقيًا. ما أزعمُه أضيق وأقوى دعمًا: في دقة الاستخراج وسلوك العرض، وعبر ثمانية أنواع مختلفة من الصفحات، كانت النتائج متطابقة. إذا كنت تأمل أن يفلت أحدهما من الآخر على صفحة حقيقية، فلم يحدث ذلك.
الفرق الحقيقي الذي يجب أن يحسم القرار
الانقسام الحقيقي ليس في الأرقام. بل في النطاق.
Playwright يدعم ثلاثة محركات — Chromium وFirefox وWebKit — عبر واجهة واحدة، ويقدّم عملاء جاهزين من الدرجة الأولى في Python وJava و.NET إلى جانب JavaScript. وهذه ميزة موثقة، وأريد أن أكون دقيقًا في كلمة "موثقة": أنا لم أختبر في هذه الجولة سوى Chromium، لذا فإنني أذكر دعم Playwright للمحركات الثلاثة بوصفه قدرة معلنة لم أتحقق منها بنفسي، لا شيئًا اختبرته مباشرة. إذا كنت تحتاج إلى استخراج موقع يعرض بشكل مختلف تحت WebKit في Safari، أو كان فريقك يكتب بـPython، فهذه السعة هي حجة Playwright.
أما Puppeteer فهو متمحور حول Chrome أولًا، وهنا يخطئ التلخيص الشائع. عبارة "خاص بـChrome فقط" لم تعد دقيقة. فمنذ Puppeteer v23 أصبح يدعم Firefox بدرجة إنتاجية عبر WebDriver BiDi، مع الاستمرار في استخدام CDP مع Chrome للحفاظ على الأتمتة الحالية كما هي — وهو تحول وثّقه كل من Chrome for Developers وMozilla. والإصدار الذي اختبرته (24.16.0) يتجاوز v23 بوضوح، لذا فالمقارنة الحقيقية ليست "Chrome مقابل ثلاثة محركات". بل هي: Puppeteer يغطي Chrome (عبر CDP) وFirefox (عبر BiDi) لكنه لا يغطي WebKit، كما أن قصة تعدد المحركات لديه أحدث سنًا من Playwright. والمحرك الذي لدى Playwright ولا يملكه Puppeteer هو WebKit.
هذا هو القرار مختصرًا. ليس السرعة، ولا الدقة، ولا وفاء العرض — فهذه متعادلة. إنها مسألة نطاق: هل تحتاج تغطية WebKit أو عملاء بلغات غير JavaScript، أم أن Chrome وFirefox من Node يكفيان لأهدافك؟ في نسبة كبيرة من مهام الاستخراج، أي من الأداتين يفي بالغرض، ويصبح الاختيار هنا مبنيًا على ملاءمة البنية التقنية لا على القدرة.
ما لا تفعله أي منهما
كلتا الأداتين تتركان نفس المهمة على مكتبك: تنظيم الزحف. لا واحدة منهما تأتي بقائمة طلبات مدمجة، ولا كاتب بيانات، ولا ضبط تلقائي للسرعة. اختبار بيان الزحف الذي أجريته — تتبع الروابط الداخلية، وحفظ العمق، وعدم إعادة زيارة الرابط نفسه — احتاج إلى خوارزمية بحث بعرض الصفحة مكتوبة يدويًا في الحالتين. 12 صفحة، الأعماق {0,1,2}، وBFS من كتابتي، في المرتين.
هذا مناسب تمامًا عندما تكون الصفحات قليلة؛ فـBFS صغير لا يحتاج أكثر من عشرة أو اثني عشر سطرًا. لكن عند الزحف على نطاق واسع — مئات أو آلاف الروابط مع منع التكرار وإعادة المحاولة وتأخيرات اللباقة — ستضطر إما إلى بناء هذه المنظومة بنفسك أو اللجوء إلى طبقة تغلف هذه المحركات. وCrawlee يفعل ذلك تحديدًا، إذ يوفّر طبقة زحف حقيقية فوق Playwright وPuppeteer معًا.
هذا ليس عيبًا، وأريد أن أوصفه بدقة: Playwright وPuppeteer إطاران لأتمتة المتصفح، وليس لإدارة الزحف. غياب قائمة الانتظار ليس خطأً، بل حدًّا للنطاق. والنموذج الذهني الصحيح هو أن هذه الأدوات تمثل نصف "رؤية الصفحة" من أداة الاستخراج. أما نصف "التجول في الموقع" فعليك أنت أن تحضره — إما بكتابته أو بتركيب طبقة غلاف توفره.
الإعداد وملاحظة اختلاف الإصدارات
التثبيت متقارب جدًا. أمر npm install يجلب المكتبة مع ملف المتصفح التنفيذي، وهذا هو الجزء الثقيل — Puppeteer يضمّن تنزيل Chrome تلقائيًا (وتثيبي كان نظيفًا، بلا ثغرات مبلّغ عنها)، بينما يستخدم Playwright الأمر npx playwright install بشكل منفصل لتنزيل نسخ المتصفح. لا التثبيت صعب في الحالتين، لكن احسب حسابًا لحجم التنزيل هنا وهناك؛ فثقل المتصفح وتكلفة الصفحة هما الضريبة الحقيقية التي تدفعها مقابل العرض، مقارنة بأداة تعتمد على HTTP فقط.
والآن الإفصاح الذي أَدِينُك به. لقد اختبرت Playwright 1.56.0 مقابل أحدث إصدار 1.61.1، وPuppeteer 24.16.0 مقابل أحدث نسخة على npm وهي 25.3.0 — أي أن Puppeteer كان متأخرًا إصدارًا رئيسيًا كاملًا، وكل ذلك كما في 2026-07-09. الواجهات التي استخدمتها مستقرة عبر هذه الفجوات، لذا فالنتائج صالحة. لكن إذا كنت تقرأ هذا بعد فترة من النشر، فأعد الاختبار على الإصدارات الحالية قبل أن تبني أرقامك الدقيقة عليها. وأكرر مرة أخرى: لم أستخدم في Playwright سوى Chromium، لذا لا أزعم شيئًا عن تكافؤ Firefox أو WebKit إلا بقدر ما هو "موثّق".
Playwright وPuppeteer: الإيجابيات والسلبيات
بما أن النتيجة تعادل، تصبح قائمة المزايا والعيوب أقل علاقة بالفوز وأكثر علاقة بما الذي تقبل الالتزام به.
Playwright
- الإيجابيات: دعم موثّق لثلاثة محركات (Chromium وFirefox وWebKit) عبر واجهة واحدة؛ عملاء رسميون لـPython وJava و.NET؛ عرض JavaScript محلي بدقة كاملة؛ توسع نشط في الدعم.
- السلبيات: لا توجد قائمة زحف مدمجة؛ ثقل المتصفح وتكلفة الصفحة؛ اختبرت Chromium فقط؛ الإصدار الذي شغّلته كان متأخرًا عن أحدث نسخة.
Puppeteer
- الإيجابيات: أتمتة ناضجة ومستقرة لـChrome عبر CDP؛ عرض JavaScript محلي بدقة كاملة؛ التعامل مع HTTP 500 بسلاسة (كائن استجابة، بلا استثناء)؛ منظومة عميقة ومجرّبة؛ دعم موثّق لـFirefox عبر WebDriver BiDi منذ v23.
- السلبيات: متمحور حول Chrome وNode، من دون WebKit؛ لا توجد قائمة زحف مدمجة؛ ثقل المتصفح؛ الإصدار الذي شغّلته كان متأخرًا إصدارًا رئيسيًا كاملًا عن أحدث نسخة على npm.
من يختار ماذا
اختر Puppeteer إذا كنت تعمل داخل Node، وكانت مواقعك تعرض جيدًا في Chrome (وهذا ينطبق على معظمها)، وتريد مكتبة ناضجة ومركزة مع منظومة قوية ومحور تعقيد أقل. وخيار Firefox عبر BiDi متاح إذا احتجته لاحقًا.
اختر Playwright إذا كنت تحتاج WebKit، أو إذا أردت كتابة أداة الاستخراج بـPython أو .NET، أو إذا كنت تفضّل الرهان على المشروع الذي يملك سعة أوسع في المحركات واللغات. وملاءمة اللغة وحدها كثيرًا ما تكون السبب الأكثر وضوحًا لاختيار Playwright من قبل فريق Python.
وهناك جواب ثالث تتجاوزه المقالات المقارنة عادة: اختر أياً منهما إذا كانت صفحاتك لا تحتاج JavaScript أصلًا كي تكشف بياناتها. فإذا كان طلب HTTP مع محلّل كافيين للوصول إلى المحتوى، فالمتصفح الخفي هنا مبالغة مكلفة — فهذه فئة أدوات مختلفة، واستخدام متصفح حقيقي في هذه الحالة يعني هدر الذاكرة ووقت الإعداد بلا فائدة.
أين تقع واجهة مُدارة مثل Thunderbit
جرّب Thunderbit لاستخراج بيانات الويب
كلا Playwright وPuppeteer مكتبتان مفتوحتا المصدر ومجانيّتان تديرهما بنفسك. أنت المسؤول عن بيئة المتصفح، والتحديثات، وكود الزحف الذي تضيفه، وسباق التسلح مع الحماية من الروبوتات. وفي كثير من المشاريع، هذه الملكية الذاتية هي بالضبط الخيار الصحيح، ولا شيء هنا يدعو إلى عكس ذلك.
لكن انظر إلى مقدار العمل الفعلي في الاستخراج الذي يقع خارج هذه الأدوات. فهي تعرض الصفحة جيدًا؛ لكنها لا تصطفّف الروابط في قائمة انتظار، ولا تدير الحظر، ولا تعطيك JSON منظّمًا، ولا تُبقي أسطول المتصفحات يعمل بنفسها. هذه طبقة مختلفة من المكدس عن خدمة استخراج مُدارة، ومن المفيد أن نسمّيها بوضوح حين يفكّر المطوّر بين البناء والشراء. مجموعة المطورين الخاصة بنا في Thunderbit تقع في تلك الطبقة الأخرى: فالأمر POST /distill يحوّل الصفحة إلى Markdown نظيف جاهز للنماذج اللغوية، وPOST /extract يعيد JSON منظمًا وفق مخطط تحدده أنت، مع عرض JavaScript، ومعالجة الحماية من الروبوتات، وCAPTCHAs على الخادم بدلًا من جهازك. وهناك Thunderbit MCP server للوكلاء الذكيين ومساعدي البرمجة (حيث يعمل thunderbit_suggest_fields مجانًا قبل أن تدفع شيئًا)، وكذلك واجهة CLI عبر npx @thunderbit/thunderbit-cli للتشغيل في CI والمهام المجدولة.
ولن أدّعي أن هذا أفضل على الإطلاق — إنه مقايضة بشكل مختلف. مع Playwright أو Puppeteer أنت تملك العرض وكل ما تبنيه حوله، من دون كلفة لكل استدعاء. ومع واجهة مُدارة تنقل العرض، والحماية من الحظر، وبنية الزحف إلى الخارج، وتدفع مقابل كل طلب (وفي Thunderbit تُحاسَب حسب الاستدعاء — نقطة واحدة لـdistill وعشرون لـextract — لا حسب الصف). إذا كان مشروعك صغيرًا ومُستضافًا ذاتيًا، وتحب امتلاك المتصفح بنفسك، فهذه الأدوات مناسبة. أما إذا كنت تتوسع، ولا تريد تشغيل أسطول متصفحات بلا رأس مع طبقة زحف وطبقة تدوير للحظر، فالخيار المُدار يزيل هذه الفئة كاملة من العمل.
وفي المجال الأوسع، اختبر فريقنا أيضًا نهج Crawlee ثنائي المحرك ومجموعة من الأطر التي تعتمد HTTP أولًا على نفس العينات، وهذا هو التوقف المنطقي التالي إذا قررت أن المتصفح الكامل أكثر مما تحتاجه صفحاتك.
الخلاصة
هل تستخدم Playwright أم Puppeteer؟ بالنسبة لعرض صفحات JavaScript، أيٌّ منهما يصلح — لقد تعادلا في كل اختبار مهم هنا، لذا أنت لا تتنازل عن القدرة عندما تختار على أساس آخر. اختر Puppeteer إذا كان Chrome وFirefox من Node يلائمانك، وتريد نضجًا وتركيزًا. واختر Playwright إذا كنت تحتاج وصولًا إلى WebKit أو عملاء غير JavaScript.
وهناك نقطتان تتجاوزهما مقالات المقارنة غالبًا تستحقان أن تحتفظ بهما: أولًا، في مهام الاستخراج الحقيقية هاتان الأداتان متعادلتان فعلًا، فلا تُرهق نفسك بفجوة أداء لم تظهر في ثمانية اختبارات مختلفة. ثانيًا، لا واحدة منهما أداة زحف — هما تعرضان الصفحة، أما الزحف فهو عليك أو على غلاف مثل Crawlee. إذا ضبطت هاتين النقطتين جيدًا، ومواءمت النطاق مع مكدسك، يصبح القرار صغيرًا. قرار المحرك أقل أهمية بكثير من نصف المهمة الذي لا تؤديه أيٌّ من الأداتين نيابةً عنك.
اعرف المزيد
جرّب Thunderbit لاستخراج بيانات الويب Get Started Free
الأسئلة الشائعة
أيّهما أسرع في استخراج الويب: Playwright أم Puppeteer؟ على نفس العينات كانت النتيجة عمليًا تعادلًا — نفس الاسترجاع في الصفحات الثابتة (12/12)، والديناميكية (8/8)، واستخراج واجهات JSON، ونفس العرض المحلي، ونفس التعامل مع 500. هذه كانت ملاحظات تشغيل واحد على جهاز واحد، وليست قياسات معيارية، لذلك الفروق الزمنية لكل صفحة لا تمثل اختبار سرعة حقيقيًا. اختر بناءً على النطاق واللغة، لا بناءً على فجوة سرعة لم تظهر.
ما الفرق الفعلي بين Playwright وPuppeteer؟ الفرق في المحركات ونطاق اللغات. Playwright يشغّل Chromium وFirefox وWebKit عبر واجهة واحدة، مع عملاء لـPython وJava و.NET. أما Puppeteer فهو متمحور حول Chrome عبر CDP، مع دعم موثّق لـFirefox عبر WebDriver BiDi منذ v23، لكن من دون WebKit، وهو مبني على Node. كلاهما يعرض JavaScript محليًا، ولا واحدة منهما تتضمن تنظيم الزحف بشكل مدمج.
هل أستطيع الزحف على موقع كامل باستخدام Playwright أو Puppeteer؟ ليس بشكل جاهز. لا واحدة منهما تحتوي على قائمة طلبات أو كاتب بيانات أو ضبط تلقائي للسرعة — واختبار بيان الزحف الذي أجريته احتاج إلى BFS مكتوب يدويًا في الحالتين، مع 12 صفحة عند الأعماق {0,1,2}. وللأحجام الكبيرة، أضف طبقة زحف مثل Crawlee، التي تغلف المحركين ببنية زحف حقيقية.
هل أحتاج أصلًا إلى أداة متصفح للاستخراج؟ فقط إذا كانت الصفحة تحتاج JavaScript كي تكشف بياناتها. إذا كان طلب HTTP مع محلّل يعيدان لك المحتوى المطلوب، فالمتصفح الخفي مبالغة مكلفة — استخدم أداة تعتمد على HTTP أولًا وتخلّص من وزن المتصفح بالكامل.
ماذا ينبغي لفريق Python أن يختار؟ Playwright، لأنه يملك عميل Python رسميًا من الدرجة الأولى. أما Puppeteer فهو مبني على Node، لذا استخدامه من Python يعني بناء جسر ينبغي عليك صيانته. هذه الملاءمة اللغوية من أوضح الأسباب الفردية لاختيار Playwright بدل Puppeteer.
