רוב האנשים נתקלים ב-Crawlee דווקא כשהם מנסים לענות על שאלה אחרת: "איזה דפדפן headless כדאי לי להשתמש בו?" אבל זו לא השאלה הנכונה — ו-Crawlee הוא בדיוק הסיבה. הוא לא דפדפן. זו מסגרת Node/TypeScript שמפעילה דפדפן כשצריך, ומדלגת עליו כשלא.
במשך כמה ימים הרצתי את Crawlee 3.17.0 על סט מבוקר של fixtures ועל כמה אתרי דמו ציבוריים, ב-Node v22.22.3 וב-macOS. ההבטחה המרכזית — ספרייה אחת, API אחד, ומתחתיו או סורק HTTP או דפדפן אמיתי — היא בדיוק מה שרציתי לבדוק לעומק, כי זו השאלה שקובעת אם Crawlee שווה מקום בסטאק שלך או שכדאי פשוט לעבוד עם Playwright ישירות. בשורה התחתונה: סיפור שני המנועים אכן מחזיק, עם כמה הסתייגויות שאגיע אליהן.
מה Crawlee באמת עושה — ומה לא
Crawlee מציג את עצמו כספריית web scraping ואוטומציית דפדפן ל-Node.js, שנבנתה כדי ליצור סורקים אמינים. ה-מיצוב הרשמי רחב מאוד: חילוץ נתונים ל-AI, LLMs, RAG או GPTs; הורדת HTML, PDF, JPG, PNG וקבצים נוספים; עבודה עם Puppeteer, Playwright, Cheerio, JSDOM ו-HTTP גולמי; מצב headful או headless; וסבב פרוקסי מובנה. זה המון כיסוי, ולכן חשוב גם לומר מה Crawlee לא.
הוא לא מנוע רינדור. אין לו דפדפן משלו. כשצריך להריץ JavaScript, Crawlee מפעיל את Playwright או Puppeteer, ואלו בתורם מפעילים את Chromium (או דפדפן אחר). הוא גם לא שירות מתארח שמדברים איתו ברשת — זו תלות שמתקינים ומריצים בעצמכם. מה שכן, Crawlee כן הוא השכבה שמעל ה-fetcher: מחלקות הסריקה, תור הבקשות, האחסון, והלוגיקה של מעקב אחרי קישורים. תחשבו עליו כמסגרת סריקה, עם חריץ למנוע מתחלף מתחתיה.
למען הסר ספק, הגרסה שבדקתי הייתה 3.17.0 (שוחררה ב-2026-06-04), היא מבוססת TypeScript, הרישיון הוא Apache-2.0, ונכון ל-2026-07-09 הריפו עמד בערך על 24.6k כוכבים ב-apify/crawlee. ספירת הכוכבים משתנה — הריפו קיבל 53 כוכבים ביומיים שבהם עקבתי אחרי העניין — אז כדאי להתייחס למספר הזה כאל תמונת מצב ולא כעובדה קבועה.
שני המנועים: CheerioCrawler מול PlaywrightCrawler
כאן העיצוב באמת מוכיח את עצמו, ופה ביליתי את רוב הזמן.
CheerioCrawler הוא הנתיב מבוסס ה-HTTP. הוא מושך HTML גולמי מהרשת ומנתח אותו באמצעות Cheerio — בלי דפדפן, בלי הרצת JavaScript, בלי רינדור. הוא מהיר וזול. PlaywrightCrawler הוא נתיב הדפדפן. הוא מפעיל Chromium אמיתי, מרנדר את הדף כולל כל מה ש-JavaScript בונה לתוך ה-DOM, ואפילו יכול לצלם צילומי מסך.
שני מנועים שונים עם יכולות שונות באמת. המסר של Crawlee הוא שהם לובשים את אותם בגדים. שניהם מקבלים requestHandler. שניהם חושפים run(). שניהם סורקים קישורים באמצעות enqueueLinks. המעבר ממנוע אחד לשני הוא החלפת מחלקה, לא כתיבה מחדש — אימתתי את זה בכך ששמרתי על לוגיקת החילוץ זהה לחלוטין, ורק החלפתי את מחלקת הסורק שעוטפת אותה.
חשוב לדייק בנקודה אחת, כי שם מסתיים השוויון: ידית התוכן שונה. בתוך handler של CheerioCrawler מקבלים $ — DOM סטטי שכבר נותח, שאותו שואלים כמו ב-jQuery. בתוך handler של דפדפן מקבלים אובייקט page חי. כלומר, התור, הניתוב, והצנרת של "שלח את הנתונים האלה, עקוב אחרי הקישורים האלה" נשארים זהים, אבל הקטע שבו קוראים בפועל את הדף משנה צורה. גם התיעוד של Crawlee אומר זאת במפורש — הממשק המשותף מוגבל לפעולות הסריקה, ואילו גישת התוכן היא החלק שמשתנה.
| מנוע | איך הוא מושך תוכן | מריץ JavaScript? | הרצה שלי (דף דינמי אחד) | מתאים במיוחד ל |
|---|---|---|---|---|
CheerioCrawler | HTTP גולמי + ניתוח עם Cheerio | לא | ~0.035 שנ׳ | HTML סטטי, APIs של JSON, מהירות |
PlaywrightCrawler | Chromium אמיתי דרך Playwright | כן | ~4.967 שנ׳ | דפים שמרונדרים ב-JavaScript, צילומי מסך |
הזמנים האלה מגיעים ממכונה אחת והרצה אחת — לא מבנצ'מרק, אלא מה שממחיש את הטרייד-אוף. נתיב הדפדפן עלה בערך בשני סדרי גודל יותר זמן על אותו URL. זה המחיר של רינדור, ולכן לא פונים אליו כברירת מחדל.
המבחן: אותו URL, 0 מול 8/8
הבטחות זה דבר זול. הסיבה שאני סומך על הסיפור של שני המנועים היא שהצלחתי לשבור אותו — ואז לתקן אותו — פשוט על ידי החלפת מחלקה אחת.
בניתי fixture דינמי מקומי — דף קטלוג שבו כרטיסי המוצרים מוזרקים על ידי JavaScript אחרי הטעינה, בדיוק מסוג הדפים שהפכו לברירת המחדל ברשת המודרנית. כיוונתי אליו את CheerioCrawler. התוצאה: 0 כרטיסי מוצר. זו לא תקלה; זה פשוט אופן הפעולה. Cheerio מעולם לא הריץ את ה-JavaScript, ולכן הכרטיסים בכלל לא נוצרו ב-HTML שהוא ניתח. אחר כך כיוונתי את PlaywrightCrawler לאותו URL בדיוק, בלי לשנות שום דבר אחר, והוא רנדר 8 מתוך 8 מוצרים וגם צילם מסך כהוכחה.
כדי לוודא שזה לא רק קיצור דרך של ה-fixture שלי, הרצתי את אותו דפוס גם על אתר ציבורי — דף הדמו של Quotes to Scrape, שבונה את הציטוטים בצד הלקוח. אותה תוצאה באותו כיוון: CheerioCrawler ראה 0 ציטוטים, ו-PlaywrightCrawler החזיר 10.
חשוב לי לדייק במה שהמבחן הזה מוכיח. זו שחזור נקי של טענה ש-Crawlee כבר מתעד — המסגרת כבר חולקת את אותה מחלקת בסיס ואת אותו ממשק בין סוגי הסורקים שלה מאז גרסה 3.0. לכן זו אימות, לא גילוי. אבל זה בדיוק הערך: הטענה השיווקית של "ממשק אחד, HTTP או דפדפן" היא אמיתית, והנה הקבלה של 0 → נתונים מלאים גם על fixture שבשליטתי וגם על אתר חיצוני.
איפה הנתיב של HTTP מנצח
קל מאוד לקרוא את הסעיף למעלה כ"תמיד להשתמש בדפדפן". אל תעשו את זה. כל הרעיון של העיצוב עם שני המנועים הוא שהדפדפן הוא מסלול גיבוי יקר, לא ברירת מחדל.
על תוכן סטטי, CheerioCrawler היה גם מדויק וגם מהיר. ה-fixture הסטטי של הקטלוג החזיר 12 מתוך 12 מוצרים בדיוק מלא, תוך מעקב אחרי פאג'ינציה באמצעות enqueueLinks({ selector: '.next-page' }), ובכ-0.155 שניות. דף מאמר החזיר כותרת ואת כל 3 מתוך 3 פסקאות הגוף, כששורות login/subscribe/copyright נפרדו יפה מהתוכן עצמו.
הנקודה הכי חשובה לזכור: דף שהנתונים שלו נטענים ב-JavaScript מחזיק לעיתים קרובות גם API של JSON מאחוריו. הנתונים של ה-fixture הדינמי שלי ישבו בנקודת קצה, וכשכיוונתי את CheerioCrawler ישירות אל ה-API הזה, הוא השיג 8 מתוך 8 מוצרים — בלי דפדפן, ובכ-0.035 שניות. אותם נתונים שנתיב הדפדפן לקח כמעט חמש שניות לרנדר. הלקח ישן אבל עדיין נכון: אם אפשר לשחזר את הבקשה הבסיסית, עדיף לעשות את זה במקום להפעיל Chromium. Crawlee מאפשר לבחור זאת לכל סורק בנפרד, בלי להחליף מסגרת.
החלק של מסגרת הסריקה — הסיבה לבחור ב-Crawlee ולא רק בספריית דפדפן
אם כל מה שהייתם צריכים הוא לרנדר דף אחד, לא הייתם צריכים את Crawlee — הייתם משתמשים ב-Playwright או Puppeteer לבד. מה שספריית דפדפן לבד לא נותנת לכם הוא סריקה של ממש: תור, מניעת כפילויות, שליטה בעומק, ו-retries. זה החלק ב-Crawlee שלא קשור למנועים בכלל.
הרצתי crawl בתוך אותו hostname, מהשורש של fixture, עם enqueueLinks ובקרת עומק. Crawlee עבר על 11 דפים לפי העומקים {0:1, 1:3, 2:7} — דף שורש אחד, שלושה דפים במרחק קפיצה אחת, ושבעה דפים במרחק שתי קפיצות — וגם כיבד את maxRequestsPerCrawl כתנאי עצירה. ה-RequestQueue טיפל בכל החשבונאות. כשכיוונתי בקשה לדף שהחזיר HTTP 500, Crawlee ניסה שוב ואז העביר את הכשל דרך failedRequestHandler במקום לבלוע אותו בשקט או להפיל את ההרצה.
זה הטיעון החזק ביותר לטובת Crawlee מול כלי דפדפן עצמאי: תזמור הסריקה מובנה, וחשוב מכך — הוא נשאר אותו תזמור גם כשהמנוע מתחתיו הוא HTTP או דפדפן. כותבים את לוגיקת התור והמעקב אחרי קישורים פעם אחת. אחר כך מחליטים בנפרד אם כל סורק ירנדר JavaScript.
התקנה וההורדה הנסתרת של הדפדפן
ההתקנה הייתה ברובה חלקה, עם מלכודת אחת שתיתפס למשתמשים בפעם הראשונה.
npm install crawlee playwright עבר נקי — בלי vulnerabilities. אבל PlaywrightCrawler לא יופעל עד שתריצו גם npx playwright install chromium, שמוריד קובץ Chromium בנפח של כ-81.7 MiB. התקנת חבילת crawlee לבדה לא מביאה דפדפן. אם מדלגים על השלב הזה וקופצים ישר לסורק דפדפן, תקבלו שגיאת הפעלה שלא מובנת מאליה אם לא מכירים כבר את מודל ההפצה של Playwright. זו התנהגות שירש Playwright, לא פגם ב-Crawlee, אבל זו נקודת חיכוך אמיתית בהרצה הראשונה שכדאי להדגיש.
עוד הערה תפעולית: כברירת מחדל Crawlee כותב לתיקיית storage/ מקומית. סביבת הבדיקה שלי הפנתה את זה לתיקיית temp זמנית וביטלה persistence כדי לשמור על ניקיון, אבל הרצה רגילה תשאיר תיקיית 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 לדפדפן — וזה בדיוק המקום שבו הייתם מצפים להם.
הגבול שחשוב לומר במפורש: לא הרצתי crawl חי עם PuppeteerCrawler. התלות האופציונלית puppeteer לא הותקנה בחבילת הבדיקה שלי, והרצה שלה הייתה מחייבת עוד הורדה של דפדפן. לכן השוויון עם Puppeteer אומת כאן מבנית — אותה מחלקת בסיס, אותן מתודות משותפות, ואותה צורת handler — ולא דרך הרצה בפועל. וגם כשממשק זהה, ההתנהגות שמתחתיו לא תמיד זהה לגמרי: ה-הנחיות של Crawlee עצמו מציינות ש-Playwright מחכה לאלמנטים אוטומטית בעוד Puppeteer מחייב המתנה מפורשת. זו תכונה של המנוע, לא תקלה ב-Crawlee — אבל זה אומר ש"אותו API" לא אומר "אותו קוד בכל handler".
מה לא בדקתי
הנה מה שבכוונה נשאר מחוץ למבחן הזה, כדי שלא תקראו את התוצאות שלי כרחבות יותר ממה שהן באמת.
- סקייל. הכול רץ על fixtures קטנים וסריקות קצרות של אתרים ציבוריים. לא הייתה הרצה ארוכה של 100–1,000 דפים, אז אני לא יכול להגיד הרבה על autoscaling או יציבות תחת עומס אמיתי.
- שמירת תור וחזרה לאחר עצירה. לא עצרתי crawl באמצע כדי לראות אם
RequestQueueממשיך בצורה נקייה אחרי קריסה. זו יכולת חשובה בהרצות ארוכות, והיא לא נבדקה כאן. - ייצוא של Dataset ו-KeyValueStore. כתבתי בעצמי את ייצואי ה-JSON/CSV בהארנס. את חוויית הייצוא המובנית של
Dataset/KeyValueStore— אולי היתרון הארגונומי המרכזי בשימוש במסגרת — לא בדקתי. - Proxy ו-pool של sessions. Crawlee כולל סבב פרוקסי ו-fingerprinting. אני מתייחס לזה אך ורק כנושא של תאימות ותפעול, לא כיתרון של "עקיפת anti-bot", וגם לא לחצתי על זה בשום כיוון.
וגם פה, כל הזמנים הם של מכונה אחת והרצה אחת. הם מראים את צורת העלות בין HTTP לדפדפן. הם לא בנצ'מרק, ולא הייתי מצטט אותם ככאלה.
יתרונות וחסרונות
יתרונות
- משטח API אחד לסריקה ב-HTTP ובדפדפן — המעבר בין מנועים באמת מתמצה בהחלפת מחלקה, והדבר אומת עם 0 → נתונים מלאים גם על fixture מקומי וגם על אתר ציבורי.
- מסגרת סריקה אמיתית:
RequestQueue,enqueueLinksעם שליטה בעומק, retries ו-failedRequestHandler, לא רק רנדר של דף. - חילוץ מדויק ב-HTTP (12/12 בקטלוג סטטי, 3/3 פסקאות במאמר, 8/8 דרך JSON API) כש-JavaScript לא מפריע.
- נתיב הדפדפן משחזר תוכן שה-HTTP פשוט לא יכול לראות, ויודע גם לצלם מסך.
- Apache-2.0, TypeScript, ומתוחזק באופן פעיל.
חסרונות
- סורקי הדפדפן דורשים
npx playwright install chromiumנפרד (~81.7 MiB), שהתקנתnpm install crawleeלא מטפלת בו — קל לפספס את זה. - רינדור דפדפן מוסיף עלות אמיתית לכל דף (~5 שנ׳ לעומת פחות משנייה במבחן הדף הבודד שלי).
- יצירה אוטומטית של תיקיית
storage/בהרצות רגילות. - סקייל, חזרה אחרי קריסה, וארגונומיית ייצוא של Dataset לא הוכחו בבדיקות שלי.
- צריך להשתמש ביכולות proxy ו-fingerprinting בהתאם לתנאי האתר ולחוק — זו אחריות, לא תכונה שאפשר להישען עליה סתם כך.
מתי לבחור ב-Crawlee לעומת API מנוהל
Crawlee הוא כלי שבונים איתו בעצמכם, וזה בדיוק מה שצוותים רבים צריכים. כדאי לבחור בו כשאתם רוצים להחזיק את הסורק בתוך קוד Node שלכם, לשלב סריקת HTTP ודפדפן באותו פרויקט בלי להחליף מסגרת, ולשלוט בעצמכם בתור ובאחסון. אם נוח לכם להפעיל ובסוף גם להרחיב צי דפדפנים, Crawlee נותן לכם שלד נקי ומעוצב היטב לבנות עליו.
המסלול השני הוא לא להפעיל את כל התשתית הזאת בעצמכם. אם טיפול ידני ב-Chromium, בפרוקסי וב-anti-bot לא אמור לגזול מכם זמן הנדסי, API מנוהל הוא האלטרנטיבה — וכאן נכנס ה-stack שלנו למפתחים ב-Thunderbit. למשתמשים טכניים, Thunderbit הוא לא רק תוסף כרום; הוא API ל-scraping מבוסס AI, שרת MCP, וגם CLI. אפשר לקרוא ל-POST /distill כדי להפוך דף ל-Markdown נקי שמוכן ל-LLM, או ל-POST /extract עם JSON Schema כדי לקבל נתונים מובנים בחזרה, עם renderMode של none, basic או full — כך אתם מחליטים מתי רינדור מלא של דפדפן באמת שווה את זה. שרת ה-MCP מאפשר לסוכן AI (כמו Claude, Cursor ולקוחות MCP אחרים) לבצע scraping תוך כדי משימה, וה-CLI רץ מהטרמינל או מ-CI:
נסו את Thunderbit לחילוץ נתוני אינטרנט
npx -y @thunderbit/thunderbit-cli distill "<url>" -f markdown > out.md
ההבדל שחשוב למפתחים: Crawlee נותן לכם את חומר הגלם — HTML מרונדר, nodes מפורשים — ואתם מחזיקים את הצינור; API מנוהל מחזיר JSON מובנה שתואם סכימה, עם רינדור JavaScript, CAPTCHA ו-anti-bot מטופלים בצד השרת. עבודות שונות. אם אתם רוצים שליטה מקסימלית ולא אכפת לכם מהתפעול — Crawlee. אם אתם רוצים את הנתונים בלי צי דפדפנים משלכם — המסלול המנוהל. לא מעט צוותים בסוף משתמשים בשניהם: אחד לסריקות מותאמות אישית, ואחד למקרים של "פשוט תביא לי את הנתונים המובנים". אפשר לראות את הפער בעלויות ב-התמחור של Thunderbit.
פסק דין
אז האם כדאי להשתמש ב-Crawlee? כן — אם אתם מפתחים ב-Node או TypeScript ורוצים מסגרת אחת שמכסה גם HTTP וגם סריקה מבוססת דפדפן, עם תור סריקה אמיתי מתחת. ההבטחה של שני המנועים היא הסיבה לבחור בו, והיא עמדה יפה במבחן שלי: אותו URL עבר מ-0 לנתונים מלאים בהחלפת מחלקה אחת, החילוץ הסטטי היה מדויק ומהיר, והסריקה עם תור ועומק עבדה בדיוק כפי שמתועד.
רק קחו בחשבון שני דברים. תקצבו את ההורדה הנסתרת של הדפדפן בפעם הראשונה שבה תשתמשו ב-PlaywrightCrawler, ואל תניחו שהחלקים שלא בדקתי — סקייל, חזרה אחרי קריסה, ייצוא מובנה — עובדים באותה רמה כמו החלקים שבדקתי, עד שתפעילו אותם על עומס העבודה שלכם. כבסיס לבניית סורק משלכם, Crawlee הוא יצירה הנדסית חזקה ומעוצבת היטב. כצינור נתונים מוגמר ואוטומטי לגמרי, הוא נקודת התחלה — לא היעד הסופי.
נסו את Thunderbit לחילוץ נתוני אינטרנט Get Started Free
שאלות נפוצות
האם Crawlee חינמי, ואיזה רישיון יש לו?
כן. Crawlee הוא קוד פתוח תחת רישיון Apache-2.0 ומתקינים אותו מ-npm באמצעות npm install crawlee. הגרסה שבדקתי הייתה 3.17.0. כדי להריץ את סורקי הדפדפן צריך גם הורדת Chromium נפרדת דרך Playwright — היא גם חינמית, אבל מוסיפה בערך 81.7 MiB להגדרה שלכם.
CheerioCrawler לעומת PlaywrightCrawler — במה כדאי לבחור?
בחרו ב-CheerioCrawler כשהנתונים נמצאים ב-HTML הגולמי או ב-API JSON בסיסי — הוא מהיר בהרבה ולעולם לא מפעיל דפדפן. בחרו ב-PlaywrightCrawler כשהתוכן נרנדר על ידי JavaScript, מה שאפשר לזהות כשנתיב ה-HTTP מחזיר תוצאות ריקות. בבדיקות שלי מנוע ה-HTTP החזיר 0 פריטים בדף שמרונדר ב-JavaScript, ואילו מנוע הדפדפן החזיר הכול. מכיוון שהם חולקים אותו API, המעבר ביניהם הוא החלפת מחלקה, לא כתיבה מחדש.
האם Crawlee צריך דפדפן כדי לפעול?
רק עבור סורקי הדפדפן. CheerioCrawler לא צריך דפדפן בכלל. PlaywrightCrawler (וגם PuppeteerCrawler) צריכים בינארי של דפדפן — מתקינים אותו עם npx playwright install chromium. שימו לב ש-npm install crawlee לבדו לא מוריד דפדפן, וזה כנראה מפח הנפוץ ביותר בהרצה הראשונה.
האם Crawlee יודע להתמודד עם pagination וסריקות רב-עמודיות?
כן, וזו אחת הסיבות המרכזיות לבחור בו על פני ספריית דפדפן עצמאית. enqueueLinks עוקב אחרי קישורים (כולל סלקטורים של pagination כמו .next-page), ה-RequestQueue מבטל כפילויות ומנהל את הסריקה, ויש לכם שליטה בעומק וגם הגבלת maxRequestsPerCrawl. בבדיקות, crawl בתוך אותו hostname עבר על 11 דפים בעומקים 0–2, ובקשות שנכשלו עלו דרך failedRequestHandler.
איך Crawlee משתווה ל-API scraping מתארח?
Crawlee הוא self-hosted: אתם כותבים ומריצים את הסורק, ואתם אחראים לסקייל, פרוקסי ו-anti-bot. API מנוהל כמו נקודות הקצה של Thunderbit ל-distill/extract מחזיר Markdown נקי או JSON מובנה שתואם סכימה, כשהרינדור והטיפול ב-anti-bot נעשים בצד השרת ונגישים דרך API, שרת MCP ו-CLI. בחרו ב-Crawlee כשאתם רוצים שליטה מלאה בצינור שלכם; בחרו ב-API מנוהל כשאתם מעדיפים לא להפעיל ולהרחיב תשתית דפדפנים בעצמכם.
