مراجعة Browserless: Chrome كخدمة يمكنك ضبط استهلاكها

Browserless متصفح Chrome بنمط headless مُقدَّم كخدمة تستضيفها بنفسك. تبقى حاويته قيد التشغيل، وتستقبل العمل عبر HTTP أو WebSocket، وتفرض حدود قبول مشتركة بدلاً من الاستيراد داخل كل تطبيق. في اختبارات REST هنا، بقيت الخدمة عند صفر عمليات Chrome في الخمول، وأنشأت عمليات أثناء الطلب، وعادت للصفر بعده. المُجمَّع مسبقًا سعة الخدمة والانتظار، لا مجموعة متصفحات مُسخَّنة مؤكدة.

شغّلت v2.55.0 مقابل بيئة محلية مضبوطة: تفكيك الإقلاع لمراحل، اختبار القبول بثلاثة إعدادات، فحص دقة النهايات مقابل نتائج معروفة، اختبار تحمّل بـ 30 جلسة، وحد التايم آوت. السلوك المفيد كان تشغيليًا لا سرعة أعلى: حدود القبول تطابقت مع استجابات العميل، وأغلب الحواف الحادة مرتبطة بالنشر.

أهم نتيجة لم تكن رقم سرعة. Browserless لا يجعل Chrome يبدأ أسرع، بل يضع سياسة باب عليه: عدد ثابت من الجلسات، طابور خلفها، و429 لمن عداهم. هذا السقف انتقل من 4 إلى 8 إلى 10 عند تغيير متغيرَي بيئة، وحساب الحاوية توافق مع رموز حالة العميل في كل طلب.

ما هو Browserless فعليًا

التصنيف هو ما يُوقِع الناس. Browserless ليس مكتبة تستوردها، بل صورة Docker — ghcr.io/browserless/chromium — تُشغّلها كخدمة طويلة الأمد. تُتيح عمل المتصفح بطريقتين: نقاط REST (/content، /scrape، /screenshot، /pdf، و/function و/unblock)، وواجهة CDP/WebSocket يتصل بها Puppeteer وPlaywright.

اختبرتُ سطح REST فقط. مسار WebSocket حقيقي وواسع الاستخدام، لكنني لم أقِسه.

الإصدار المختبَر هو v2.55.0، تم التحقق منه في 27 يوليو 2026.

عدد النجوم يتغيّر باستمرار؛ اعتبره قراءة في لحظة محددة.

بوابة الترخيص: SSPL-1.0 أو ترخيص تجاري

يُقدَّم المستودع بموجب SSPL-1.0 أو ترخيص Browserless التجاري. اقرأ LICENSE الحالي وإرشادات النشر مفتوحة المصدر قبل اختيار المسار. لم يُجرِ هذا المقال تحليلًا قانونيًا لأي سيناريو نشر، فاجعل مسؤول تراخيص البرمجيات لديك يقيّم نموذجك.

تبيع Browserless أيضًا خططًا مُستضافة. التسعير متقلب ولم يكن جزءًا من هذا الاختبار، فتحقق منه على الموقع الرسمي بدلًا من اعتماد جدول قديم هنا.

كيف يعمل نموذج الجلسات تحت الغطاء

تصرّف مسار REST المقيس وكأنه عمل متصفح لكل طلب، لكن الاختبار لم يتعمّق كفاية للتمييز بين عملية جديدة وإعادة استخدام السياق. ما ثبت أبسط: صفر عمليات Chrome في الخمول، 11 عملية أثناء طلب نشط، وصفر بعد التشغيل المتسلسل. لا دليل على مجمع متصفحات مُسخَّن مسبقًا هنا.

خدمة Node طويلة الأمد تسمح بعدد محدود من المهام، تضع مجموعة أخرى في الانتظار، وترفض الباقي. اعتبر هذا العقد المعماري المقيس أدناه. لا تستنتج إعادة استخدام العمليات من كلمة «pool» وحدها.

التحكم في القبول متغيّران:

• CONCURRENT — عدد الجلسات العاملة في الوقت نفسه.
• QUEUED — عدد الطلبات الإضافية التي تنتظر مكانًا.

أظهرت /config الافتراضيات CONCURRENT=10 و QUEUED=10 و TIMEOUT=30000. أي طلب يتجاوز CONCURRENT + QUEUED يُرفض فورًا.

