Chromium שוקל בערך 280MB. מגבלת החבילה הלא־דחוסה של AWS Lambda היא 250MB. אם אי פעם ניסיתם npm install puppeteer ולפרוס ישר ל-Lambda, אתם כבר יודעים איך החשבון הזה נגמר (הוא לא).
ביליתי מספיק זמן בלדבג שגיאות של "Failed to launch the browser process" ב-2 בלילה כדי לדעת שהנושא הזה ראוי להשוואה אמיתית, ולא לעוד מדריך שמראה שיטה אחת ומשאיר אתכם לנחש לגבי השתיים האחרות. אז זה בדיוק מה שיש כאן: Layers מול Container Images מול העלאת ZIP ישירה, מטריצת תאימות גרסאות שבאמת רלוונטית ל-2026, ופרק פתרון תקלות לחמש השגיאות שהסטטיסטיקה אומרת שסביר ביותר שתפגשו.
מה זה Puppeteer על AWS Lambda ולמה בכלל להשתמש בזה
Puppeteer היא ספריית Node.js ששולטת ב-Chromium ללא ממשק גרפי דרך Chrome DevTools Protocol. Lambda הוא מנגנון המחשוב ללא שרת של AWS — משלמים לפי הפעלה, הוא מתרחב אוטומטית, ולא צריך לגעת בשרת. מחברים את השניים ומקבלים סביבת אוטומציית דפדפן שיכולה להתפצל למאות ריצות מקבילות בלי להרים אפילו מופע EC2 אחד.
המקרים השימושיים די דומים בין צוותים: scraping של אתרים, יצירת צילומי מסך ו-PDF, ניטור סינתטי, pre-rendering של אפליקציות חד־עמודיות לצורכי SEO, ובדיקות UI אוטומטיות. הבעיה תמיד אותה בעיה שהזכרתי קודם — הגודל של Chromium מול מגבלות החבילה של Lambda. לכן אף אחד לא פורס את puppeteer המלא (שכולל הורדת Chromium משלו) ל-Lambda. במקום זה משתמשים ב-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 | Container Image (Docker) | העלאת ZIP ישירה |
|---|---|---|---|
| גודל מקסימלי | 250 MB לא דחוס (בכל ה-Layers יחד) | Image עד 10 GB | 250 MB לא דחוס |
| מורכבות פריסה | בינונית (ניהול ARN של layer) | גבוהה יותר (Dockerfile + דחיפה ל-ECR) | הנמוכה ביותר (zip והעלאה) |
| השפעה על cold start | בינונית | מעט גבוהה יותר (טעינת image גדול יותר) | בינונית |
| תהליך עדכון Chromium | פרסום מחדש של גרסת layer | בנייה מחדש של ה-image | העלאת zip מחדש |
| מתאים במיוחד ל | אבטיפוסים מהירים, משתמשי Serverless Framework | עומסי ייצור, צוותים עם Docker ב-CI | פונקציות פשוטות וחד־פעמיות |
| תמיכה ב-IaC | SAM, Serverless Framework | CDK, SAM, Terraform | Console, כל כלי IaC |
גם מגבלת 250MB וגם מגבלת 10GB מגיעות ישירות מה-תיעוד המכסות של Lambda ב-AWS — זה לא מספר ששינה כיוון לאחרונה, אבל זו בדיוק המגבלה שקובעת מראש את כל אסטרטגיית הפריסה.
הכלל שלי, אם זה עוזר: אם אתם עושים אבטיפוס או כבר עובדים עם Serverless Framework, התחילו עם Layers. אם אתם עולים לייצור והצוות כבר מחזיק CI/CD מבוסס Docker, לכו על Container Image — תקרת ה-10GB נותנת הרבה מרחב נשימה. אם אתם צריכים רק פונקציה אחת שתצלם מסך מדי פעם, ZIP ישיר הוא הדרך הכי פחות מסורבלת.
כל שלושת המסלולים נשענים על אותו צמד תלויות בסיסי: puppeteer-core + @sparticuz/chromium. שיטת הפריסה משנה רק את אופן האריזה, לא את מה שמארזים.
מטריצת התאימות ל-2026 (מפסיקים לנחש)
זה החלק שבאמת עולה לאנשים חודשים, לא שעות. התלונה הכי נפוצה ב-Stack Overflow וב-GitHub Issues היא לא "איך פורסים את זה" — אלא "למה הפריסה שעבדה לי נשברה בשקט אחרי עדכון npm". האשם כמעט תמיד הוא חוסר התאמה בין @sparticuz/chromium, puppeteer-core ו-runtime של Node.js.
קודם כל ההבהרה החשובה: chrome-aws-lambda (החבילה המקורית של alixaxel) הוצאה משימוש. היא נשברת ב-Node 18 ומעלה ולא עמדה בקצב של גרסאות Chromium. אם אתם מוצאים מדריך שמפנה אליה, תסגרו את הלשונית — אתם קוראים משהו מיושן. כל מדריך עדכני צריך להצביע על @sparticuz/chromium במקום.
השתמשו בכלל התאימות הבא במקום לנסות להתאים גרסאות לפי העין:
| רכיב | כלל גרסה | מה לבדוק לפני הפריסה |
|---|---|---|
puppeteer-core | לבחור את גרסת Puppeteer שהאפליקציה שלכם צריכה | לבדוק איזה build של Chromium נתמך בגרסה הזו |
@sparticuz/chromium | הגרסה הראשית שלו מתיישרת עם הגרסה הראשית של Chromium, לא של Puppeteer | להתאים אותו ל-build של Chromium מטבלת התמיכה של Puppeteer ולקרוא את הערות הגרסה של Sparticuz |
| AWS Lambda Node.js runtime | להשתמש ב-runtime שעדיין נתמך ב-Lambda | להריץ בדיקת הפעלה אחרי כל עדכון runtime או חבילה |
| ארכיטקטורה | חבילת npm כוללת בינארי x64; תמיכה ב-arm64 מתחילה עם Chromium v135 דרך Layer או pack מרוחק | להתאים במדויק בין ארכיטקטורת Lambda, ארטיפקט ה-layer/pack וגרסת Chromium |
אני בכוונה לא נועל כאן זוג חבילות ספציפי, כי @sparticuz/chromium עוקבת אחרי מחזור השחרור של Chromium ולא משתמשת בגרסאות סמנטיות רגילות. התחילו עם עמוד Chromium Support הרשמי של Puppeteer, שימו לב ל-major של Chromium שנתמך בגרסת Puppeteer שבחרתם, ואז בחרו את אותו major של @sparticuz/chromium. לבסוף, קראו את הערות הגרסה של Sparticuz כדי לזהות שינויים שוברים ברמת patch ופרטי ארכיטקטורה. אל תתקינו את אותו מספר major בשתי החבילות אלא אם המיפוי הזה אושר במפורש על ידי שני המקורות האלה.
איך לפרוס Puppeteer על AWS Lambda עם Lambda Layers
Lambda Layer מאפשר לכם לארוז את Chromium בנפרד מקוד הפונקציה, מה שמשאיר את ה-handler עצמו קטן ומאפשר לכם לעשות שימוש חוזר באותה שכבת 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 מספקת את עזרי ההפעלה, בעוד שה-layer מספק את קבצי Chromium הדחוסים ב-Brotli תחת /opt/chromium.
שלב 2: יוצרים או מפנים ל-Chromium Lambda Layer
השתמשו בארכיון layer ייעודי לארכיטקטורה שמצורף לגרסת Sparticuz רשמית, או בנו את הארכיון ממאגר המקור הרשמי. עבור Lambda מסוג x86_64, תהליך הבנייה המתועד הוא:
git clone --depth=1 https://github.com/sparticuz/chromium.git
cd chromium
make chromium.x64.zip
זה ייצור את chromium.x64.zip. מעלים אותו ל-S3 ומפרסמים אותו כ-Lambda Layer עם ה-runtime והארכיטקטורה שבהם אתם באמת משתמשים. עבור arm64, השתמשו בארטיפקט arm64 המתאים או ביעד הבנייה המתאים; אל תחברו ארכיון x64 לפונקציית arm64.
אם אתם משתמשים ב-SAM, מצרפים את ARN של ה-layer ישירות ב-template.yaml:
Resources:
PuppeteerFunction:
Type: AWS::Serverless::Function
Properties:
Layers:
- arn:aws:lambda:us-east-1:XXXXXXXXXXXX:layer:chromium-layer:1
שלב 3: כותבים את ה-Lambda Handler
הנה דפוס handler שעובד, נכנס ל-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: מגדירים Memory, Timeout ו-Architecture
מגדירים זיכרון של לפחות 1024 MB — הייתי ממליץ על 1536–2048 MB לכל דבר מעבר לצילום מסך בסיסי. מגדירים timeout של לפחות 60 שניות. נועלים את הארכיטקטורה ל-x86_64 אלא אם כן אימתם במפורש תמיכה ב-arm64 לגרסת Chromium המדויקת שלכם (זה משתנה בין גרסאות).
שלב 5: פורסים ובודקים
sam build && sam deploy --guided
מפעילים עם אירוע בדיקה, ואז בודקים מיד את CloudWatch Logs אם משהו משתבש — 90% מהשגיאות שבפרק פתרון התקלות למטה מופיעות שם בצורה ברורה.
איך לפרוס Puppeteer על AWS Lambda עם Container Images (Docker)
Container Images פותרים לגמרי את כאב הראש של 250MB, כי הם נותנים תקרה של 10GB במקום. זו בדרך כלל הבחירה הנכונה לעומסי ייצור, במיוחד אם לצוות שלכם כבר יש Docker בתוך צינור ה-CI.
שלב 1: יוצרים Dockerfile
מתחילים מ-Image בסיס רשמי של AWS Lambda עבור Node.js, מתקינים את התלויות ומגדירים את ה-handler:
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
שמרו את ה-image באותו region של פונקציית Lambda שלכם — טעינות image חוצות-region מוסיפות השהיה שלא צריך.
שלב 3: יוצרים את פונקציית Lambda מתוך ה-Container Image
מצביעים על פונקציית Lambda אל URI של ה-image ב-ECR דרך CLI או CDK, ומגדירים memory (1536–2048 MB) ו-timeout (60–120 שניות) בדיוק כמו בפריסה מבוססת layer.
שלב 4: פורסים ובודקים
מפעילים עם אירוע בדיקה ומוודאים את הפלט. החיסרון העיקרי לעומת Layers: cold starts מעט גבוהים יותר בגלל טעינת image גדולה יותר, אבל מקבלים הרבה יותר מרחב לניהול תלויות.
איך לפרוס Puppeteer על AWS Lambda עם העלאת ZIP ישירה
זו האפשרות הפשוטה ביותר — בלי layers לנהל, בלי Docker לבנות. טובה לאבטיפוסים או לפונקציה אחת שלא צריכה להתפתח לכל פלטפורמת אוטומציית דפדפן.
שלב 1: מתקינים תלויות מקומית
עבור ZIP עצמאי, משתמשים ב-puppeteer-core + @sparticuz/chromium ושומרים את שתי הגרסאות נעולות. החבילה המלאה כוללת את קבצי Chromium הדחוסים ומחלצת אותם ל-/tmp בזמן ריצה. משתמשים ב-@sparticuz/chromium-min רק כשמספקים את הקבצים האלה בנפרד דרך Lambda Layer או כתובת Remote Pack מהירה; חבילת -min עצמה לא כוללת את קבצי Brotli.
שלב 2: אורזים את הפונקציה ויוצרים ZIP
npm install --production
zip -r function.zip . -x "*.git*"
הדגל --production חשוב כאן — תלויות פיתוח אוכלות לכם חלק מה-250MB בלי סיבה.
שלב 3: מעלים ומגדירים את פונקציית Lambda
aws lambda update-function-code --function-name my-puppeteer-fn --zip-file fileb://function.zip
אם ה-ZIP שלכם גדול מ-50MB, אי אפשר להעלות אותו ישירות דרך הקונסול או בקריאה פשוטה ל-CLI — תצטרכו להעלות ל-S3 קודם ואז להפנות ל-URI של S3 במקום. מגדירים memory, timeout ו-architecture בדיוק כמו בשתי השיטות הקודמות.
שלב 4: פורסים ובודקים
משתמשים באותו flow של הרצה ובדיקת לוגים. עם החבילה המלאה, ל-chromium.executablePath() לא צריך להעביר ארגומנט. עם chromium-min, מעבירים את נתיב ה-layer המדויק או את כתובת ה-remote pack, למשל chromium.executablePath("/opt/chromium") עבור פריסת ה-layer שלמעלה. Remote pack מוסיף הורדה ל-cold start הראשון, לכן כדאי לארח אותו קרוב לפונקציה ולאמת את גרסת הארטיפקט והארכיטקטורה.
ה-Args של puppeteer.launch() שבאמת עובדים ב-Lambda
זה הקטע שכולם עושים לו copy-paste, אז בואו נעשה אותו נכון. לסביבת ההפעלה של 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 כבר כולל את כל הדגלים החשובים לסביבה ללא שרת — --no-sandbox, --disable-gpu, --disable-dev-shm-usage ועוד דומים. זה בדיוק היתרון של השימוש בחבילה הזו במקום להרכיב בעצמכם רשימת דגלים: היא עוקבת אחרי הדרישות של Chromium, ואתם לא צריכים.
פתרון תקלות: 5 שגיאות שכל מפתח נתקל בהן
אף מדריך שמצאתי לא כולל פרק פתרון תקלות אמיתי, וזה קצת מבלבל בהתחשב בזה ששגיאות הן כמעט בוודאות הסיבה שבגללה אתם קוראים את המאמר הזה מלכתחילה.
"Failed to launch the browser process"
סיבה שורשית: חסרות ספריות משותפות (libnss3.so, libatk וכו') או שהוגדר executablePath שגוי.
תיקון: @sparticuz/chromium כוללת את רוב התלויות הנדרשות, ולכן זו החבילה המומלצת במקום לבנות לעצמכם בינארי Chromium. בפריסות Docker, אם זה עדיין קורה, מתקינים את הספריות החסרות במפורש ב-Dockerfile.
"Unzipped size must be smaller than 262144000 bytes"
סיבה שורשית: התקנתם את החבילה המלאה puppeteer, שכוללת הורדת Chromium משלה (~400MB).
תיקון: עוברים ל-puppeteer-core + @sparticuz/chromium. אם באמת צריך יותר מקום, עוברים ל-Container Image עם תקרת 10GB.
"Browser disconnected" או Timeout ב-browser.newPage()
סיבה שורשית: זיכרון Lambda לא מספיק, או שחסרים דגלים כמו --disable-gpu בארגומנטים של ההפעלה.
תיקון: מגדירים memory של לפחות 1024MB (אני הייתי הולך על יותר — ראו את הבנצ'מרקים בהמשך) ומוודאים שמעבירים chromium.args ולא רשימה מקוצרת בהתאמה אישית.
קוד שעבד נשבר אחרי עדכון של Lambda Runtime
סיבה שורשית: AWS מתקנת מדי פעם את ה-runtime הבסיסי, וזה יכול לשנות גרסאות של ספריות משותפות או גרסאות patch של Node.js מתחתיכם.
תיקון: נועלים במפורש את גרסת @sparticuz/chromium, נועלים את גרסת ה-Node runtime בהגדרת הפונקציה, ו—וזה החלק שאנשים מדלגים עליו—בודקים שוב אחרי כל הכרזה של AWS על runtime, לא רק כשמשהו נשבר.
"Protocol error: Connection closed" אחרי בערך 30 שניות
סיבה שורשית: ה-timeout של Lambda קצר יותר מהזמן שלוקח לדף להיטען ולעבור רינדור.
תיקון: מעלים את ה-timeout ל-60–120 שניות, מגדירים page.setDefaultNavigationTimeout() במפורש, ומחליפים waitUntil: 'networkidle0' ב-waitUntil: 'domcontentloaded' אם לא צריך להמתין עד שכל בקשה ברשת תסתיים לפני שממשיכים.
חיזוק לייצור: Memory, Cold Starts ועלויות
רוב המדריכים אומרים לכם "להגדיל זיכרון" ועוצרים שם. זו לא עצה שימושית — הנה מה באמת משתנה כשמעלים זיכרון.
Memory מול ביצועים
Lambda מקצה CPU ביחס לזיכרון, וזה הפרט שמבלבל הרבה אנשים. יותר זיכרון זה לא רק "יותר RAM לעבוד איתו" — זה גם CPU מהיר יותר, ולכן גם רינדור Chromium מהיר יותר. בפועל, צוותים שמבצעים בנצ'מרקים ל-Puppeteer מדווחים על שיפור משמעותי כשהם עוברים מ-512MB כלפי מעלה לטווח של 1536–2048MB, אבל המספרים המדויקים שלכם יהיו תלויים מאוד בדפים שאתם מרנדרים. במקום לצטט טבלת בנצ'מרק שתהיה מיושנת עד שתגיעו לקרוא אותה, עדיף להריץ בדיקה משלכם ב-512MB, 1024MB, 1536MB ו-2048MB מול הדפים האמיתיים שלכם — זה תרגיל של עשר דקות שמראה בדיוק איפה נמצא sweet spot שלכם בין עלות לביצועים.
Provisioned Concurrency ל-cold starts
אם אתם מריצים משהו רגיש להשהיה — ניטור סינתטי, API לצילומי מסך בזמן אמת — cold starts הם האויב. Provisioned Concurrency שומרת כמות מסוימת של סביבות ריצה חמות ומוכנות, ובכך מבטלת את עונש ה-cold start במחיר של תשלום על הקיבולת הזו גם כשהיא לא פעילה. זה משתלם במיוחד כשזמן תגובה חשוב יותר מיעילות עלות נטו.
arm64 (Graviton) לחיסכון בעלויות
פונקציות Lambda מבוססות Graviton זולות בערך ב-20% מהמקבילות ב-x86_64. הבעיה: התמיכה של @sparticuz/chromium ב-arm64 הייתה היסטורית מוגבלת יותר מאשר ב-x86_64, לכן חשוב לאמת זאת במפורש מול הגרסה שננעלה אצלכם לפני שמחליטים לייצר ב-Graviton.
VPC מול No-VPC
מיקום הפונקציה בתוך VPC הוסיף בעבר השהיית cold start משמעותית; AWS צמצמה הרבה מהפער הזה בשנים האחרונות, אבל זה עדיין לא אפס. מכניסים את הפונקציה ל-VPC רק אם באמת צריך גישה למשאבים פרטיים כמו RDS או ElastiCache — אחרת עדיף להימנע.
מתי לעבור בכלל מחוץ ל-Lambda
אם משימות הדפדפן שלכם עוברות באופן קבוע 15 דקות, דורשות יותר מ-10GB זיכרון, או צריכות סשנים מתמשכים של דפדפן בין בקשות, Lambda כבר נאבקת בכם. ECS Fargate בנוי בדיוק לזה — משאבים מתכווננים, ריצה ארוכה, ותשלום לפי שנייה. Lambda מעולה למשימות דפדפן קצרות, מתפרצות וניתנות לפיצול; היא הכלי הלא נכון ברגע שהעומס מתחיל להיראות כמו שירות מתמשך.
מתי פריסה של Puppeteer ב-Lambda היא לא הבחירה הנכונה
יש כאן משהו שכדאי לומר בכנות: חלק גדול מהמפתחים שמגיעים למדריכים של "Puppeteer + Lambda" בעצם מנסים לפתור בעיית חילוץ נתונים, לא בעיית אוטומציית דפדפן. אם מה שאתם באמת צריכים הוא נתונים מובנים מדפי אינטרנט — רשימות מוצרים, פרטי קשר, תוכן דפים — כל האריזה של Chromium, נעילת הגרסאות וניהול ה-Layers למעלה הם תקורה שלא הייתם צריכים לקחת על עצמכם.
שווה להישאר עם Lambda + Puppeteer אם אתם צריכים שליטה אמיתית בדפדפן: אינטראקציה מותאמת בטפסים, צינורות צילום מסך/PDF, ניטור סינתטי, או בדיקות מבוססות דפדפן שבהן אתם באמת מניעים את ה-DOM באופן תכנותי.
כדאי לשקול API לחילוץ נתונים אם התוצאה הסופית שלכם היא JSON מובנה מתוך דף אינטרנט, ולא סשן דפדפן שאתם מנהלים בעצמכם. Thunderbit Open API מטפל ברינדור JS, במנגנוני anti-bot וב-CAPTCHA דרך קריאת HTTP אחת — POST /extract עם JSON Schema מחזיר נתונים מובנים, ו-POST /distill מחזיר Markdown נקי. יש גם שרת MCP (thunderbit_extract, thunderbit_distill) אם אתם בונים agent מבוסס AI שצריך למשוך נתונים תוך כדי workflow בלי להרים דפדפן משלו.
| גורם | Lambda + Puppeteer (DIY) | API לחילוץ נתונים (למשל Thunderbit) |
|---|---|---|
| זמן הקמה | שעות (אריזה, layers, דיבוג) | דקות (מפתח API + קריאת HTTP) |
| תחזוקה | מתמשכת (נעילת גרסאות, עדכוני runtime) | מטופלת על ידי הספק |
| טיפול ב-anti-bot | ידני (stealth plugins, proxies) | מובנה |
| פורמט פלט | HTML גולמי/צילומי מסך שאתם מנתחים בעצמכם | JSON מובנה באמצעות schema |
| מתאים במיוחד ל | אוטומציית דפדפן מלאה, בדיקות, flow-ים מותאמים | חילוץ נתונים, scraping, קליטת תוכן |
אומר את זה בפשטות: אם אתם מבלים שעות בלדבג בינארי Chromium רק כדי לשלוף JSON מדפי מוצרים, זה סימן שאתם פותרים את הבעיה הלא נכונה. שימרו את המסלול של Lambda DIY למצבים שבהם באמת צריך להפעיל דפדפן — לחילוץ נתונים, יש דרך ישירה יותר. אם אתם שוקלים את הפשרה הזו עבור פרויקט מסוים, המדריך שלנו ל-AI web scrapers סוקר את הנוף לעומק, ו-תוסף Chrome של Thunderbit שווה בדיקה אם אתם רוצים לנסות קודם גישת extraction-first לפני שמתחייבים לאחד המסלולים.
סיכום
שלוש שיטות פריסה, נושא אחד חוזר: לנעול גרסאות, לתת ל-Chromium מספיק זיכרון לנשום, ולהתאים את שיטת הפריסה למגבלות האמיתיות שלכם במקום למדריך הראשון שמצאתם. Layers לאיטרציה מהירה, Container Images לקנה מידה ייצור, ZIP לפתרון פשוט וחד־פעמי. ואם מה שאתם עושים בפועל הוא חילוץ נתונים ולא אוטומציית דפדפן — אולי שווה לבדוק אם API ייעודי לחילוץ חוסך לכם לגמרי את כאב האריזה.
שאלות נפוצות
האם אפשר להריץ Puppeteer על AWS Lambda ב-2026?
כן — באמצעות puppeteer-core יחד עם @sparticuz/chromium, בפריסה דרך Layers, Container Image או ZIP ישיר. החבילה המלאה puppeteer ו-chrome-aws-lambda שהוצאה משימוש כבר לא עובדות בצורה אמינה ב-runtimes העדכניים של Lambda.
מהו גודל החבילה המקסימלי ב-AWS Lambda? 250MB לא דחוס עבור פריסות Layers ו-ZIP; ו-10GB עבור Container Image, לפי מכסות Lambda של AWS.
האם chrome-aws-lambda עדיין מתוחזקת?
לא. החבילה המקורית chrome-aws-lambda (של alixaxel) הוצאה משימוש ונשברת ב-Node 18 ומעלה. השתמשו ב-@sparticuz/chromium במקום — זו כרגע הבחירה הסטנדרטית המתוחזקת.
כמה זיכרון Puppeteer צריך על AWS Lambda? 1024MB הוא המינימום המעשי; 1536–2048MB זה הטווח שבו הביצועים כבר מרגישים נוחים. מתחת ל-1024MB, צפו לביצוע איטי באופן מורגש, כי Lambda קושרת את הקצאת ה-CPU לזיכרון.
איך מקטינים את זמני ה-cold start של Puppeteer ב-Lambda? מקצים יותר זיכרון (מה שנותן גם יותר CPU), שוקלים Provisioned Concurrency אם השהיה קריטית למקרה השימוש שלכם, ושומרים את חבילת הפריסה קלה ככל האפשר — כל תלות נוספת מוסיפה זמן ל-cold start.
