אם מחפשים את "Colly", כמעט תמיד מופיע אותו תיאור ראשון: מהיר. סורק Go מהיר, מהיר כי הוא מתקמפל, מהיר כי אין דפדפן שמעכב אותו. כמעט אף אחד לא מצמיד לזה מספרים.
אז החלטתי לא להסתפק בסיסמא. הקמתי אתר בדיקה קטן, הרכבתי את Colly מולו, ובדקתי מה הספרייה באמת עושה — עד כמה היא מחזירה נתונים מדפים אמיתיים, איך היא מטפלת בבקשה שנכשלה, ועד כמה זחילה עם מגבלת עומק באמת מתפשטת. בשורה התחתונה, לפני שנצלול למספרים: חילוץ סטטי חזר עם כיסוי מלא, שגיאת 500 נחתה בדיוק במקום הנכון, וזחילה עם מגבלת עומק הגיעה ל־17 עמודים מתוך קובץ בינארי סטטי יחיד, בלי שום דפדפן מחובר. הספרייה גם החזירה אפס נקי בכל מה שתלוי ב־JavaScript — וזה בדיוק החלק שלרוב נעלם כשמדברים על "מהירות".
מה Colly באמת הוא — ומה הוא לא
Colly מציגה את עצמה כ־"מסגרת אלגנטית ל־scraping ול־crawling עבור Golang", והמשפט הקצר הזה חשוב הרבה יותר ממה שנדמה. זו ספריית Go — בערך ~25.4k כוכבים נכון ל־2026-07-09 ב־gocolly/colly, עם רישיון Apache-2.0. זה לא כלי שורת פקודה שמורידים ומכוונים ל־URL. כותבים Go, מייבאים את החבילה, מחברים כמה callbacks, ומתקמלים לקובץ הרצה אחד.
המודל המנטלי הוא מודל מונע־אירועים, וזה בדיוק מה שמבלבל אנשים שמגיעים מעולם של request-and-parse. לא עוברים תגובה שורה־שורה ושולפים שדות. מחברים handlers ל־Collector, והספרייה מפעילה אותם תוך כדי סריקת הדפים. OnHTML מריץ את קוד החילוץ בכל פעם שיש selector תואם ב־CSS. OnResponse נותן את גוף התגובה הגולמי, וזה חשוב כשהמטען הוא JSON ולא HTML. OnError תופס בקשות שנפלו. גם הזחילה עובדת כך: בתוך handler של קישורים קוראים ל־Visit() על ה־URLs שמצאתם, Colly מכניסה אותם לתור, ו־MaxDepth קובע כמה רחוק מותר לה להסתובב. callbacks, תור ביקורים, מגבלת עומק, קובץ סטטי מקומפל. בלי interpreter, בלי runtime, בלי headless Chrome שרק יושב בזיכרון.
מודל ה־callback, ולמה הוא משנה את החוויה של החילוץ
ה־callbacks הם כל האישיות של הכלי, ולכן שווה לעצור עליהם רגע. שלושה מהם ליוו כל בדיקה שהרצתי.
OnHTML(selector, handler) הוא זה שתשתמשו בו הכי הרבה. מגדירים אותו על .product או article p, ו־Colly מפעילה את ה־handler פעם אחת לכל אלמנט תואם בזמן שה־DOM מפוענח. כאן יושב חילוץ מובנה, וזה גם נוח לקריאה — מתארים מה רוצים, לא את הלולאה שמגרדת את זה החוצה.
OnResponse(handler) יושב שכבה מתחת ונותן את הבייטים הגולמיים מהחוט. כשיעד מחזיר JSON במקום markup, בכלל לא נוגעים ב־DOM — מפענחים את הגוף בעצמכם. ה־callback הזה הוא הסיבה ש־Colly טיפלה ב־JSON API בהרצה שלי בלי לנתח אפילו שבריר HTML.
OnError(handler) הוא ה־callback שכולם שוכחים ממנו עד ש־scraper נופל ב־3 בלילה. הוא מופעל כשבקשה נכשלת ונותן לכם את התגובה, כדי שתוכלו לקרוא את קוד הסטטוס ולהחליט מה עושים הלאה. crawler שבולע תקלות בשקט גרוע יותר מזה שנופל בקול; Colly לא עושה אף אחד מהשניים, וזה משמעותי הרבה יותר ממה שזה נשמע כשמריצים אותה בלי השגחה.
עוד שני מאפיינים יושבים מעל ה־callbacks האלה ומשפיעים תפעולית. MaxDepth מגביל את הזחילה, כך שה־collector שעוקב אחרי קישורים עוצר אחרי שני צעדים במקום לטייל ברחבי הרשת. ופלט הבנייה הוא קובץ Go סטטי אחד — מתקמלים פעם אחת, מקבלים קובץ יחיד בלי תלויות ריצה, זורקים אותו לשרת או ל־CI, ומריצים. אם אי פעם איבדתם אחר צהריים שלם על virtualenv של Python במכונה חדשה, זה נשמע יותר כמו יתרון מאשר הערת שוליים.
התקנה — שרשרת הכלים של Go שאף אחד לא מזכיר
סיפור התלויות קצר, אבל יש בו נקודת חיכוך אחת אמיתית, אז הנה היא לפני שמתקינים משהו. על המכונה שבדקתי לא היה Go בכלל, ו־Colly היא ספריית Go, לכן השלב הראשון היה להתקין toolchain על המחשב — התקנתי Go 1.26.5 דרך Homebrew. אם הצוות שלכם לא חי כבר בתוך Go, זה החיכוך האמיתי. לא הספרייה. סביבת השפה שנדרשת לפני ששורה אחת בכלל תתקמפל.
אחרי שה־Go היה מותקן, הבאת Colly הייתה נקייה. go get github.com/gocolly/colly/v2 פתר ל־v2.3.0 בלי דרמה — בלי דפדפן, בלי headless, בלי שום דבר מעבר לקובץ המתקמפל בסוף. בהשוואה ל־scrapers של Python שמתקינים parser ואז קורסים בניסיון הראשון בגלל שרשרת של extras חסרים, זה היה משעמם בצורה נעימה. "משעמם" כאן הוא מחמאה.
הערת דיוק אחת, במפורש, כי היא בהחלט תבלבל אם תתחילו לחפור. המודול האחרון ב־Go proxy הוא v2.3.0, שפורסם בדצמבר 2025. הגרסה המתויגת החדשה ביותר ב־GitHub היא v2.2.0, ממרץ 2025. כלומר, הקוד שבדקתי — v2.3.0 — מתקדם ממה שמופיע בעמוד Releases של המאגר. זו תוצאה של האופן שבו Go modules ו־GitHub tags נפרדים זה מזה לאורך זמן, לא סימן שמשהו מקולקל. פשוט אל תיבהלו כשתראו ש־go get ועמוד Releases מספרים מספרים שונים.
בדיקה מעשית — המספרים מאחורי "מהיר"
הרצתי את Colly מול שרת בדיקה עצמאי שנבנה על httptest של Go, וגם מול שני אתרי דמו ציבוריים, כך שההתנהגות ניתנת לשחזור ולא רק סיפור שאני מספר. הנה מה שחזר.
| בדיקה | יעד | תוצאה |
|---|---|---|
| קטלוג סטטי + חלוקה לעמודים | fixture מקומי | 12/12 מוצרים, כיסוי 1.0 |
| חילוץ מאמר | fixture מקומי | כותרת + 3/3 פסקאות |
| API דינמי ב־JSON | fixture מקומי | 8/8 פריטים דרך OnResponse, כיסוי 1.0 |
| טיפול ב־HTTP 500 | fixture מקומי | הועבר ל־OnError, סטטוס 500 |
גרף זחילה (MaxDepth 2) | fixture מקומי | 17 עמודים |
| Books to Scrape | דמו ציבורי | 20 מוצרים |
| עמוד דינמי (ללא JS) | fixture מקומי | 0 כרטיסים (כצפוי) |
| Quotes JS (ללא רינדור) | דמו ציבורי | 0 (כצפוי) |
אם קוראים את זה מלמעלה למטה, התמונה מסתדרת. החילוץ הסטטי היה נקי — 12 מתוך 12 מוצרים מהקטלוג, כל שלוש הפסקאות מהמאמר, והכול מונע על ידי selectors של OnHTML. בדיקת ה־JSON API אפילו לא פתחה parser של HTML: OnResponse העבירה את הגוף, אני פענחתי אותו, ו־8 מתוך 8 פריטים חזרו. בדיקת ה־500 היא זו שעליה אני נשען הכי חזק, כי היא הקו שבין crawler שאפשר להשאיר לרוץ כל הלילה לבין כזה שאי אפשר — Colly העבירה את הכשל ל־OnError והציגה את הסטטוס בצורה נקייה, בלי קריסה ובלי נפילה שקטה. על דמו ציבורי של Books to Scrape היא שלפה 20 מוצרים בלי טיפול מיוחד.
תוצאת הזחילה היא הכותרת, וחשוב לי לנסח אותה בזהירות. collector עם MaxDepth(2), שעוקב אחר קישורים וממיר אותם ל־absolute URLs, הגיע ל־17 עמודים בתוך גרף ה־fixture שלי. זה סוף סוף מצמיד את המשפט "סורק Go מהיר" למספר עמודים ממשי ולא לתחושה כללית. אבל חשוב לשים לב לניסוח — 17 עמודים בזחילה עם עומק 2. מספר העומק שם הוא מונה של סביבת הבדיקה שלי, שמסביר איך הוגדרה ההרצה; אני לא טוען ש־Colly מבטיחה פנימית "בדיוק עומק 2, ולא קישור אחד מעבר" כ־contract. האמירה המדויקת והניתנת לאימות היא זו: עם מגבלת עומק של 2, הזחילה עברה על הגרף והגיעה ל־17 עמודים.
ועכשיו לתקרה, המקום שבו לרוב הפוסטים על "זה כל כך מהיר" משתתקים. Colly לא מריצה JavaScript. כיוונתי אותה על fixture שמרונדר ב־JavaScript וקיבלתי 0 כרטיסים; כיוונתי אותה לעמוד Quotes to Scrape JS הציבורי וקיבלתי שוב 0. זה לא באג וזה לא חיסרון מפתיע. Colly היא crawler מבוסס HTTP — היא מורידה HTML ומנתחת אותו, אבל לעולם לא מעלה דפדפן כדי להריץ סקריפטים בצד הלקוח. כמו Scrapy ו־HTTP-first crawlers אחרים, אם התוכן שאתם מחפשים קיים רק אחרי ש־JavaScript רץ, Colly תחזיר לכם ריק בכל פעם, ושום מהירות גולמית לא תשנה את זה. צריך לחבר אותה ל־renderer, או לבחור כלי שמגיע עם כזה מובנה.
אני גם רוצה להיות כן לגבי מה לא בדקתי, כדי שאף אחד לא ימתח את המסקנות מעבר לראיות. לא בדקתי את ה־async collector, את תצורת rate limiting והנימוס, את rotation של proxyים, או את backends של queue ו־storage. כל אלה קיימים ב־Colly. אני בדקתי את ליבת החילוץ והזחילה, לא את שכבת ההרחבה לקנה מידה. ה־README מתהדר בתפוקה של יותר מאלף בקשות בשנייה על ליבה אחת, אבל זה הנתון של הפרויקט עצמו — אני מדדתי מספרי עמודים וכיסוי, לא throughput, כך שכאשר אני אומר "מהיר" אני מתכוון לנתיב החילוץ של Go מקומפל שבאמת בדקתי, לא לבנצ'מרק מול Scrapy שלא הרצתי.
יתרונות וחסרונות
יתרונות:
- כיסוי מלא בחילוץ סטטי — 12/12 מוצרים מהקטלוג ו־3/3 פסקאות מהמאמר דרך
OnHTML. - טיפול נקי ב־JSON דרך
OnResponse, בלי צורך בניתוח DOM — 8/8 פריטי API. - ניתוב שגיאות נכון — ה־500 הגיע ל־
OnErrorעם הסטטוס גלוי, בלי קריסה. - זחילה עם מגבלת עומק הגיעה ל־17 עמודים מתוך collector יחיד.
- קובץ Go סטטי אחד, בלי תלויות ריצה — פרופיל פריסה ותפעול מצוין.
- רישיון Apache-2.0 מקל ונוח לשימוש מסחרי.
חסרונות:
- אין הרצה של JavaScript — תוכן שמרונדר בצד הלקוח מחזיר 0, נקודה.
- צריך Go toolchain; צוותים שלא כבר עובדים ב־Go משלמים על ההקמה הזו לפני כתיבת scraper אחד.
- המודול האחרון (
v2.3.0) מתקדם לפני הגרסה המתויגת החדשה ביותר (v2.2.0), מה שיכול לבלבל כל מי שמסתכל על עמוד Releases. - הפלט הוא הקוד שלכם — Colly נותנת callbacks, לא dataset מוכן או exporter מובנה כמו ל־Scrapy.
- קיימים async, rate limiting, proxy ו־queue backends, אבל הם לא נבדקו כאן; "מהיר" הוא נתיב החילוץ שמדדתי, לא מספר throughput ראש בראש.
למי Colly מתאימה — ומי עדיף שיוותר
Colly מתאימה אם אתם כבר כותבים ב־Go ומבצעים crawling לאתרים מבוססי HTML או JSON במהירות. אם בעיניכם פריסה נקייה היא להעתיק קובץ בינארי אחד למכונה ולהריץ — בלי interpreter, בלי virtualenv, בלי רולטת תלויות — הכלי הזה נבנה בדיוק בשביל הגישה הזו. מודל ה־callback משתלם ברגע שהחילוץ מפסיק להיות טריוויאלי: OnHTML למבנה, OnResponse ל־payload גולמי, OnError לתקלות שאחרת לא הייתם רואים. עבור יעד סטטי או API שמריצים בלו״ז מתוך CI, זה פתרון חזק ונטול דרמה.
עדיף לעקוף אותו, או לפחות לחבר אליו כלי שני, כשהיעדים נשענים על JavaScript. Colly החזירה 0 בכל עמוד שמרונדר בצד הלקוח ששמתי מולה, וזה מכוון, לא הגדרה שאפשר להדליק או לכבות. כדאי לעקוף אותה גם אם הצוות שלכם לא נוגע ב־Go ואתם לא רוצים להקים toolchain רק כדי לגרד כמה אתרים — המחויבות לשפה היא אמיתית, והיא שלכם לתחזק. ואם אתם רוצים לקבל נתונים מובנים במקום לנתח אותם בקוד שכתבתם, ה־callbacks של Colly מעבירים את העבודה הזו לצד שלכם של המגרש.
חלופות — איפה נכנסת API מנוהלת לחילוץ עם AI
Colly היא ספרייה חינמית ופתוחה שאתם מקמפלים ומריצים בעצמכם. אתם מחזיקים את קוד ה־Go, את ה־callbacks, את לוגיקת הזחילה ואת המכונה שעליה היא רצה — ובתמורה לא משלמים לכל בקשה ושומרים את כל התהליך אצלכם. עבור צוותי Go, זו תשובה הגיונית, והפריסה בקובץ יחיד באמת נעימה.
שני המקומות שבהם זה נעצר הם בדיוק המקומות ששווה להשוות מול משהו אחר. ראשית, JavaScript — Colly לא מרנדרת אותו, כך שכל מה שתלוי בלקוח נשאר מחוץ למשחק אלא אם מחברים דפדפן. שנית, מבנה — Colly נותנת callbacks ומשאירה את עיצוב הפלט הנקי לקוד שלכם. API מנוהלת לחילוץ בעזרת AI עונה על שני אלה אחרת. ה־developer stack של Thunderbit מטפל ברינדור של JS ומחזיר נתונים מובנים בצד השרת. POST /distill הופך עמוד ל־Markdown נקי ומוכן ל־LLM, עם תוכן דינמי והגנות anti-bot שמטופלות עבורכם. POST /extract מחזיר JSON מובנה לפי JSON Schema שאתם מגדירים, עם renderMode שאפשר להעלות עד רינדור מלא בדפדפן כשעמוד דורש זאת. יש גם שרת Thunderbit MCP לסוכני AI ולעוזרי קוד — thunderbit_suggest_fields חינמי, כך שאפשר לבדוק אילו שדות עמוד חושף לפני שמתחייבים — וגם CLI שאפשר להריץ עם npx @thunderbit/thunderbit-cli עבור הטרמינל, CI ו־cron.
נסו את Thunderbit לחילוץ נתוני רשת
הפשרה היא לא טוב מול רע. השאלה היא איפה העבודה מתבצעת. עם Colly אתם משאירים את הרינדור, הניתוח והתחזוקה בתוך הקובץ הבינארי המקומפל שלכם, בלי עלות לכל קריאה, ומתחזקים אותה בעצמכם כשהאתר משתנה. עם API מנוהלת אתם מעבירים הלאה את רינדור ה־JS, ההגנות נגד בוטים והפלט המובנה, ומשלמים לפי שימוש על הזכות הזו. יעדים קטנים, ילידיי Go, מבוססי HTML או JSON, שאתם שמחים להחזיק ולתחזק? השליטה והמהירות של Colly מנצחות חד־משמעית. עמודים עתירי JavaScript, או פשוט העדפה לקבל JSON מובנה לפי סכימה במקום לכתוב עוד callback? זה המקרה למעבר למסלול המנוהל. אם רוצים לראות את התמונה הרחבה יותר, הסיכומים של best web scraping tools ושל best web scraping GitHub projects ממקמים איפה ספרייה כמו Colly עומדת לצד הכלים מבוססי הדפדפן והפתרונות המנוהלים.
פסק דין
אז האם כדאי להשתמש ב־Colly? כן — אם אתם כותבים ב־Go ומבצעים crawling של HTML או JSON במהירות, היא עושה בדיוק את מה שהמוניטין של "fast crawler" מבטיח, והפעם יש גם מספרים מאחורי המוניטין. כיסוי מלא בחילוץ סטטי. JSON נקי דרך OnResponse. שגיאת 500 שנשלחה כראוי ל־OnError. זחילה בעומק 2 שהגיעה ל־17 עמודים. כל זה מקומפל לקובץ בינארי סטטי אחד ללא תלויות ריצה, שזה בערך סיפור הפריסה הכי נוח בכל הקטגוריה הזו.
אבל צריך להגדיר את הטענות בצורה כנה. היא לא מרנדרת JavaScript — כל עמוד צד־לקוח בהרצה שלי החזיר 0, וזה קבוע, לא הגדרה שפיספסתם. היא דורשת Go toolchain, כך שצוותים שלא עובדים ב־Go משלמים מס הקמה מראש. המודול שאתם מתקינים (v2.3.0) מתקדם לפני הגרסה המתויגת החדשה ביותר (v2.2.0), אז אל תיכנסו לפאניקה כשהעמודים לא מסכימים ביניהם. ו־"מהיר" כאן אומר את נתיב החילוץ שמדדתי, לא benchmark של throughput שלא הרצתי. בתוך הקווים האלה, Colly היא crawler מהיר, אמין, באמת ניתן לפריסה, ב־Go — והיא עומדת במוניטין שלה ברגע שמפסיקים לבקש ממנה להריץ JavaScript.
נסו את Thunderbit לחילוץ נתוני רשת Get Started Free
שאלות נפוצות
האם Colly באמת מהירה, והאם יש לזה מספר? כן, במה שחשוב לנתיב הליבה שבדקתי: Go מקומפל, כיסוי מלא בחילוץ סטטי (12/12 מוצרים מהקטלוג), טיפול נקי ב־JSON, וזחילה בעומק 2 שהגיעה ל־17 עמודים — הכול מתוך קובץ בינארי סטטי אחד. מה לא הרצתי הוא benchmark של throughput מול Scrapy, אז צריך לקרוא ל־"מהירה" כאל התנהגות חילוץ שנמדדה, לא כציון מהירות ראש בראש.
האם Colly יכולה לגרד עמודים שמרונדרים ב־JavaScript? לא. Colly היא crawler מבוסס HTTP — היא מורידה HTML ומנתחת אותו, אבל לא מריצה דפדפן. fixture שמרונדר ב־JavaScript החזיר 0 כרטיסים, וגם עמוד Quotes JS הציבורי החזיר 0. עבור תוכן בצד לקוח תצטרכו לחבר ל־renderer או להשתמש בכלי שמגיע עם רינדור דפדפן מובנה.
האם צריך לדעת Go כדי להשתמש ב־Colly?
כן. Colly היא ספריית Go, לא CLI עצמאי — מייבאים אותה, רושמים callbacks (OnHTML, OnResponse, OnError), ומתקמלים. במכונה שבדקתי לא היה Go, ולכן ההקמה התחילה מהתקנת toolchain (1.26.5). אם הצוות שלכם לא כבר עובד ב־Go, זו עלות ההקמה האמיתית.
למה הגרסה שאני מתקין לא תואמת את ה־GitHub release האחרון של Colly?
כי ה־Go module ותג הגרסה ב־GitHub התפצלו זה מזה. המודול האחרון ב־Go proxy הוא v2.3.0 (דצמבר 2025), בעוד שהתג המתויג החדש ביותר ב־GitHub הוא v2.2.0 (מרץ 2025). בדקתי את v2.3.0. זו תופעה של modules מול tags, לא התקנה שבורה.
האם Colly חינמית לשימוש מסחרי? כן, היא תחת Apache-2.0, רישיון מקל ונוח לשימוש מסחרי. כמו תמיד, מומלץ לאמת את הרישיון העדכני ב־repo לפני שבונים עליו.