المصادقة ليست اختيارية. Browserless v2 يتطلب رمزًا مميزًا دائمًا — بلا TOKEN محدد، يولّد واحدًا عشوائيًا ويطبعه في stdout. كل استدعاء REST يحمل ?token=.

للمراقبة تحصل على /pressure (تشغيل، انتظار، CPU، ذاكرة، مرفوض مؤخرًا)، و/sessions، و/config. توجد /metrics بصيغة JSON أيضًا، لكنها تتطلب METRICS_JSON_PATH ولم أستخدمها. وتُشغّل الصورة dumb-init كـ PID 1، الحل الموثّق لمشكلة عمليات Chrome الزومبي.

واقع الإعداد: أمر واحد، وأربعة أمور لا يذكرها أحد

سطر التثبيت الذي يقتبسه الجميع هو بالفعل أمر docker run واحد. ما يحيط به هو ما يجب أن تخطط له.

حجم الصورة 4.34 جيجابايت. هذا الرقم الذي يجب أن يُشكّل توقعاتك، لا زمن الإقلاع. يحمل البيان linux/arm64 وlinux/amd64؛ على مضيفي arm64 سحب Docker النسخة الأصلية. (user-agent الخاص بـ Chrome داخل الحاوية يظهر كـ X11; Linux x86_64 — مجرد UA تجميلي، لا محاكاة. uname -m يُظهر aarch64.)

استخدمت --shm-size=2g في كل قياس. لم يتضمن الاختبار تشغيلًا ضابطًا بالإعداد الافتراضي لـ /dev/shm، فلا يمكن اعتبار 2 جيجابايت إلزاميًا عالميًا. اضبط الحجم بحسب حاجتك.

الرمز المميز قضية أمن نشر، لا إجراء شكلي. بدونه، يمتلك أي شخص يصل للمنفذ 3000 متصفحًا على شبكتك.

شبكة الحاوية مسؤوليتك. عملت البيئة على المضيف، فوصلت إليها الحاوية عبر host.docker.internal (يربط colima ذلك عبر --add-host host.docker.internal:host-gateway). تحققت بـ curl خام من وصولها قبل الوثوق بأي قياس.

بيئتي: colima 0.10.3 (6 معالجات / 11.6 جيجابايت) مع Docker 29.2.1 على macOS 26.5.2 arm64، وPython 3 القياسية فقط. لملفات PNG وPDF، تحققت من توقيعات الملفات فقط، لا فك الترميز أو الأبعاد أو الدقة البصرية.

تشغيل مكافئ بسيط يستخدم الصورة المثبّتة، رمزًا صريحًا، وحجم الذاكرة نفسه:

docker run --rm -p 3000:3000 --shm-size=2g \
  -e TOKEN=replace-with-a-secret \
  ghcr.io/browserless/chromium:v2.55.0

بعد استجابة /pressure?token=...، يفعّل طلب POST /content?token=... مُصادَق مع JSON يتضمن الرابط المستهدف مسار REST. يحتاج مستدعو الإنتاج أيضًا إعادة محاولة محدودة مع تشويش عشوائي عند 429؛ فإعادة المحاولة فورًا تصطدم مجددًا بنفس الطابور الممتلئ.

ضريبة الإقلاع، مُفكَّكة إلى مراحل

ثلاث عمليات إقلاع جديدة بـ docker run، الوسيط مع نطاق الحد الأدنى–الأقصى:

من السهل تفسير الصف الأوسط مبالَغًا فيه. لا يقيس إقلاع المتصفح بمعزل، ولا يُثبت أن Browserless أسرع من مكتبة داخل العملية. إنه رحلة HTTP زائد عمل المتصفح والتنقل ونقل الاستجابة. الفارق نحو 0.17 ثانية بين أول طلب واللاحق قد يتضمن تأثيرات نظام الملفات أو Chrome أو Node أو التخزين المؤقت. ولأن العمليات كانت صفرًا في الخمول ولم يُلتقط تتبّع CDP، لا يمكن نسبة الفارق لإعادة استخدام المتصفح.

هذه أرقام من جهاز colima الافتراضي على macOS، وستختلف على Linux الفعلي. لا تذكر 0.78 ثانية لفريقك كرقم قابل للنقل بين البيئات.

تجربة عملية: إيجاد السقف من الجهتين

عقد CONCURRENT + QUEUED → 429 يتكرر ذكره في كل مكان، ونادرًا ما يُثبَت عمليًا.

