حجم Chromium يقارب 280 ميغابايت. أما الحد الأقصى لحزمة AWS Lambda بعد فك الضغط فهو 250 ميغابايت. إذا جرّبت يومًا تنفيذ npm install puppeteer ثم رفع المشروع مباشرة إلى Lambda، فأنت تعرف أن المعادلة لا تعمل لصالحك.
لقد قضيت وقتًا كافيًا في تتبّع أخطاء "Failed to launch the browser process" عند الساعة الثانية صباحًا لأعرف أن هذا الموضوع يستحق مقارنة حقيقية، لا مجرد شرح يوضح طريقة واحدة ويتركك تتخبط في الباقي. لذلك فهذا الدليل يضع ثلاث طرق جنبًا إلى جنب: Layers مقابل Container Images مقابل رفع ZIP مباشر، مع جدول توافق محدث لعام 2026، وقسم استكشاف أخطاء لأكثر خمسة أخطاء شائعة على الأرجح.
ما المقصود بـ Puppeteer على AWS Lambda ولماذا نستخدمه أصلًا؟
Puppeteer هي مكتبة Node.js تتحكم في Chromium بوضع headless عبر Chrome DevTools Protocol. أما Lambda فهي خدمة الحوسبة بدون خوادم من AWS — تدفع فقط عند التنفيذ، وتتوسع تلقائيًا، ولا تحتاج إلى إدارة أي خادم. وعند الجمع بينهما تحصل على إعداد لـ أتمتة المتصفح بدون خادم يمكنه توزيع الحمل على مئات العمليات المتوازية من دون أن تجهّز حتى مثيل EC2 واحدًا.
حالات الاستخدام متشابهة غالبًا بين الفرق: استخراج البيانات من المواقع، إنشاء لقطات الشاشة وملفات PDF، المراقبة الاصطناعية، إعادة العرض المسبق لتطبيقات الصفحة الواحدة من أجل SEO، والاختبارات الآلية لواجهات المستخدم. والمشكلة تبقى نفسها دائمًا: حجم Chromium مقابل حدود الحزم في Lambda. لهذا السبب لا ينشر أحد حزمة puppeteer الكاملة إلى Lambda، لأنها تتضمن Chromium الخاص بها. بدلًا من ذلك، يستخدم المطورون puppeteer-core من دون متصفح مضمّن، مع نسخة Chromium مهيأة لـ Lambda، وغالبًا ما تكون @sparticuz/chromium.
هذا الاستبدال وحده — puppeteer-core بدلًا من puppeteer — يحل نحو 80% من مشكلة الحجم قبل أن تكتب سطرًا واحدًا من إعدادات النشر.
Layers أم Container Image أم ZIP؟ حدّد المسار أولًا
أحد الأمور التي أزعجتني أثناء البحث هو أن معظم الأدلة الموجودة تشرح طريقة نشر واحدة فقط. شروحات AWS SAM تركّز على Layers، وأمثلة CDK تستخدم Docker، وأحيانًا تجد منشورًا عشوائيًا على Substack يعتمد ZIP خام مع Chromium مخزن في S3. لا أحد يضع هذه الخيارات جنبًا إلى جنب، وبالتالي يتم تجاهل أول قرار مهم فعلًا: أي طريقة نشر تناسب حالتك؟
لذا دعنا نصحح ذلك.
| المعيار | Lambda Layers | صورة حاوية (Docker) | رفع ZIP مباشر |
|---|---|---|---|
| الحد الأقصى للحجم | 250 ميغابايت بعد فك الضغط (إجمالي الطبقات) | 10 غيغابايت للصورة | 250 ميغابايت بعد فك الضغط |
| تعقيد النشر | متوسط (إدارة ARN للطبقة) | أعلى (Dockerfile + رفع إلى ECR) | الأقل (ضغط ورفع) |
| التأثير على cold start | متوسط | أعلى قليلًا (بسبب سحب صورة أكبر) | متوسط |
| طريقة تحديث Chromium | إعادة نشر إصدار الطبقة | إعادة بناء الصورة | إعادة رفع ملف zip |
| الأنسب لـ | النماذج الأولية السريعة، مستخدمو Serverless Framework | أحمال الإنتاج، فرق تستخدم Docker في CI | وظائف بسيطة لمرة واحدة |
| دعم IaC | SAM، Serverless Framework | CDK، SAM، Terraform | Console، وأي IaC |
الحدّان 250 ميغابايت و10 غيغابايت مأخوذان مباشرة من وثائق حصص Lambda الرسمية في AWS — ليست أرقامًا متغيرة كثيرًا، لكنها القيد الذي يحدد استراتيجية النشر بالكامل منذ البداية.
وإن أردت خلاصة عملية: إذا كنت في مرحلة التجربة أو تستخدم أصلًا Serverless Framework، فابدأ بـ Layers. وإذا كنت تنشر للإنتاج وفريقك يستخدم Docker أصلًا ضمن مسار CI/CD، فاختر Container Image — فحد 10 غيغابايت يريحك كثيرًا. أما إذا كنت تحتاج إلى دالة واحدة فقط لالتقاط لقطات شاشة من حين لآخر، فالرفع المباشر عبر ZIP هو الأقل تعقيدًا.
جميع المسارات الثلاثة تعتمد في الأساس على نفس الزوج: puppeteer-core + @sparticuz/chromium. ما يتغير هو طريقة التغليف، لا المكوّنات نفسها.
جدول التوافق المحدث لعام 2026 (توقّف عن التخمين)
هذا هو الجزء الذي يكلّف الناس أشهرًا، لا ساعات. الشكوى الأكثر تكرارًا في Stack Overflow ومشكلات GitHub ليست "كيف أنشر هذا؟" بل "لماذا تعطّل النشر الذي كان يعمل بعد تحديث npm؟". السبب غالبًا هو عدم التوافق بين @sparticuz/chromium وpuppeteer-core ونسخة Node.js في runtime.
أول نقطة مهمة: الحزمة chrome-aws-lambda الأصلية من alixaxel لم تعد مدعومة. وهي تتعطل مع Node 18+ ولم تواكب إصدارات Chromium الحديثة. إذا صادفت دليلًا يشير إليها، فأغلق الصفحة — فالمعلومة قديمة. أي دليل حديث ينبغي أن يوجّهك إلى @sparticuz/chromium بدلًا منها.
استخدم قاعدة التوافق التالية بدلًا من مطابقة أرقام الإصدارات بشكل عشوائي:
| المكوّن | قاعدة الإصدار | ما الذي يجب التحقق منه قبل النشر |
|---|---|---|
puppeteer-core | اختر إصدار Puppeteer الذي تحتاجه تطبيقاتك | راجع إصدار Chromium المدعوم من ذلك الإصدار |
@sparticuz/chromium | الإصدار الرئيسي يتبع إصدار Chromium الرئيسي، لا Puppeteer | طابِقه مع إصدار Chromium في جدول دعم Puppeteer واقرأ ملاحظات إصدار Sparticuz |
| runtime الخاص بـ AWS Lambda Node.js | استخدم runtime مدعومًا حاليًا | نفّذ اختبارًا بعد كل تحديث للـ runtime أو للحزمة |
| البنية Architecture | حزمة npm تتضمن ملفات x64، ودعم arm64 يبدأ مع Chromium v135 عبر طبقة arm64 أو pack عن بُعد | طابِق بين بنية Lambda، والملف المرفوع للطبقة/pack، وإصدار Chromium بدقة |
أنا لا أضع هنا زوجًا ثابتًا من الحزم عمدًا، لأن @sparticuz/chromium يتبع دورة إصدار Chromium ولا يستخدم النسخ الدلالية التقليدية بالشكل المعتاد. ابدأ من صفحة دعم Chromium الرسمية في Puppeteer، وحدد رقم Chromium الرئيسي المدعوم من إصدار Puppeteer الذي اخترته، ثم اختر الإصدار الرئيسي المطابق من @sparticuz/chromium. بعد ذلك، اقرأ ملاحظات إصدار Sparticuz لمعرفة أي تغييرات كاسرة على مستوى التصحيحات أو تفاصيل المعمارية. ولا تثبّت نفس الرقم الرئيسي للحزمتين إلا إذا أكدته هاتان المرجعيتان.
كيفية نشر Puppeteer على AWS Lambda باستخدام Lambda Layers
تتيح لك Lambda Layer عزل Chromium عن كود الدالة، مما يجعل الحزمة الأساسية صغيرة، ويسمح لك بإعادة استخدام طبقة Chromium نفسها عبر عدة دوال. وهي أقرب شيء إلى "البدء السريع" في هذا المجال.
الخطوة 1: ثبّت puppeteer-core وحزمة -min
عندما تكون ملفات Chromium داخل Lambda Layer، حافظ على صغر حزمة الدالة باستخدام @sparticuz/chromium-min. استبدل القيم المؤقتة بالإصدارات المتوافقة التي تأكدت منها سابقًا:
npm install puppeteer-core@$PUPPETEER_VERSION \
@sparticuz/chromium-min@$CHROMIUM_VERSION
أنت تثبّت puppeteer-core — وليس puppeteer — لأنه لا يحمّل المتصفح تلقائيًا. أما حزمة -min فتوفر أدوات التشغيل، بينما توفر الطبقة ملفات Chromium المضغوطة بصيغة Brotli تحت /opt/chromium.
الخطوة 2: أنشئ أو استخدم Chromium Lambda Layer
استخدم أرشيف الطبقة الخاص بالمعمارية والمرفق مع أحد إصدارات Sparticuz، أو ابنِ الأرشيف من المستودع الرسمي. ولـ x86_64 على Lambda، تكون طريقة البناء الموثقة كالتالي:
git clone --depth=1 https://github.com/sparticuz/chromium.git
cd chromium
make chromium.x64.zip
ينتج عن ذلك ملف chromium.x64.zip. ارفعه إلى S3 ثم انشره كـ Lambda Layer مع runtime والبنية التي تستخدمها فعلًا. أما arm64، فاستخدم ملف الإصدار المطابق أو هدف البناء المناسب؛ لا تربط أرشيف x64 بدالة arm64.
إذا كنت تستخدم SAM، فأضف ARN الخاص بالطبقة مباشرة في template.yaml:
Resources:
PuppeteerFunction:
Type: AWS::Serverless::Function
Properties:
Layers:
- arn:aws:lambda:us-east-1:XXXXXXXXXXXX:layer:chromium-layer:1
الخطوة 3: اكتب معالج Lambda
إليك نمط معالج يعمل بالفعل، يفتح صفحة على عنوان URL ويعيد عنوان الصفحة:
import puppeteer from "puppeteer-core";
import chromium from "@sparticuz/chromium-min";
export const handler = async () => {
const browser = await puppeteer.launch({
args: puppeteer.defaultArgs({ args: chromium.args, headless: "shell" }),
executablePath: await chromium.executablePath("/opt/chromium"),
headless: "shell",
});
try {
const page = await browser.newPage();
await page.goto("https://example.com", { waitUntil: "domcontentloaded" });
return { title: await page.title() };
} finally {
await browser.close();
}
};
لاحظ كتلة finally. أغلق المتصفح دائمًا هناك — فإذا لم تفعل، ستتراكم عمليات المتصفح اليتيمة داخل بيئة Lambda الدافئة بين كل استدعاء وآخر، وستنتهي بأخطاء ذاكرة غريبة لا علاقة لها بكودك أصلًا.
الخطوة 4: اضبط الذاكرة والمهلة والبنية
اضبط الذاكرة على 1024 ميغابايت على الأقل — وأنا أوصي بـ 1536 إلى 2048 ميغابايت لأي شيء يتجاوز لقطة شاشة بسيطة. واجعل المهلة 60 ثانية على الأقل. وثبّت البنية على x86_64 ما لم تكن قد تحققت تحديدًا من دعم arm64 لإصدار Chromium الذي تستخدمه (وهذا يختلف من إصدار لآخر).
الخطوة 5: انشر واختبر
sam build && sam deploy --guided
نفّذ استدعاءً تجريبيًا، ثم راجع CloudWatch Logs فورًا إذا ظهرت مشكلة — فـ 90% من الأخطاء المذكورة في قسم استكشاف الأخطاء أدناه ستظهر بوضوح هناك.
كيفية نشر Puppeteer على AWS Lambda باستخدام Container Images (Docker)
تحل صور الحاويات مشكلة 250 ميغابايت بالكامل لأنها تمنحك سقف 10 غيغابايت بدلًا منه. وهذا غالبًا الخيار الأفضل لأحمال الإنتاج، خصوصًا إذا كان فريقك يستخدم Docker أصلًا ضمن مسار CI.
الخطوة 1: أنشئ Dockerfile
ابدأ من صورة AWS Lambda الأساسية الرسمية الخاصة بـ Node.js، ثم ثبّت الاعتمادات وحدد المعالج:
FROM public.ecr.aws/lambda/nodejs:20
COPY package*.json ./
RUN npm install --production
COPY . .
CMD ["index.handler"]
وبحسب حزمة Chromium التي تستخدمها، قد تحتاج إلى تثبيت بعض المكتبات المشتركة عبر yum install (سنعود لهذا في قسم استكشاف الأخطاء). حزمة @sparticuz/chromium تتضمن معظم ما تحتاجه، وهذا يقلل الكثير من التعقيد مقارنة بتثبيت Chrome كامل يدويًا.
الخطوة 2: ابنِ الصورة وارفعها إلى Amazon ECR
aws ecr create-repository --repository-name puppeteer-lambda
docker build -t puppeteer-lambda .
docker tag puppeteer-lambda:latest <account-id>.dkr.ecr.<region>.amazonaws.com/puppeteer-lambda:latest
aws ecr get-login-password | docker login --username AWS --password-stdin <account-id>.dkr.ecr.<region>.amazonaws.com
docker push <account-id>.dkr.ecr.<region>.amazonaws.com/puppeteer-lambda:latest
احتفظ بالصورة في نفس المنطقة التي تعمل فيها Lambda — السحب من منطقة أخرى يضيف زمن تأخير لا تحتاجه.
الخطوة 3: أنشئ دالة Lambda من صورة الحاوية
وجّه الدالة إلى URI الخاص بصورة ECR عبر CLI أو CDK، واضبط الذاكرة (1536–2048 ميغابايت) والمهلة (60–120 ثانية) كما تفعل مع النشر عبر Layers.
الخطوة 4: انشر واختبر
نفّذ استدعاءً تجريبيًا وتحقق من المخرجات. المقايضة الرئيسية مقارنةً بـ Layers: cold start أعلى قليلًا بسبب سحب صورة أكبر، لكنك تحصل على مساحة أوسع بكثير للاعتمادات.
كيفية نشر Puppeteer على AWS Lambda عبر رفع ZIP مباشر
هذا هو الخيار البسيط بلا زخرفة — لا Layers لإدارتها، ولا Docker لبنائه. مناسب للنماذج الأولية أو لوظيفة واحدة لا تحتاج إلى التحول إلى منصة أتمتة متكاملة للمتصفح.
الخطوة 1: ثبّت الاعتمادات محليًا
للحزمة المستقلة ذاتيًا، استخدم puppeteer-core + @sparticuz/chromium وثبّت الإصدارات بدقة. الحزمة الكاملة تحتوي ملفات Chromium المضغوطة وتفكها إلى /tmp أثناء التشغيل. استخدم @sparticuz/chromium-min فقط عندما تُوفَّر تلك الملفات بشكل منفصل عبر Lambda Layer أو رابط pack بعيد سريع؛ لأن حزمة -min لا تتضمن ملفات Brotli بنفسها.
الخطوة 2: اجمع الدالة وضعها في ملف ZIP
npm install --production
zip -r function.zip . -x "*.git*"
خيار --production مهم هنا — فاعتمادات التطوير تستهلك من حد 250 ميغابايت بلا أي فائدة.
الخطوة 3: ارفع الدالة واضبطها
aws lambda update-function-code --function-name my-puppeteer-fn --zip-file fileb://function.zip
إذا تجاوز ملف ZIP حجم 50 ميغابايت، فلن تتمكن من رفعه مباشرة عبر الـ console أو عبر أمر CLI بسيط — ستحتاج أولًا إلى رفعه إلى S3 ثم الإشارة إلى URI الخاص بـ S3 بدلًا منه. اضبط الذاكرة والمهلة والبنية كما في الطريقتين السابقتين.
الخطوة 4: انشر واختبر
استخدم نفس نمط الاستدعاء ثم مراجعة السجلات. مع الحزمة الكاملة، لا يحتاج chromium.executablePath() إلى وسيطة. أما مع chromium-min، فمرّر المسار الدقيق للطبقة أو رابط pack البعيد، مثل chromium.executablePath("/opt/chromium") لتصميم الطبقة أعلاه. والـ remote pack يضيف عملية تنزيل إلى cold start الأول، لذا استضفه قريبًا من الدالة وتحقق من إصدار الأداة والبنية.
الوسائط الخاصة بـ puppeteer.launch() التي تعمل فعلًا على Lambda
هذا هو المقطع الذي ينسخه الجميع، فلنضبطه جيدًا. بيئة تنفيذ Lambda لا تحتوي على /dev/shm، ولا تمنحك وصولًا إلى GPU، وتعمل بصلاحيات محدودة — وهذا يعني أن استدعاء puppeteer.launch() الافتراضي الذي يعمل جيدًا على جهازك لن يعمل هنا كما هو.
const viewport = {
width: 1920,
height: 1080,
deviceScaleFactor: 1,
isMobile: false,
hasTouch: false,
isLandscape: true,
};
const browser = await puppeteer.launch({
args: await puppeteer.defaultArgs({ args: chromium.args, headless: "shell" }),
executablePath: await chromium.executablePath(),
headless: "shell",
defaultViewport: viewport,
});
مصفوفة chromium.args من @sparticuz/chromium تتضمن أصلًا الإشارات المهمة لبيئة serverless — مثل --no-sandbox و--disable-gpu و--disable-dev-shm-usage وغيرها. وهذه هي فكرة استخدام الحزمة بدلًا من كتابة قائمة الإشارات يدويًا: فهي تواكب متطلبات Chromium بدلًا منك.
استكشاف الأخطاء: 5 رسائل خطأ يواجهها كل مطور
لا يوجد دليل وجدته يتضمن قسمًا حقيقيًا لاستكشاف الأخطاء، وهذا أمر غريب قليلًا بالنظر إلى أن الأخطاء هي على الأرجح السبب وراء قراءتك لهذه المقالة أصلًا.
"Failed to launch the browser process"
السبب الجذري: نقص المكتبات المشتركة (libnss3.so وlibatk وغيرها) أو خطأ في executablePath.
الحل: حزمة @sparticuz/chromium تتضمن معظم الاعتمادات المطلوبة، ولهذا تُعد الخيار الموصى به بدلًا من بناء Chromium بنفسك. وإذا كنت تنشر عبر Docker وما زلت تواجه المشكلة، فأضف المكتبات الناقصة صراحةً عبر yum install داخل Dockerfile.
"Unzipped size must be smaller than 262144000 bytes"
السبب الجذري: قمت بتثبيت الحزمة الكاملة puppeteer، والتي تتضمن تحميل Chromium الخاص بها (~400 ميغابايت).
الحل: انتقل إلى puppeteer-core + @sparticuz/chromium. وإذا كنت تحتاج فعلًا إلى مساحة أكبر، فانتقل إلى نهج Container Image وسقفه 10 غيغابايت.
"Browser disconnected" أو Timeout عند browser.newPage()
السبب الجذري: ذاكرة Lambda غير كافية، أو أنك لا تمرر إشارات مثل --disable-gpu ضمن launch args.
الحل: ارفع الذاكرة إلى 1024 ميغابايت على الأقل (وأنا أفضل أعلى من ذلك — راجع المقاييس أدناه)، وتأكد من تمرير chromium.args بدلًا من قائمة مخصصة مختصرة.
الكود الذي كان يعمل يتعطل بعد تحديث Lambda Runtime
السبب الجذري: AWS تحدّث runtime الأساسي دوريًا، ما قد يغيّر إصدارات المكتبات المشتركة أو نسخ Node.js التصحيحية من تحتك.
الحل: ثبّت إصدار @sparticuz/chromium بشكل صريح، وثبّت إصدار Node runtime في إعدادات الدالة، والأهم — أعد الاختبار بعد كل إعلان من AWS عن تحديث runtime، لا فقط عندما يحدث العطل.
"Protocol error: Connection closed" بعد نحو 30 ثانية
السبب الجذري: مهلة Lambda أقصر من الوقت الذي تحتاجه الصفحة لتحميل نفسها وعرضها.
الحل: ارفع المهلة إلى 60–120 ثانية، واضبط page.setDefaultNavigationTimeout() صراحةً، واستبدل waitUntil: 'networkidle0' بـ waitUntil: 'domcontentloaded' إذا لم تكن بحاجة إلى انتظار كل الطلبات الشبكية حتى تستقر.
تحسين النشر للإنتاج: الذاكرة وcold starts والتكلفة
معظم الأدلة تقول لك "ارفع الذاكرة" ثم تتوقف. هذا ليس نصيحة عملية — إليك ما يتغير فعلًا عندما تزيد الذاكرة.
الذاكرة مقابل الأداء
تمنح Lambda موارد CPU بشكل يتناسب مع الذاكرة، وهذه التفاصيل هي التي تربك كثيرًا من الناس. الذاكرة الأعلى ليست فقط "RAM أكثر"، بل أيضًا CPU أسرع، وهذا يسرّع عرض Chromium بشكل مباشر. عمليًا، الفرق يكون ملحوظًا عند الانتقال من 512 ميغابايت إلى نطاق 1536–2048 ميغابايت، لكن الأرقام الدقيقة ستعتمد كثيرًا على الصفحات التي تعرضها. بدلًا من عرض جدول أرقام قد يصبح قديمًا عند قراءتك له، اختبر بنفسك عند 512 و1024 و1536 و2048 ميغابايت على صفحاتك المستهدفة فعلًا — فهذه تجربة تستغرق عشر دقائق وتخبرك بالضبط أين تقع النقطة المثالية بين التكلفة والأداء.
Provisioned Concurrency لتقليل cold start
إذا كان تطبيقك حساسًا للزمن — مثل المراقبة الاصطناعية أو واجهة API لالتقاط لقطات الشاشة لحظيًا — فإن cold start هو العدو. Provisioned Concurrency يحافظ على عدد محدد من بيئات التنفيذ دافئًا وجاهزًا، ويزيل كلفة cold start مقابل دفع ثمن السعة الخاملة. وهو يستحق ذلك عندما تكون السرعة أهم من كفاءة التكلفة الصِرفة.
arm64 (Graviton) لتقليل التكلفة
دوال Lambda المعتمدة على Graviton أرخص بنحو 20% تقريبًا من نظيراتها x86_64. لكن هناك ملاحظة مهمة: دعم arm64 في @sparticuz/chromium كان تاريخيًا أكثر محدودية من x86_64، لذا تحقّق منه صراحةً مع الإصدار المثبّت قبل اعتماد Graviton في الإنتاج.
VPC مقابل عدم استخدام VPC
كان وضع الدالة داخل VPC يضيف في السابق تأخيرًا ملحوظًا في cold start؛ وقد سدّت AWS جزءًا كبيرًا من هذه الفجوة خلال السنوات الأخيرة، لكنه ليس صفرًا. لا تضع الدالة داخل VPC إلا إذا كانت تحتاج فعلًا إلى الوصول إلى موارد خاصة مثل RDS أو ElastiCache — وإلا فالأفضل تركها خارج VPC.
متى تنتقل بعيدًا عن Lambda بالكامل
إذا كانت مهام المتصفح تستغرق أكثر من 15 دقيقة بشكل متكرر، أو تحتاج إلى أكثر من 10 غيغابايت من الذاكرة، أو تتطلب جلسات متصفح دائمة بين الطلبات، فهنا تصبح Lambda ضدك بدلًا من أن تساعدك. ECS Fargate مُصمم تحديدًا لهذا النوع من الأعمال — حوسبة طويلة التشغيل، قابلة للضبط، وتُحاسَب بالثانية. Lambda ممتازة لمهام المتصفح القصيرة، المتفجرة، والقابلة للتوازي؛ لكنها أداة غير مناسبة عندما يبدأ عبء العمل في التشبه بخدمة دائمة.
متى يكون نشر Puppeteer على Lambda خيارًا خاطئًا؟
هناك نقطة تستحق الصراحة: نسبة كبيرة من المطورين الذين يصلون إلى أدلة "Puppeteer + Lambda" يحاولون في الحقيقة حل مشكلة استخراج بيانات، لا مشكلة أتمتة متصفح. إذا كان ما تحتاجه هو بيانات منظمة من صفحات الويب — مثل المنتجات أو معلومات الاتصال أو محتوى الصفحة — فكل هذا التغليف الخاص بـ Chromium وتثبيت الإصدارات وإدارة الطبقات يصبح عبئًا لم تكن بحاجة إلى تحمله.
التزم بـ Lambda + Puppeteer إذا كنت تحتاج إلى تحكم حقيقي في المتصفح: تفاعل مخصص مع النماذج، مسارات التقاط الصور أو PDF، المراقبة الاصطناعية، أو الاختبار القائم على المتصفح حيث تتلاعب بالفعل بـ DOM برمجيًا.
فكّر في واجهة استخراج بيانات إذا كانت النتيجة النهائية المطلوبة هي JSON منظم من صفحة ويب، لا جلسة متصفح تديرها بنفسك. Thunderbit Open API تتعامل مع عرض JavaScript، وآليات الحماية ضد البوتات، وCAPTCHA عبر طلب HTTP واحد فقط — POST /extract مع JSON Schema يمنحك بيانات منظمة، وPOST /distill يمنحك Markdown نظيفًا. وهناك أيضًا خادم MCP (thunderbit_extract وthunderbit_distill) إذا كنت تبني وكيلًا ذكيًا يحتاج إلى سحب البيانات أثناء سير العمل من دون تشغيل متصفح خاص به.
| العامل | Lambda + Puppeteer (DIY) | واجهة استخراج بيانات (مثل Thunderbit) |
|---|---|---|
| وقت الإعداد | ساعات (تغليف، Layers، تصحيح أخطاء) | دقائق (مفتاح API + طلب HTTP) |
| الصيانة | مستمرة (تثبيت إصدارات، تحديثات runtime) | يتكفل بها المزوّد |
| التعامل مع anti-bot | يدوي (stealth plugins، proxies) | مدمج |
| صيغة المخرجات | HTML خام / لقطات شاشة تقوم بتحليلها بنفسك | JSON منظم عبر schema |
| الأنسب لـ | أتمتة متصفح كاملة، اختبار، تدفقات مخصصة | استخراج البيانات، scraping، إدخال المحتوى |
سأقولها بصراحة: إذا كنت تقضي ساعات في تصحيح ملفات Chromium الثنائية فقط لاستخراج JSON من صفحات المنتجات، فهذه علامة على أنك تحل المشكلة الخطأ. احتفظ بمسار Lambda اليدوي للحالات التي تحتاج فيها فعلًا إلى قيادة متصفح — أما للاستخراج، فهناك طريق أبسط وأكثر مباشرة. وإذا كنت توازن بين الخيارين في مشروع محدد، فـدليلنا لأفضل أدوات AI Web Scraper يشرح المشهد بمزيد من العمق، كما أن Thunderbit Chrome Extension يستحق التجربة إذا أردت اختبار نهج الاستخراج أولًا قبل الالتزام بأي من المسارين.
الخلاصة
ثلاث طرق للنشر، وثيمة واحدة متكررة: ثبّت الإصدارات، امنح Chromium ذاكرة كافية، وطابق طريقة النشر مع القيود الحقيقية لديك بدلًا من أول دليل تصادفه. استخدم Layers للتجربة السريعة، وصور الحاويات على مستوى الإنتاج، وZIP للحالات البسيطة لمرة واحدة. وإذا كان هدفك الحقيقي هو استخراج البيانات لا أتمتة المتصفح، فقد يكون من المفيد أن تتحقق مما إذا كانت واجهة استخراج مخصصة ستوفر عليك عناء التغليف بالكامل.
الأسئلة الشائعة
هل يمكن تشغيل Puppeteer على AWS Lambda في 2026؟
نعم — باستخدام puppeteer-core مع @sparticuz/chromium، ويتم النشر عبر Layers أو Container Image أو ZIP مباشر. أما الحزمة الكاملة puppeteer وحزمة chrome-aws-lambda المتقادمة فلم تعد تعمل بشكل موثوق على runtimes الحالية في Lambda.
ما الحد الأقصى لحجم الحزمة في AWS Lambda؟ 250 ميغابايت بعد فك الضغط لكل من Layers وZIP، و10 غيغابايت لعمليات النشر عبر Container Image، وفقًا لـ حصص Lambda في AWS.
هل ما زالت chrome-aws-lambda مدعومة؟
لا. الحزمة الأصلية chrome-aws-lambda من alixaxel لم تعد مدعومة وتتعطل مع Node 18+. استخدم @sparticuz/chromium بدلًا منها — فهي الخيار النشط حاليًا.
كم من الذاكرة يحتاج Puppeteer على AWS Lambda؟ 1024 ميغابايت هو الحد الأدنى العملي؛ أما 1536–2048 ميغابايت فهو النطاق الذي يصبح فيه الأداء مريحًا فعلًا. تحت 1024 ميغابايت، توقّع تنفيذًا أبطأ بوضوح لأن Lambda تربط توزيع CPU بالذاكرة.
كيف أقلل زمن cold start لـ Puppeteer على Lambda؟ خصص ذاكرة أكبر (وستحصل معها على CPU أكثر)، وفكر في Provisioned Concurrency إذا كانت السرعة حاسمة لحالتك، وابقِ حزمة النشر خفيفة قدر الإمكان — فكل اعتماد إضافي يعني وقت cold start إضافيًا.
