כמעט כל רשימת "הסקרייפר בקוד פתוח הטוב ביותר" סובלת מפגם שקט אחד: אף אחד לא מריץ את הכלים על אותם דפים. Scrapy נבדק על כתבת חדשות, Playwright על הדגמה של מסחר אלקטרוני, Colly על מה שהיה למחבר במקרה בהישג יד — ואז מדרגים אותם זה מול זה, כאילו המספרים האלה באמת נמדדו על אותו הדבר. הדירוג הזה מספר לכם משהו על הדפים, לא על הכלים.
אז עשיתי את הדבר המשעמם והמתבקש שהרשימות מדלגות עליו. בניתי סט אחד של fixtures והעברתי דרכו את כל תשעת הכלים: קטלוג סטטי, קטלוג שמוצג ב-JavaScript, כתבה שקבורה בתוך זבל של ניווט ו-footer, שגיאת HTTP 500 מכוונת, גרף קטן של סריקת קישורים פנימיים, ועוד שני אתרי תרגול ציבוריים. אותה אמת קרקעית, אותן מדידות, כל ריצה וריצה. הסקריפטים והפלט הגולמי יושבים ב-מאגר benchmark ציבורי אחד, כך שתוכלו להריץ הכול בעצמכם. מה שחזר משם הוא לא לוח התוצאות המסודר שרשימות הסיכום מבטיחות — אין מנצח יחיד. יש שלוש עבודות שונות, והתשעה מתחלקים ביניהן כמעט מעצמם.
נסו את Thunderbit לחילוץ נתונים מהאינטרנט
איך בניתי את הספסל, ומה המגבלה היחידה שאומר בקול רם
כל כלי פגש בדיוק את אותן צורות של fixture: 12 מוצרים סטטיים שמפוזרים על פני שני דפים, 8 מוצרים שמוזרקים על ידי JavaScript אחרי השהיה, כתבה עטופה ב-boilerplate של ניווט ו-footer סביב שלוש פסקאות אמיתיות, שרת 500 מכוון, וגרף של קישורים פנימיים. זה מה שגורם לתוצאות להסתדר — "8/8 מוצרים דינמיים" אומר בדיוק אותו הדבר, בין אם Puppeteer או Crawlee יצרו את זה.
יש כאן גם גבול שרוב הסקירות מדלגות עליו. החבילה של כל כלי משקפת את אותם fixtures בגרסה שלו, ולכן ספירות התווים האבסולוטיות אינן בהכרח ניתנות להשוואה ישירה בין הכלים — קראו אותן כאותות בתוך הכלי עצמו, לא כציון בין כלים שונים. המדדים שכן ניתנים להשוואה הם recall (תחשבו עליו כשיעור הצלחה), מעבר או כשל ב-JavaScript, והתנהגות מבנית. ויש עוד הערת היקף באותו רוח: הריצה של Crawl4AI על הקטלוג הסטטי כללה רק את הדף הראשון, ולכן 6/6 אצלו הוא recall מלא על חתך צר יותר, בעוד שהכלים האחרים סרקו את שני הדפים עבור 12/12 — היקף קטן יותר, לא פספוס חלקי. ההסבר המלא, fixture אחרי fixture, נמצא ב-מסמך המתודולוגיה.
ועוד הסתייגות לפני המספרים. כל חבילה נושאת גם ציון מחקרי זמני, אבל בכוונה אני לא מציג אותם כטבלה מדורגת. הם שימשו אותי פנימית כדי לבדוק כל כלי מול הראיות שלו, לא כליגת אלופים — ופרסום שלהם ככאלה היה משחזר בדיוק את בעיית הדיוק-לכאורה-מזויף שהניסוי הזה נועד למנוע. זו סינתזה של מה שהספסל הראה, לא לוח תוצאות.
כל השדה, על ספסל אחד
קראו למטה את שתי העמודות בטבלה — "מייצר JS?" ו"תור סריקה מובנה" — ותראו איך שלוש העבודות מתבהרות כמעט לבד.
| כלי | שפה | מייצר JS? | recall בסטטי | פלט מובנה | תור סריקה מובנה | משקל התקנה | רישיון |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | כן (דפדפן) | 6/6 (דף 1) | סכמת CSS | BFS/DFS מובנים | כבד (2 ערימות דפדפן) | Apache-2.0 |
| Firecrawl | מארח-עצמי | כן (playwright-service) | Markdown מלא | כן | /v1/crawl | הכבד ביותר (6 קונטיינרים) | AGPL-3.0 |
| trafilatura | Python | לא | 3/3 פסקאות כתבה | לא (טקסט בלבד) | לא | קל | Apache-2.0 |
| Crawlee | Node/TS | אופציונלי לפי מנוע | 12/12 | דרך extraction | כן (RequestQueue) | בינוני (+~80 MiB) | Apache-2.0 |
| Playwright | Node/ריבוי | כן | 12/12 | ידני | לא (BFS שנכתב ידנית) | בינוני (דפדפן) | Apache-2.0 |
| Puppeteer | Node | כן (Chrome) | 12/12 | ידני | לא (BFS שנכתב ידנית) | בינוני (Chrome) | Apache-2.0 |
| Scrapy | Python | לא | 12/12 | ייצוא feed (JSON/CSV/XML) | כן (מובנה) | בינוני (תלויות Twisted) | BSD-3 |
| Colly | Go | לא | 12/12 | דרך callbacks | שליטת עומק | קל (בינארי אחד + Go) | Apache-2.0 |
| Scrapling | Python | לא (fetcher מבוסס HTTP) | 12/12 | כן | לא | בינוני ([fetchers]) | BSD-3 |
הערה על המטאדאטה בטבלה, וגם בכל מה שמופיע בהמשך: מספרי כוכבים וגרסאות צולמו בתחילת יולי 2026, ושניהם משתנים מהר. כדאי לרענן אותם מול דפי GitHub והחבילות של כל פרויקט לפני שמתייחסים אליהם כמעודכנים.
אינדקס הסקירות לכל כלי בנפרד
לכל פרויקט ברשימה הזאת יש סקירה עמוקה משלו:
- סקירת Crawl4AI
- סקירת Firecrawl
- סקירת trafilatura
- השוואה בין Playwright ל-Puppeteer
- סקירת Crawlee
- סקירת Scrapy
- סקירת Colly
- סקירת Scrapling
הנה השערים שלהם — ועוד שני צילומי מסך אמיתיים ממבחן הרינדור ב-JavaScript, כדי שטענת ה-"8/8 דינמי" לא תהיה רק מספר על הדף.
עבודה ראשונה: להפוך דף לטקסט מוכן ל-LLM
אם מה שאתם צריכים הוא Markdown נקי להזנה לצינור RAG, שלושה כלים מתחרים — והם פשוט לא יכולים להיות שונים יותר זה מזה.
Crawl4AI הוא, מתחת לשיווק, מחולל Markdown שמבוסס על דפדפן. שווה לנפץ את סיפור ה-"adaptive intelligence self-learning selector" שמלווה אותו בתוצאות החיפוש: אין בו דבר כזה — זה טריק של ספרייה אחרת לגמרי (עוד נגיע לזה כשנגיע ל-Scrapling). אבל מה שהוא באמת עושה, הוא עושה טוב. באתר Books to Scrape הוא הפיק 13,476 תווים של Markdown, הוא יודע לבצע חילוץ מבוסס CSS schema עבור שליפות מובנות, וה-BFS המובנה שלו לסריקה עמוקה עבר על 5 דפים בגרף הסריקה תוך רינדור של דף JavaScript וצילום מסך. אבל יש גם שתי נקודות חולשה ברורות. ה-Markdown הגולמי שלו נושא את ה-boilerplate של הדף אלא אם מפעילים פילטר תוכן, וה-500 המכוון חזר כ-success=false — לא כי Crawl4AI זיהה יפה את שגיאת ה-HTTP, אלא כי ההיוריסטיקה שלו בחנה את גוף השגיאה הקטן וסימנה אותו כ-minimal_text ... blocked. וההתקנה מוסיפה לדיסק שני סטים של דפדפנים. גרסה 0.9.0, Apache-2.0, בערך 71 אלף כוכבים נכון לתחילת יולי.
Firecrawl הוא הכבד של החבורה, והאחסון העצמי שלו באמת עובד — אני אומר "באמת" כי ערימת ששת הקונטיינרים (api, playwright-service, redis, rabbitmq, nuq-postgres ו-foundationdb) אכן עלתה ויצרה 9,222 תווים של Markdown מוכן ל-LLM מאותו עמוד Books to Scrape. הוא רינדר דף JavaScript דרך ה-playwright-service המובנה, וציטוט איינשטיין שמוזרק אחרי הסקריפט הופיע בפלט, מה שהוכיח שהרינדור היה אמיתי. שתי תקלות שפגשתי היו באשמת הסביבה, לא באשמת Firecrawl, ואני רוצה לדייק כדי שאף אחד לא יעתיק את התיקון הלא נכון: build מתוך קוד המקור נתקל בתקלה אקראית של containerd snapshotter תחת colima (עברתי לתמונות המוכנות מראש), ותחום ה-DNS של colima ב-198.18.x.x הפעיל את מנגנון ה-SSRF guard של Firecrawl, שאותו ניקיתי עם ALLOW_LOCAL_WEBHOOKS=true — פתרון זמני לפיתוח מקומי, לא משהו שמשביתים בפריסה אמיתית. גם לליבה המארחת-עצמית חסר Fire-engine, שכבת האנטי-חסימה בענן, ולא בדקתי את ה-API בענן. הדגל המשמעותי יותר הוא הרישיון: הליבה המארחת-עצמית של Firecrawl היא AGPL-3.0, וזה שיעורי בית משפטיים אמיתיים לפני כל שימוש מסחרי, לא הערת שוליים. כ-148 אלף כוכבים בתחילת יולי.
trafilatura הוא החריג בקבוצה, וזה הכלי שרשימות ההייפ של AI שוכחות שוב ושוב. בלי דפדפן. בלי שורות מובנות. רק טקסט נקי ומהיר של כתבות, ב-Python טהור. על ה-fixture של הכתבה הוא חילץ את הכותרת יחד עם כל 3 מתוך 3 הפסקאות האמיתיות, הסיר לגמרי את ה-boilerplate — שום "Login", "Subscribe" או "Copyright" לא דלף החוצה — וגם שחזר את המחבר והתאריך. בעמוד מוצר ציבורי הוא החזיר 1,324 תווים של טקסט נקי. המגבלה שלו היא בדיוק מה שהעיצוב שלו מרמז: תנו לו קטלוג והוא יחזיר 12 שמות מוצרים כטקסט אבל 0 שורות מובנות — הטקסט שם, המבנה לא, והוא לא מרנדר JavaScript. גרסה 2.1.0 (הגרסה הנוכחית), Apache-2.0, בערך 6.2 אלף כוכבים. לחילוץ כתבות טהור, זה הראשון שהייתי שולח אליו יד.
שתי ספירות התווים ב-Markdown — 13,476 מ-Crawl4AI, 9,222 מ-Firecrawl — הגיעו מאותו עמוד ציבורי, אבל אל תקראו בהן פער איכות. הן משקפות אסטרטגיות Markdown שונות (כמה מעטפת דף כל כלי שומר), לא פסק דין מי עדיף. זה בדיוק כלל ה-"אות בתוך הכלי" מהקודם, שמתגלה כאן בשטח.
עבודה שנייה: לרנדר JavaScript בצורה אמינה
יש נתונים שפשוט לא נמצאים ב-HTML עד שהסקריפטים רצים, וברגע הזה דפדפן אמיתי מפסיק להיות מותרות. שלושה כלים מכסים את המשימה הזו — ושניים מהם התבררו כמעט ככלי זהה.
Playwright ו-Puppeteer סיימו בתיקו על כל בדיקה שהטסתי עליהם. שניהם רינדרו 8/8 מוצרים דינמיים ב-fixture המקומי ו-10 באתר Quotes JS הציבורי, שניהם הגיעו ל-12/12 ב-recall הסטטי, ושניהם התמודדו יפה עם ה-500 (Puppeteer מחזיר response object במקום לזרוק חריגה). אף אחד מהם לא מגיע עם תור סריקה, אז בשניהם היה צריך לכתוב BFS ידני כדי לעבור על גרף הקישורים של 12 העמודים. ההבדל היחיד שבאמת נשאר הוא היקף: Playwright מניע Chromium, Firefox ו-WebKit ומדבר Python ו-.NET, בעוד Puppeteer הוא קודם כול Chrome וב-Node בלבד. שתי הבהרות, כי הגרסאות כאן זזות מהר: בדקתי את Playwright 1.56.0 מול גרסה עדכנית 1.61.1, והפעלתי רק Chromium; ואת Puppeteer 24.16.0 מול גרסה עדכנית 25.3.0 — לכן כדאי להריץ מחדש או להוריד משקל בהתאם. שניהם Apache-2.0; בערך 92 אלף ו-95 אלף כוכבים בהתאמה.
Crawlee הוא זה שפותר את בעיית התור שהשניים האחרים משאירים פתוחה. הוא עוטף מנוע Cheerio (HTTP) ומנוע Playwright (דפדפן) מאחורי API אחד, והניגוד על אותו דף הוא כל הפיץ': מנוע Cheerio ראה 0 פריטים שהוזרקו ב-JavaScript, מנוע Playwright ראה את כולם 8/8 ב-local (ו-10 באתר הציבורי), והמעבר ביניהם הוא שינוי של שורה אחת. הוא גם נותן לכם RequestQueue אמיתי, וזה מה שמקנה לו מקום בעבודה הזו ולא בעבודה השלישית. הקאץ' שאף אחד לא כותב בכותרת: מנוע הדפדפן דורש npx playwright install נפרד, בערך 80 MiB ש-npm install crawlee לא מוריד בשבילכם. גרסה 3.17.0, TypeScript, Apache-2.0, סביב 24.6 אלף כוכבים.
עבודה שלישית: לסרוק מהר בלי דפדפן
כשאין JavaScript בדף, דפדפן הוא בזבוז כבד. כאן מתחרים שלושה כלים מבוססי HTTP, אחד לכל פילוסופיית שפה, והם לא מסכימים על הכול — וזה דווקא מעניין.
Scrapy הוא הכלי ברמת ההנדסה של החבורה — spiders, ייצוא feed ל-JSON/CSV/XML, AutoThrottle, הכול. הוא הגיע ל-12/12 ב-recall הסטטי, חילץ את 3/3 הפסקאות של הכתבה, עבר על 11 דפים בעומק 0–2 בגרף הסריקה, ותפס את ה-500 דרך handle_httpstatus_list. אבל תפיסת העולם שלו היא החלק המעניין: הוא לא מרנדר, הוא משחזר את הבקשה. כששולחים אותו לדף JavaScript הוא קיבל 0 nodes — ואז ה-JSON API שמאחוריו החזיר לו 8/8. זו הפילוסופיה של Scrapy במשפט אחד: למצוא את הבקשה שהדף עצמו שולח ולשחזר אותה, לא לנהוג דפדפן. המחיר הוא stack של תלויות לא קטן (Twisted, lxml, parsel), ובדקתי אותו רק מול fixtures קטנים. גרסה 2.17.0, BSD-3-Clause, בערך 63 אלף כוכבים.
Colly היא התשובה של Go, והיא גלויה באופן מרענן לגבי מה שהיא: בינארי סטטי אחד, מונחה callbacks דרך OnHTML, OnResponse, ו-OnError, עם שליטה בעומק. היא קלעה ל-12/12 ב-recall הסטטי, חילצה 8/8 מה-JSON API דרך OnResponse, תפסה את ה-500 דרך OnError, והגיעה ל-17 דפים בסריקה בעומק 2 — ואני אומר בדיוק כך, כי מספר הדפים הזה הוא מונה של ה-harness עצמו, לא הבטחת שלמות ש-Colly נותנת. מה שהיא לא עושה הוא JavaScript: ה-fixture הדינמי ואתר Quotes JS חזרו שניהם כ-0, במכוון. תצטרכו toolchain של Go כדי לבנות אותה, וגרסת המודול (v2.3.0) רצה כרגע לפני ה-release המתויג (v2.2.0). Apache-2.0, בערך 25 אלף כוכבים.
Scrapling הוא המומחה, והוא בהחלט מצדיק את התואר. ה-adaptive selectors שלו בנויים כדי למצוא מחדש אלמנט אחרי שה-Markup זז — ולכן כששיניתי במחלקת ה-HTML של יעד מ-product-name ל-product-title, סלקטור רגיל מצא 0, ואילו ה-adaptive re-match שחזר את האלמנט שעוקבים אחריו בכל זאת. בשליפה רגילה ב-HTTP הוא הגיע ל-12/12 בסטטי ול-8/8 ב-JSON API. והנה החלק שהדוקומנטציה שלו לא מסתירה: במבחן סינתטי עם כמה אלמנטים הוא שחזר 1 מתוך 3 — זו עמידות במעקב אחר אלמנט, לא התאוששות כוללת, אז לא להפריז בזה בראש. גם ההתקנה הבסיסית pip install scrapling דורשת את התוספת [fetchers] כדי להתחיל לעבוד, ו-StealthyFetcher הוא אזהרת תאימות, לא פיצ'ר שהייתי שם בשקופית. גרסה 0.4.10 (הגרסה הנוכחית), BSD-3-Clause, בערך 68.7 אלף כוכבים.
הדפוס שמסתתר מתחת לשלוש העבודות
שמים את התשעה זה לצד זה, ומשהו נקי יוצא החוצה. recall סטטי מלא — 12/12 שטוח — הוא תנאי בסיס לכל כלי HTTP-first; אף אחד מהם לא הסתבך במקרה הקל, אז זה לא מה שמבדיל ביניהם. כלי הדפדפן מצדיקים את המשקל הנוסף שלהם רק כש-JavaScript באמת בתמונה, וכולם משלמים על זה בהתקנה: ערימת דפדפנים, התקנה נוספת, או צי קונטיינרים שלם. ועמודת ה-"תור סריקה מובנה" היא בעצם הקו שמבדיל בין framework למנוע — Scrapy ו-Crawlee נותנים orchestration, בעוד Playwright ו-Puppeteer גורמים לכם לכתוב את ה-BFS בעצמכם. זה מבנה השדה. אין מנצח כולל, כי אף אחד לא משחק את אותו משחק.
אז מה באמת כדאי לבחור
הספסל מסרב להכתיר מנצח, כי התשובה הנכונה היא לא כלי — אלא שאלה: איזו משלוש העבודות אתם עושים?
- צריכים Markdown מוכן ל-LLM? לכו על trafilatura כשאתם צריכים טקסט נקי של כתבות, על Crawl4AI כשאתם רוצים גם חילוץ CSS וגם רינדור JavaScript באותה ספרייה, ועל Firecrawl כשאתם דווקא רוצים שירות מארח-עצמי ומוכנים לעבור גם את רישיון AGPL-3.0 וגם את המשקל של שישה קונטיינרים.
- צריכים JavaScript מרונדר? Playwright או Puppeteer לרינדור הגולמי — בחרו לפי מנוע ושפה, כי חוץ מזה זה תיקו — ו-Crawlee כשאתם גם רוצים orchestration של הסריקה בלי לכתוב הכול ידנית.
- סורקים דפים סטטיים או APIs שניתן לשחזר בקנה מידה גדול? Scrapy אם אתם רוצים framework מלא ב-Python, Colly אם אתם רוצים מהירות Go גולמית בבינארי יחיד, ו-Scrapling כשמה שמכאיב לכם הוא specifically markup drift חוזר ונשנה.
תתאימו את הכלי למשימה, וכל אחד מהם הוא בחירה הגיונית. קחו כלי מהקטגוריה הלא נכונה — כלי דפדפן לדפים סטטיים, או parser של HTTP לאפליקציית JavaScript — וגם הספרייה הכי מדורגת באינטרנט תאכזב אתכם.
איפה API מנוהל של AI נכנס לתמונה
כל כלי למעלה הוא חינמי, בקוד פתוח, וניתן להרצה אצלכם. אבל זו גם הפשרה המשותפת שהספסל הזה מבליט שוב ושוב: אתם הבעלים של סביבת הדפדפן, קוד הסריקה, מרוץ החימוש מול anti-bot, וכל התחזוקה. עבור הרבה צוותים, בדיוק זה הוא היתרון, ומפת הרישיונות חשובה כשנכנסים לזה — רוב השדה הוא permissive (Apache-2.0 ב-Crawl4AI, Crawlee, Playwright, Puppeteer ו-Colly; BSD-3 ב-Scrapy וב-Scrapling), כשהליבה המארחת-עצמית של Firecrawl ב-AGPL-3.0 היא היחידה שדורשת בדיקת רישיון אמיתית לפני שימוש מסחרי.
אבל שימו לב למה שהספסל גם מיפה: מה הכלים האלה לא עושים. רינדור, סריקה, מבנה, והסתובבות סביב חסימות — לעיתים נדירות הכול יחד, ובטח לא בלי תחזוקה מצדכם. API מנוהל ל-scraping מבוסס AI מקפל את כל הערימה הזו לקריאה אחת. הממשק המפתחים שלנו ב-Thunderbit הוא אחת האפשרויות שם, ולמשתמש טכני מה שחשוב הוא ה-API, שרת ה-MCP, וה-CLI — לא תוסף הדפדפן. POST /distill מחזיר Markdown נקי ו-POST /extract מחזיר JSON שמוגדר לפי schema, כשהרינדור של JavaScript וההגנות נגד חסימות מטופלים בצד השרת ולא במחשב שלכם. יש שרת MCP רשמי לסוכנים ולעוזרי קוד — thunderbit_suggest_fields רץ בחינם כדי לתכנן חילוץ, ואז thunderbit_distill (קרדיט 1) ו-thunderbit_extract (20 קרדיטים) עושים את העבודה — וגם CLI שאפשר למשוך עם npx @thunderbit/thunderbit-cli למשימות טרמינל ו-cron. למי שאינו מפתח בצוות יש גם תוסף Chrome ללא קוד, ו-התמחור מכסה את שני הממדים.
הפשרה היא אותה פשרה שהספסל הזה סובב סביבה כל הזמן: להפעיל ולתחזק עד תשע ספריות בעצמכם בלי עלות לכל קריאה, או להעביר את הצנרת הלאה ולשלם לפי בקשה. אף אחת מהבחירות לא שגויה. הכול תלוי בכמה מה-stack אתם באמת רוצים להחזיק אצלכם. אם תרצו לראות איך החילוץ נראה בפועל, ערוץ ה-YouTube של Thunderbit מדגים את זה.
{{INTERNAL_BLOG_LINKS}}
מסקנה
אין סקרייפר בקוד פתוח אחד שהוא הטוב ביותר, וכל רשימה שמגישה לכם בביטחון אחד כזה, מסתירה בשקט את השאלה שבאמת מכריעה: איזו משלוש העבודות אתם עושים? להפוך דף לטקסט, לרנדר JavaScript, או לסרוק מהר בלי דפדפן — השדה מתחלק יפה לקבוצות האלה, ובתוך כל אחת הבחירה תלויה בשפה ובמשקל ההתקנה, לא באלוף אוניברסלי.
אם לוקחים הרגל אחד מכל זה, קחו את זה: תבדקו על הדפים שלכם לפני שאתם מתחייבים לכלי. כל מספר כאן ניתן לשחזור ב-מאגר ה-benchmark בדיוק מהסיבה הזו — כי הכלי שמוביל ברשימת סיכום כללית והכלי ששורד את היעדים האמיתיים שלכם הם לא תמיד אותו כלי.
נסו את Thunderbit לחילוץ נתונים מהאינטרנט Get Started Free
שאלות נפוצות
מהו הסקרייפר בקוד פתוח הטוב ביותר? אין אחד כזה — זה תלוי במשימה. לטקסט מוכן ל-LLM, trafilatura או Crawl4AI; לרינדור JavaScript, Playwright, Puppeteer או Crawlee; לסריקת HTTP מהירה, Scrapy או Colly. על ספסל בדיקה משותף, כל כלי היה חזק במיוחד בתוך הקטגוריה שלו וחלש יותר מחוצה לה, ולכן דירוגים של "אחד שמתאים לכולם" מטשטשים את התמונה.
אילו סקרייפרים בקוד פתוח מרנדרים JavaScript? Crawl4AI, Firecrawl, Playwright, Puppeteer, וגם מנוע ה-Playwright של Crawlee מרנדרים JavaScript. Scrapy, Colly, trafilatura, וה-fetcher ברירת המחדל של Scrapling אינם מרנדרים — הם או צריכים API שניתן לשחזר מאחורי הדף (זו הגישה של Scrapy, שהחזירה 8/8 מה-endpoint של JSON) או מצב דפדפן נפרד.
האם אני צריך headless browser כדי לסרוק אתר? רק אם הנתונים מופיעים אחרי הרצת JavaScript. אם בקשת HTTP רגילה יחד עם parser יכולה להגיע לתוכן, דפדפן הוא פתרון יקר ומיותר — Scrapy, Colly או Scrapling יהיו קלים ומהירים הרבה יותר למקרה כזה.
לאיזה מהכלים יש את הרישיון הידידותי ביותר לשימוש מסחרי? רובם permissive: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) או BSD-3-Clause (Scrapy, Scrapling). החריג הוא הליבה המארחת-עצמית של Firecrawl, שהיא AGPL-3.0, ולכן דורשת בדיקת רישיון רצינית לפני שבונים עליה מוצר מסחרי.
האם מספרי ה-benchmark האלה ניתנים לשחזור? כן. כל runner, fixture ותוצאה גולמית נמצאים במאגר ציבורי תחת רישיון MIT. רק הסתייגות אחת שחשוב לזכור: recall ותוצאות מבניות ניתנים להשוואה בין הכלים, אבל ספירות תווים אבסולוטיות הן אותות בתוך הכלי בלבד, כי כל חבילה משקפת את ה-fixtures במקום לשתף עותק קנוני אחד — לכן השוו שיעורי הצלחה ו-pass/fail, לא את סך התווים הגולמי.