الإعداد: مسار ينام 5 ثوانٍ خادميًا، فيشغل كل طلب جلسة لمدة معروفة. أطلقت CONCURRENT + QUEUED + 4 طلبات معًا، وراقبت الاستجابات بينما يقرأ خيط منفصل /pressure.

ثلاثة أمور اتضحت من هذا.

السقف بالضبط CONCURRENT + QUEUED في كل مرة. الاستجابات الناجحة كانت 4 و8 و10 — مجموع الإعداد في كل حالة. والرفض ساوى الفائض، 4 في التشغيلات الثلاثة.

السقف يتحرك. ليس ثابتًا في الصورة، بل ما تضبطه أنت. الانتقال من 4 إلى 8 إلى 10 بتغيير متغيرات البيئة هو ما يجعله مفيدًا لا مجرد تفصيل.

والإشارتان مستقلتان: رموز حالة العميل من استجابات HTTP حقيقية، و/pressure من حساب الحاوية عبر خيط مختلف. توافقتا هنا، ما يجعل /pressure إشارة مرشحة للإنتاج لا عقدًا كاملًا للتوسّع التلقائي: وتيرة الجلب والتجميع متعدد النسخ ما زالت تحتاج تحققًا.

تفصيل تُخفيه أعداد النجاح/الفشل: الطلب في الطابور لا يفشل، بل ينتظر وقد ينتظر طويلًا. عند (2, 2) مع عمل 5 ثوانٍ، وصلت الاستجابات بين 5.7 و11.0 ثانية، بوسيط 8.3 ثانية، أي ضعف مدة الجلسة تقريبًا. لم يلتقط الاختبار طوابع منفصلة للقبول والتنفيذ، فلا يمكن نسبة كامل التأخير للطابور.

كيف يبدو هذا في مهمة حقيقية

لنفترض تحويل 4,000 صفحة منتج إلى PDF كل ليلة، وكل صفحة نحو 5 ثوانٍ. تضبط CONCURRENT=5, QUEUED=5. سقف الإنتاجية صفحة في الثانية، فتستغرق المهمة نحو 67 دقيقة إن أبقيت القناة ممتلئة. حساب على سلوك مقيس لا اختبار أداء، لكنه واجب قبل النشر.

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

تجربة عملية: ما تراه نقاط النهاية فعليًا

لاختبار دقة العرض بصدق، تُخفي صفحة الاختبار نص علامتها عن أي طرف لا يُشغّل متصفحًا حقيقيًا. السلسلة Runtime Injected Marker 88 تُجمَّع من أجزاء JavaScript عند التحميل، فلا توجد حرفيًا في أي بايت يرسله الخادم. الجلب الثابت العادي يُعيد 702 بايت بلا أي من العلامتين.

عودة /content بـ 811 بايت تحمل العلامة المُحقنة تعني أن Chromium حقيقيًا عرض الصفحة قبل عودة HTML. /scrape استخرج قيمة من عقدة لا توجد إلا بعد تشغيل JavaScript. عمل كلاهما دون أي كود أتمتة على جانب العميل — طلب POST واحد مُصادَق.

هذا جوهر العرض. في نفس الجولة، فوّت زاحف ثابت هذا المحتوى تمامًا، ولم تلتقطه مكتبات المتصفح داخل العملية (chromedp، rod، Selenium) إلا بعد انتظار صريح كتبته. Browserless التقطها بطلب لا يزيد تعقيدًا عن curl. أنت تستبدل كود الأتمتة بوزن النشر.

حدّان لهذا الادعاء: الأدلة تغطي فئات محتوى بيئتي فقط، لا مسحًا للويب الحديث. و/unblock، نقطة مقاومة الكشف، تُركت عمدًا دون اختبار. كذلك لم تُختبر /function و/download و/performance.

تجربة عملية: فحص سريع للبقايا

يُعرف Chrome داخل الحاويات بترك بقايا خلفه، فشغّلت 30 جلسة متسلسلة بـ CONCURRENT=3 وأحصيت العمليات داخل الحاوية.

قبل الوثوق بأي نتيجة، عايرتُ أداة الكشف. أثناء جلسة نشطة، سجّل /proc 11 عملية من عائلة Chrome (المتصفح، zygote، GPU، renderer، utility). هذا مهم: يُثبت أن الأداة ترى Chrome فعلًا، فقراءة الصفر بعد التشغيل قياس حقيقي لا عمى. اختبار تسرّب يُبلّغ «0 عمليات» دون إثبات قدرته على العدّ لا قيمة له.

بعد 30 جلسة: 0 عمليات Chrome، 0 زومبي. الناجون الوحيدون: dumb-init وnode وXvfb وstart.sh وsh. وأظهرت /sessions القيمة 0 عند الخمول.

ذاكرة الحاوية من docker stats (الرقم الذي يراه المشغّل، لا RSS عملية واحدة):

صافي الزيادة عبر 30 جلسة: نحو 9.5 ميجابايت، واستقر المنحنى بعد الجلسة العاشرة. لا يتوافق هذا مع تسرّب خطي بسيط في هذه النافذة القصيرة. إحماء Node تفسير معقول واحد، لا شيء يثبته هذا العدد وحده.

النطاق: 30 جلسة اختبار تحمّل صغير، لا اختبار احتمال طويل أو تزامن. تحذيرات EventEmitter القديمة قد تظهر فقط عبر ساعات وآلاف الجلسات، ولم أختبر ذلك. الاستنتاج المدعوم فقط: لم تتراكم عمليات Chrome أو زومبي في هذه النافذة على v2.55.0.

حد التايم آوت

TIMEOUT موثّق كإعداد قابل للضبط. أردتُ رؤية تفعيله.

مع TIMEOUT=5000، أعادت جلسة حاولت الاحتفاظ بصفحة 15 ثانية رمز 408 عند 5.007 ثانية بدل التعليق. تؤكد هذه الملاحظة أن التطبيق يحدث قرب الحد، لكنها لا تكشف آلية المؤقّت ولا تُثبت تنظيف الفتحة؛ اختبار أقوى يكرر التجربة ويراقب عودة /sessions و/pressure للخمول قبل التأكد من حصول الطلب التالي على الفتحة.

فخ الترحيل: PREBOOT معطّل تمامًا ولا يخبرك بذلك

من بين كل ما قِسته، هذه النتيجة التي كنت أتمنى معرفتها قبل الترقية.

أزال Browserless 2.0.0 كلًا من PREBOOT وKEEP_ALIVE — وسجل التغييرات يذكر أنهما مربكان وضئيلا الأثر ومسببان للأخطاء. قرار معقول. المشكلة فيما يحدث عند نسخ إعداد v1 مباشرة إلى v2، الطريقة الأشيع للترقية.

شغّلت الحاوية مع -e PREBOOT=true وقِستها مقابل الافتراضي:

كل قياس يقع ضمن نطاق الافتراضي — أي ضجيج لا أثر. ولم يُسخَّن شيء: حاوية PREBOOT=true تبقى خاملة دون متصفح، مطابقة لحاوية بلا العلَم. إشارتان أخريان:

• /config لا تُظهر أي مفتاح preboot. المفاتيح الموجودة: concurrent وqueued وtimeout وtoken وmaxCPU وmaxMemory وretries وما شابهها.
• لا خطأ. لا تحذير. لا شيء في السجلات.

فإعداد PREBOOT من v1 على v2 عملية بلا أثر بصمت، في الإقلاع والسجلات معًا. غياب المفتاح مع ثبات السلوك هو الإشارة القابلة للاكتشاف. فحص الترحيل يحتاج تفتيش الإعدادات فعليًا لا اعتبار الإقلاع الناجح دليلًا كافيًا.

KEEP_ALIVE الحالة المعاكسة، ولا ينبغي دمجهما. أُزيلت في الإصدار نفسه، لكنها ليست صامتة — فحص سريع يُظهر تسجيلها Environment variable of "KEEP_ALIVE" is deprecated and ignored. في stdout. لم أُخضعها لنفس أداة قياس PREBOOT، فأذكرها كفحص لا قياس. لكن الاتجاه واضح: PREBOOT وحدها الفخ الصامت.

الإيجابيات والسلبيات

الإيجابيات

• التحكم في القبول يعمل كما هو موثّق ويتحرك مع الإعدادات — أُثبت عند ثلاثة أسقف، على رموز حالة العميل وحساب الخادم معًا.
• تطابقت /pressure مع أعداد التشغيل والانتظار والرفض التي يراها العميل؛ مُدخل مرشح للتوسّع التلقائي.
• عرض Chromium حقيقي دون كود أتمتة: طلب POST واحد كشف DOM مُحقنًا عبر JS لا يراه جلب ثابت.
• لم تتراكم عمليات Chrome في 30 جلسة متسلسلة؛ العدد بعد التشغيل 0 عمليات و0 زومبي.
• تجربة TIMEOUT واحدة أعادت 408 عند 5.007 ثانية مقابل ميزانية 5.000 ثانية.
• المصادقة مفعّلة افتراضيًا: نقاط REST الأربع تُعيد 401 دون رمز.
• أمر docker run واحد لخدمة جاهزة خلال نحو 0.78 ثانية، وأول عرض بعدها بـ 0.32 ثانية.

السلبيات

• حجم الصورة 4.34 جيجابايت، تظهر تكلفتها في السجل وذاكرة CI والنشر البارد.
• SSPL-1.0 أو ترخيص Browserless التجاري. قيّم الشروط مقابل نموذج نشرك.
• PREBOOT من v1 يُقبَل ويُتجاهَل بصمت في v2 — دون خطأ أو تحذير أو مفتاح في /config.
• تُشغّل خدمة لا تُضيف تبعية: حاوية، رمز، مسار شبكة، سقف قبول، ومسؤولية ترقية.
• رفعت الطلبات المنتظِرة زمن الاستجابة لضعف مدة الجلسة تقريبًا في (2, 2).
• توقيت REST المقيس يتضمن قفزة HTTP ولا يعزل تكلفة إقلاع المتصفح أو يُثبت إعادة استخدامه.

من يجب أن يستخدمها، ومن يجب أن يتجنبها

تستحق Browserless وزنها عندما يحتاج أكثر من شيء واحد متصفحًا: خدمة عرض مشتركة بين تطبيقات، فريق يريد لقطات شاشة وPDF خلف HTTP بدل تبعية Chrome في كل خدمة، أو خط أنابيب يحتاج سقف سعة مع ضغط عكسي قابل للقياس. إن كنت تُشغّل Docker ولديك مَن يتولى النشر، الصورة واضحة: قبول متوقع، ضغط عكسي مرئي، ولا عمليات Chrome أو زومبي متراكمة كما لوحظ في فحص الـ 30 جلسة.

إنها أيضًا الخيار الصحيح إن كان البديل أن تُثبّت كل خدمة Chromium خاصًا بها؛ تجميعها في حاوية واحدة برمز وسقف مقايضة معمارية جيدة بحق.

تجنّبها إن كنت تكتب سكريبتًا واحدًا: سحب 4.3 جيجابايت وتشغيل حاوية لكي يجلب ملف Python صفحة مُعروضة مراسم كثيرة لمهمة صغيرة — مكتبة داخل عمليتك تنجز ذلك دون نشر خدمة. تجنّبها إن كانت شروط SSPL لا تناسبك ولا يمكنك حلّها، أو كان ما تريده متصفحًا مُسخَّنًا مسبقًا (فـ PREBOOT لن يمنحك ذلك في v2)، أو كانت مشكلتك مقاومة البوتات (نقطة اخترت عمدًا عدم اختبارها).

البدائل، وأين يتموضع Thunderbit بينها

المقارنة المهمة ليست بين Browserless وحاوية أخرى، بل أين يعيش المتصفح ومن يتحمل مسؤولية إبقائه حيًا.

مراجعة ذات صلة: Browsertrix Crawler.

مراجعة ذات صلة: chromedp.

إن أردت متصفحًا داخل عمليتك ولا تمانع كتابة الانتظارات، المكتبة أخف ولا تتطلب نشرًا. كتبتُ عن هذا في مقارنة Playwright مقابل Puppeteer وفي استعراض مشاريع مفتوحة المصدر.

إن لم ترغب في تشغيل متصفح أصلًا، فإن Thunderbit الخاص بنا بديل مُدار. تُعيد Browserless مادة يفسّرها كودك؛ ويعيد Thunderbit Markdown أو بيانات مطابقة لمخطط بينما يتولى المزوّد بنية العرض. لم يقارن هذا المقال أداء Thunderbit أو تكلفته، فالجدول يصف حدود المسؤولية لا أداءً.

قراءة ذات صلة: مراجعة Crawl4AI لخط أنابيب Markdown بمتصفح تُشغّله بنفسك، واستعراض أدوات استخراج البيانات من الويب للفئة الأوسع.

جرّب Thunderbit لاستخراج البيانات من الويب

الحكم النهائي

هل يجب أن تُشغّل Browserless؟ نعم، إذا احتاج عدة مستدعين عمل متصفح، وأمكن لأحد تشغيل الحاوية، ووافقت مراجعة الترخيص على نموذج النشر. في ثلاث تشغيلات قبول اصطناعية، تطابق المقبول مع CONCURRENT + QUEUED، وتلقى الفائض 429، وتطابقت /pressure مع أعداد العميل. في فحص 30 جلسة منفصل، لم تتراكم عمليات Chrome أو زومبي. تجربة تايم آوت واحدة أعادت 408 قرب الحد. ملاحظات مفيدة محدودة النطاق، لا ضمانات عامة.

قدّر الالتزام بصدق مع ذلك. إنها صورة 4.34 جيجابايت وخدمة تُشغّلها بنفسك، لا مجرد تبعية؛ ولم يُثبت هذا الاختبار سرعة أعلى من مكتبة داخل العملية. ما تحصل عليه متصفح يمكنك ترشيده: سقف معروف وضغط عكسي قابل للقياس، مقابل وزن نشر وترخيص يجب قراءته. إن كنت تعرض حفنة صفحات من سكريبت واحد، المقايضة لا تستحق. أما لطبقة عرض تعتمد عليها عدة خدمات فتستحق — فقط تحقق من متغيرات v1 في طريقك، لأن PREBOOT سيبدو يعمل بينما لا يفعل شيئًا.

جرّب Thunderbit لاستخراج البيانات من الويب Get Started Free

الأسئلة الشائعة

هل تجعل Browserless متصفح Chrome بنمط headless أسرع؟ لا يستطيع هذا الاختبار الإجابة. أصبحت نقطة نهاية HTTP مستجيبة بعد 0.78 ثانية من docker run؛ استغرق أول /content 0.32 ثانية، واللاحق نحو 0.15 ثانية. تجمع هذه الأرقام رحلة HTTP وعمل المتصفح والتنقل، ولم يعزل الاختبار زمن الإقلاع بمفرده. استخدمها لحد خدمة مشترك وتحكم في القبول، ثم قِس زمن استجابتك بنفسك.

ماذا يحدث عند تجاوز حد التزامن في Browserless؟ تحصل على HTTP 429 فورًا. السقف بالضبط CONCURRENT + QUEUED: (2,2) قبلت 4 ورفضت 4، و(3,5) قبلت 8 ورفضت 4، و(5,5) قبلت 10 ورفضت 4. أظهرت /pressure أعدادًا متطابقة كل مرة. الطلبات المنتظِرة لا تفشل بل تنتظر — عند (2,2) مع عمل 5 ثوانٍ، استغرقت الاستجابات بين 5.7 و11.0 ثانية. اجعل عميلك يتعامل مع 429 كضغط عكسي مع إعادة محاولة وتراجع تدريجي.

هل لا يزال PREBOOT يعمل في Browserless v2؟ لا. أُزيل في 2.0.0، ويقبل v2 -e PREBOOT=true دون خطأ أو تحذير بينما لا يفعل به شيئًا. أكدتُ ذلك بثلاث طرق: زمن استجابة غير مميَّز عن الافتراضي، حاوية PREBOOT=true الخاملة بلا عمليات Chrome، و/config بلا مفتاح preboot. إن رحّلت إعداد v1، نُسخك ليست مُسخَّنة. أما KEEP_ALIVE فتُسجّل فعلًا تحذير "deprecated and ignored" — فالفشل الصامت خاص بـ PREBOOT وحدها.

هل Browserless مجانية للاستخدام التجاري؟ يُقدَّم المستودع SSPL-1.0 أو ترخيص Browserless التجاري، لكن هذا المقال لا يُسند سيناريوهات تجارية أو مغلقة المصدر محددة لأي منهما. راجع LICENSE الحالي وإرشادات النشر الرسمية، ثم اجعل مسؤول تراخيص البرمجيات يُقيّم نموذجك.

هل تترك Browserless عمليات Chrome زومبي؟ لم تتراكم أي منها في النافذة القصيرة المُختبَرة. بعد 30 جلسة، بقي 0 عمليات Chrome و0 زومبي، فقط dumb-init وnode وXvfb وstart.sh وsh. أحصى الكاشف 11 عملية أثناء نشاط الجلسة، فلم يكن أعمى. ارتفعت الذاكرة من 294 إلى 303 ميجابايت ثم استقرت. ليست هذه نتيجة اختبار لساعات أو تزامن عالٍ أو آلاف الجلسات.