พอค้นคำว่า “Colly” คำที่มักเด้งขึ้นมาเป็นคำแรกแทบทุกครั้งคือ “เร็ว” — เป็น Go crawler ที่เร็ว, เร็วเพราะคอมไพล์ได้, เร็วเพราะไม่ต้องมีบราวเซอร์มาขวางทาง แต่กลับแทบไม่มีใครใส่ตัวเลขกำกับไว้เลย
ผมเลยเลิกเชื่อแค่คำบอกเล่า แล้วลงมือวัดจริง ผมตั้งเว็บตัวอย่างเล็ก ๆ ขึ้นมา คอมไพล์ Colly ให้ทำงานกับเว็บนั้น และดูว่าไลบรารีนี้ทำอะไรได้จริงบ้าง — ทั้งอัตราการดึงข้อมูลจากหน้าเว็บจริง วิธีรับมือเมื่อรีเควสต์ล้มเหลว และการไล่ลิงก์แบบจำกัดความลึกจะพาไปได้ไกลแค่ไหน สรุปสั้น ๆ ก่อนดูตัวเลข: การดึงข้อมูลแบบ static ให้ผลครบทุกชิ้น, รีเควสต์ 500 ถูกส่งไปยังจุดที่ควรเป็นอย่างแม่นยำ, และการ crawl แบบจำกัดความลึกไปได้ถึง 17 หน้า จากไฟล์ไบนารีตัวเดียวแบบไม่ต้องพึ่งบราวเซอร์ ที่สำคัญ ไลบรารียังตอบกลับเป็นศูนย์แบบเรียบร้อยกับทุกอย่างที่เรนเดอร์ด้วย JavaScript — ซึ่งพอดีเป็นส่วนที่คนชอบพูดว่า “เร็ว” มักจะข้ามไป
Colly คืออะไร และไม่ใช่อะไร
Colly นิยามตัวเองว่าเป็น “framework สำหรับ scraper และ crawler ที่สวยงามสำหรับ Golang” และประโยคเดียวนี้มีน้ำหนักมากกว่าที่เห็น นี่คือไลบรารี Go — ตอนนี้มีประมาณ ~25.4k stars ณ วันที่ 2026-07-09 บน gocolly/colly, ใช้สัญญาอนุญาต Apache-2.0 ไม่ใช่เครื่องมือบรรทัดคำสั่งที่ดาวน์โหลดมาแล้วชี้ไปที่ URL ได้เลย คุณต้องเขียน Go, import แพ็กเกจ, ต่อ callback หลายตัวเข้าด้วยกัน แล้วคอมไพล์ออกมาเป็น executable ตัวเดียว
โมเดลการทำงานเป็นแบบ event-driven ซึ่งเป็นจุดที่คนที่คุ้นกับการ request แล้ว parse มักจะงง คุณไม่ได้วนอ่าน response แล้วดึง field ออกมาทีละบรรทัด แต่คุณผูก handler เข้ากับ Collector แล้วปล่อยให้ไลบรารีเรียกใช้ตอนมันไล่ผ่านหน้าเว็บ OnHTML จะรันโค้ดดึงข้อมูลทุกครั้งที่เจอ CSS selector ที่ตรงกัน OnResponse จะส่ง body ดิบมาให้คุณ ซึ่งสำคัญมากเมื่อ payload เป็น JSON ไม่ใช่ HTML OnError จะจับรีเควสต์ที่พัง ส่วนการ crawl ก็ทำงานในลักษณะเดียวกัน: ภายใน handler ของลิงก์ คุณเรียก Visit() ไปยัง URL ที่พบ Colly จะคิวไว้ และ MaxDepth จะเป็นตัวกำหนดว่ามันไปได้ลึกแค่ไหน Callback, คิวการ visit, depth limit, คอมไพล์เป็น static ไม่มี interpreter, ไม่มี runtime, ไม่มี headless Chrome มานั่งกินหน่วยความจำ
โมเดล callback และทำไมมันถึงเปลี่ยนความรู้สึกเวลาทำ extraction
Callback คือบุคลิกหลักของเครื่องมือนี้เลย จึงควรอธิบายให้ชัดหน่อย สามตัวนี้คือสิ่งที่ใช้ในทุกการทดสอบของผม
OnHTML(selector, handler) คืออันที่คุณจะใช้บ่อยที่สุด ผูกไว้กับ .product หรือ article p แล้ว Colly จะเรียก handler ของคุณหนึ่งครั้งต่อ element ที่ match ระหว่างที่มัน parse DOM ตรงนี้คือที่อยู่ของ structured extraction และอ่านแล้วเข้าใจง่าย — คุณบอกว่าต้องการอะไร ไม่ได้บอกลูปที่ใช้ดึงมันมา
OnResponse(handler) อยู่ชั้นล่างลงมาอีกระดับ และส่ง bytes ดิบจากเครือข่ายมาให้ เมื่อปลายทางคืน JSON แทน markup คุณไม่ต้องแตะ DOM เลย — แค่ unmarshal body ด้วยตัวเอง Callback เดียวนี้แหละที่ทำให้ Colly รับมือกับ JSON API ในรอบทดสอบของผมได้ โดยไม่ต้อง parse HTML สักบรรทัด
OnError(handler) คือ callback ที่ทุกคนมักลืม จนกระทั่ง scraper ดับตอนตีสาม มันจะทำงานเมื่อรีเควสต์ล้มเหลว และส่ง response มาให้คุณดู status code แล้วตัดสินใจต่อได้ crawler ที่เงียบและกลืนความล้มเหลวหายไปเลย แย่กว่าตัวที่ล้มดัง ๆ เสียอีก Colly ไม่ทำทั้งสองแบบ และนั่นสำคัญกว่าที่คิดเวลาให้มันทำงานแบบไม่มีคนเฝ้า
ยังมีอีกสองฟีเจอร์ที่อยู่เหนือ callback พวกนี้และสำคัญในเชิงใช้งานจริง MaxDepth ใช้จำกัดความลึกของ crawl ทำให้ collector ที่ไล่ลิงก์หยุดแค่สองชั้นแทนที่จะตระเวนทั้งเว็บ และ output ที่คอมไพล์ออกมาคือ static Go binary ตัวเดียว — คอมไพล์ครั้งเดียว ได้ไฟล์เดียว ไม่มี runtime dependencies เอาไปวางบนเซิร์ฟเวอร์หรือใช้ใน CI job ได้เลย ถ้าคุณเคยเสียเวลาครึ่งวันกับ Python virtualenv บนเครื่องใหม่ ๆ รูปแบบการ deploy แบบนี้จะดูเป็นข้อดี ไม่ใช่แค่หมายเหตุ
การตั้งค่า — toolchain ของ Go ที่ไม่มีใครพูดถึง
เรื่อง dependency นั้นสั้น แต่มีจุดสะดุดจริงอยู่จุดเดียว ผมขอพูดไว้ก่อนติดตั้งอะไรเลย เครื่องที่ผมทดสอบไม่มี Go ติดตั้งอยู่ Colly เป็นไลบรารี Go ดังนั้นขั้นตอนแรกคือใส่ toolchain เข้าไปในเครื่อง — ผมติดตั้ง Go 1.26.5 ผ่าน Homebrew ถ้าทีมของคุณไม่ได้อยู่ฝั่ง Go อยู่แล้ว นี่แหละคือแรงเสียดทานจริง ไม่ใช่ตัวไลบรารี แต่เป็นสภาพแวดล้อมภาษา ที่ต้องมีตั้งแต่ก่อนจะคอมไพล์บรรทัดแรก
พอมี Go แล้ว การดึง Colly ก็ง่าย go get github.com/gocolly/colly/v2 ไปจบที่ v2.3.0 แบบไม่มีปัญหา — ไม่มีบราวเซอร์ ไม่มี headless อะไรทั้งนั้น มีแค่ binary ที่คอมไพล์เสร็จท้ายสุด เอาไปเทียบกับ Python scraper ที่ต้องลง parser แล้วพังทันทีตอน fetch ครั้งแรกเพราะขาด extras บางตัว เจ้านี่กลับน่าเบื่ออย่างสบายใจ ซึ่งในที่นี้ “น่าเบื่อ” คือคำชม
มีข้อสังเกตเล็กน้อยที่ควรบอกตรง ๆ เพราะถ้าคุณไปขุดเองจะงงแน่นอน module ล่าสุดบน Go proxy คือ v2.3.0 ที่เผยแพร่ในเดือนธันวาคม 2025 แต่ release ที่ถูก tag ล่าสุดบน GitHub คือ v2.2.0 จากเดือนมีนาคม 2025 ดังนั้นโค้ดที่ผมทดสอบ — v2.3.0 — ใหม่กว่าหน้า Releases ของ repository นี่เป็นลักษณะเฉพาะของช่วงเวลาที่ Go modules กับ GitHub tags ค่อย ๆ แยกทางกัน ไม่ได้แปลว่ามีอะไรผิดพลาด แค่ตอน go get กับหน้า Releases แสดงเลขคนละชุด ก็อย่าเพิ่งตกใจ
ลงมือทดสอบ — ตัวเลขที่อยู่เบื้องหลังคำว่า “เร็ว”
ผมรัน Colly กับ fixture server ที่สร้างด้วย httptest ของ Go เอง รวมถึง demo site สาธารณะอีกสองแห่ง เพื่อให้ผลที่ได้ตรวจสอบซ้ำได้ ไม่ใช่แค่เรื่องเล่าที่ผมแต่งขึ้น นี่คือผลลัพธ์
| การทดสอบ | เป้าหมาย | ผลลัพธ์ |
|---|---|---|
| แคตตาล็อกแบบ static + pagination | fixture ในเครื่อง | สินค้า 12/12 ชิ้น, recall 1.0 |
| ดึงข้อมูลบทความ | fixture ในเครื่อง | title + ย่อหน้า 3/3 |
| JSON API แบบ dynamic | fixture ในเครื่อง | 8/8 รายการผ่าน OnResponse, recall 1.0 |
| จัดการ HTTP 500 | fixture ในเครื่อง | ส่งไปที่ OnError, status 500 |
กราฟการ crawl (MaxDepth 2) | fixture ในเครื่อง | 17 หน้า |
| Books to Scrape | demo สาธารณะ | 20 สินค้า |
| หน้า dynamic (ไม่เรนเดอร์ JS) | fixture ในเครื่อง | 0 การ์ด (เป็นผลที่คาดไว้) |
| Quotes JS (ไม่เรนเดอร์) | demo สาธารณะ | 0 (เป็นผลที่คาดไว้) |
ถ้าอ่านจากบนลงล่าง ภาพมันค่อนข้างชัด การดึงข้อมูลแบบ static ทำงานสะอาด — สินค้า 12 จาก 12 ชิ้นจากแคตตาล็อก และย่อหน้าบทความครบทั้ง 3 ย่อหน้า ทุกอย่างถูกขับเคลื่อนด้วย selector ของ OnHTML การทดสอบ JSON API ไม่ได้เปิด HTML parser เลย: OnResponse ส่ง body มาให้ ผม unmarshal แล้วได้ข้อมูลครบ 8 จาก 8 รายการ ส่วนการทดสอบ 500 คืออันที่ผมให้ความสำคัญที่สุด เพราะมันเป็นเส้นแบ่งระหว่าง crawler ที่ปล่อยรันข้ามคืนได้ กับตัวที่ปล่อยไม่ได้ Colly ส่งความล้มเหลวไปที่ OnError และแสดง status อย่างชัดเจน ไม่มี crash ไม่มีการกลืนข้อผิดพลาดเงียบ ๆ บน demo สาธารณะ Books to Scrape มันดึงสินค้าออกมาได้ 20 ชิ้น โดยไม่ต้องมีการจัดการพิเศษ
ผลการ crawl คือหัวข้อใหญ่ และผมอยากพูดให้รอบคอบหน่อย collector ที่ตั้ง MaxDepth(2) แล้วตามลิงก์พร้อม resolve เป็น absolute URL สามารถไปได้ถึง 17 หน้า บนกราฟ fixture ของผม นี่คือประโยคที่ทำให้คำว่า “Go crawler ที่เร็ว” มีตัวเลขรองรับเสียที แทนที่จะเป็นแค่ความรู้สึก แต่ต้องอ่านถ้อยคำให้ดี — 17 หน้า ภายใต้การ crawl แบบ depth-2 ตัวเลขความลึกตรงนี้คือ counter ที่ผมใช้ใน test harness เพื่อบอกวิธีตั้งค่าการรัน ผมไม่ได้อ้างว่า Colly รับประกันภายในว่า “ต้อง depth 2 พอดี ห้ามเกินหนึ่งลิงก์” เป็นสัญญา สิ่งที่พูดได้แบบตรวจสอบได้คือ: เมื่อจำกัด depth ไว้ที่ 2 การ crawl สามารถไล่กราฟและไปถึง 17 หน้า
แล้วนี่คือเพดาน ซึ่งเป็นจุดที่โพสต์ประเภท “มันเร็วมาก” มักเงียบ Colly ไม่ได้รัน JavaScript ผมยิงมันไปที่ fixture ที่เรนเดอร์ด้วย JavaScript แล้วได้การ์ดกลับมา 0 ใบ; พอส่งไปที่หน้า Quotes to Scrape JS page สาธารณะก็ได้ 0 อีกครั้ง นี่ไม่ใช่บั๊ก และไม่ใช่ข้อด้อย Colly เป็น HTTP crawler — มันดาวน์โหลดและ parse HTML และไม่เคยเปิดบราวเซอร์เพื่อรันสคริปต์ฝั่ง client เลย เช่นเดียวกับ Scrapy และ crawlers แบบ HTTP-first ตัวอื่น ๆ ถ้าเนื้อหาที่คุณต้องการมีอยู่หลังจาก JavaScript ทำงานเท่านั้น Colly ก็จะส่งผลลัพธ์ว่างกลับมาเรื่อย ๆ และความเร็วอย่างเดียวไม่ช่วยให้เส้นนั้นขยับได้ ถ้าจำเป็นต้องใช้ renderer ก็ต้องต่อมันเพิ่ม หรือเลือกเครื่องมือที่มีตัวเรนเดอร์ในตัว
ผมขอพูดตรง ๆ ด้วยว่าอะไรที่ ไม่ได้ ทดสอบ เผื่อไม่ให้ใครเอาผลลัพธ์ไปขยายเกินหลักฐาน ผมไม่ได้ทดสอบ async collector, การตั้งค่า rate limiting และ politeness, proxy rotation หรือ queue และ storage backend ต่าง ๆ ฟีเจอร์เหล่านี้มีอยู่ใน Colly จริง ผมทดสอบเฉพาะแกน extraction และ crawl ไม่ใช่โครงสร้างสำหรับ scale-out README โฆษณาว่าผ่าน throughput ได้มากกว่าพัน requests ต่อวินาทีบน single core แต่ตัวเลขนั้นเป็นของโปรเจ็กต์เอง ผมวัด page count กับ recall ไม่ได้วัด throughput ดังนั้นเวลาผมพูดว่า “เร็ว” ผมหมายถึงเส้นทางการดึงข้อมูลที่คอมไพล์ด้วย Go ซึ่งผมทดสอบจริง ไม่ใช่ benchmark เทียบกับ Scrapy ที่ผมยังไม่ได้รัน
ข้อดีและข้อเสีย
ข้อดี:
- ดึงข้อมูล static ได้ครบ — สินค้า 12/12 ชิ้น และย่อหน้าบทความ 3/3 ย่อหน้าผ่าน
OnHTML - จัดการ JSON ได้สะอาดผ่าน
OnResponseไม่ต้อง parse DOM — รายการ API 8/8 - ส่งความล้มเหลวไปถูกทาง — 500 ถูกส่งเข้า
OnErrorพร้อม status แสดงครบ ไม่มี crash - crawl แบบจำกัดความลึกไปได้ 17 หน้า จาก collector ตัวเดียว
- static Go binary ตัวเดียว ไม่มี runtime dependencies — เด่นมากในแง่การ deploy และ operation
- ใช้สัญญาอนุญาต Apache-2.0 ซึ่งค่อนข้างเป็นมิตร
ข้อเสีย:
- ไม่รัน JavaScript — เนื้อหาที่เรนเดอร์ฝั่ง client ได้ผลเป็น 0 แบบชัดเจน
- ต้องมี Go toolchain; ทีมที่ไม่ได้ใช้ Go อยู่แล้วต้องจ่ายต้นทุนการตั้งค่านี้ก่อนเขียน scraper
- module ล่าสุด (
v2.3.0) ใหม่กว่าระดับ release ที่ tag ล่าสุดบน GitHub (v2.2.0) ซึ่งจะทำให้คนที่ดูหน้า Releases งงได้ - output คือโค้ดของคุณเอง — Colly ให้ callback มา แต่ไม่ได้มี dataset หรือ feed exporter ในตัวแบบ Scrapy
- async, rate-limiting, proxy และ queue backend มีอยู่ แต่ผมไม่ได้ทดสอบในครั้งนี้; คำว่า “เร็ว” จึงหมายถึงเส้นทาง extraction ที่ผมวัดจริง ไม่ใช่ตัวเลข throughput แบบเทียบกันตรง ๆ
Colly เหมาะกับใคร — และใครควรข้าม
Colly เหมาะถ้าคุณเขียน Go อยู่แล้ว และกำลัง crawl เว็บไซต์ที่ขับเคลื่อนด้วย HTML หรือ JSON แบบเร็ว ถ้าคำจำกัดความของการ deploy ที่สะอาดสำหรับคุณคือ “คัดลอกไฟล์ไบนารีตัวเดียวลงเครื่องแล้วรัน” — ไม่ต้อง interpreter, ไม่ต้อง virtualenv, ไม่ต้องลุ้น dependency — เครื่องมือนี้ถูกสร้างมาเพื่อแนวทางนั้นโดยตรง โมเดล callback คุ้มค่าทันทีเมื่อการดึงข้อมูลของคุณไม่ได้ง่ายอีกต่อไป: OnHTML สำหรับโครงสร้าง, OnResponse สำหรับ payload ดิบ, OnError สำหรับความล้มเหลวที่ไม่งั้นคุณจะไม่เห็น สำหรับเป้าหมายแบบ static หรือ API-backed ที่คุณ crawl ตามตารางจาก CI มันเป็นตัวเลือกที่แข็งแรงและไม่วุ่นวาย
ควรข้ามมัน หรืออย่างน้อยต้องต่อเครื่องมืออีกตัวเสริมไว้ เมื่อเป้าหมายของคุณพึ่ง JavaScript หนัก ๆ Colly ให้ผลเป็น 0 กับทุกหน้าที่ต้องเรนเดอร์ฝั่ง client ในการทดสอบของผม และนั่นเป็นการออกแบบ ไม่ใช่ค่าตั้งที่ปรับได้ ข้ามมันด้วยถ้าทีมของคุณไม่ได้แตะ Go และคุณไม่อยากตั้ง toolchain เพียงเพื่อ scrape ไม่กี่เว็บ เพราะข้อผูกมัดกับภาษาเป็นของจริงและคุณต้องดูแลมันเอง และถ้าคุณอยากได้ structured data ส่งมาให้พร้อมใช้งาน แทนที่จะให้โค้ดของคุณเป็นคน parse เอง callback ของ Colly ก็โยนภาระนั้นมาฝั่งคุณเต็ม ๆ
ทางเลือกอื่น — ตรงไหนที่ managed AI scraping API เข้ามาเหมาะกว่า
Colly เป็นไลบรารีโอเพ่นซอร์สฟรีที่คุณคอมไพล์และรันเอง คุณเป็นเจ้าของโค้ด Go, callback, logic ของการ crawl และเครื่องที่มันรันอยู่ — แลกกับการที่คุณไม่ต้องจ่ายต่อ request และเก็บทุกอย่างไว้ในระบบของคุณเอง สำหรับทีม Go นี่เป็นคำตอบที่สมเหตุสมผล และการ deploy แบบไฟล์เดียวก็ใช้งานสบายจริง
จุดที่มันหยุดคือสองจุดที่ควรเอาไปเทียบกับอีกทางเลือกหนึ่ง จุดแรกคือ JavaScript — Colly ไม่เรนเดอร์มัน ดังนั้นอะไรที่อยู่ฝั่ง client จะถูกตัดทิ้ง เว้นแต่คุณจะต่อบราวเซอร์เข้าไปเอง จุดที่สองคือโครงสร้างข้อมูล — Colly ให้ callback มา และปล่อยให้การจัด output ให้สะอาดเป็นเรื่องของโค้ดคุณเอง managed AI scraping API ตอบสองเรื่องนี้ต่างออกไป Thunderbit ฝั่ง developer stack รองรับการเรนเดอร์ JS และส่ง structured data กลับมาจากฝั่งเซิร์ฟเวอร์ POST /distill เปลี่ยนหน้าเว็บให้เป็น Markdown ที่สะอาดและพร้อมให้ LLM ใช้งาน โดยจัดการ dynamic content และ anti-bot ให้คุณ POST /extract ส่งคืน JSON ที่มีโครงสร้างตาม JSON Schema ที่คุณกำหนด และมี renderMode ให้ปรับขึ้นไปถึง full browser rendering เมื่อหน้าต้องการ Thunderbit ยังมี MCP server สำหรับ AI agents และ coding assistants — thunderbit_suggest_fields ใช้ได้ฟรี เพื่อให้คุณลองสำรวจว่าหน้านั้นเปิดเผยอะไรออกมาก่อนตัดสินใจ และยังมี CLI ที่รันได้ด้วย npx @thunderbit/thunderbit-cli สำหรับ terminal, CI และ cron
ลองใช้ Thunderbit สำหรับการดึงข้อมูลเว็บ
ทางเลือกไม่ได้อยู่ที่ว่าอันไหนดีกว่ากัน แต่มันอยู่ที่งานไปอยู่ตรงไหน ถ้าใช้ Colly คุณจะเก็บการเรนเดอร์ (ซึ่งไม่มี), parsing และการบำรุงรักษาไว้ใน binary ที่คอมไพล์เอง ทั้งหมดโดยไม่มีค่าใช้จ่ายต่อการเรียก และคุณต้องคอยดูแลเมื่อเว็บเปลี่ยนโครงสร้าง ถ้าใช้ managed API คุณจะส่งต่อเรื่องการเรนเดอร์ JS, anti-bot และ structured output ให้เขาจัดการ แล้วจ่ายเงินต่อการเรียกเพื่อความสะดวกนั้น เป้าหมายเล็ก ๆ ที่ native กับ Go, มี HTML หรือ JSON เป็นฐาน และคุณยินดีดูแลเอง? Colly ชนะทั้งในแง่การควบคุมและความเร็ว ถ้าเป็นหน้าเว็บที่พึ่ง JavaScript หนัก หรือคุณแค่อยากได้ JSON ที่มี schema พร้อมใช้ แทนที่จะเขียน callback เพิ่มอีกตัว นั่นคือเหตุผลที่ควรไปทาง managed route ถ้าอยากเห็นภาพรวมที่กว้างกว่านี้ บทสรุป best web scraping tools และ best web scraping GitHub projects จะช่วยวางตำแหน่งของไลบรารีอย่าง Colly เมื่อเทียบกับตัวที่ใช้บราวเซอร์และตัวที่ managed
บทสรุป
ควรใช้ Colly ไหม? ควร — ถ้าคุณเขียน Go และกำลัง crawl HTML หรือ JSON ด้วยความเร็ว มันทำได้ตามที่ชื่อเสียงว่า “crawler ที่เร็ว” สัญญาไว้ และตอนนี้ก็มีตัวเลขมารองรับแล้ว ดึง static ได้ครบ, JSON ผ่าน OnResponse ได้สะอาด, 500 ถูกส่งไป OnError อย่างถูกต้อง, crawl แบบ depth-2 ไปได้ 17 หน้า ทั้งหมดนี้คอมไพล์เป็น static binary ตัวเดียวแบบไม่มี runtime dependencies ซึ่งเป็นเรื่องที่ deploy ง่ายที่สุดในหมวดนี้เลย
แต่ต้องตีกรอบคำพูดให้ตรงความจริงด้วย มันไม่เรนเดอร์ JavaScript — ทุกหน้าที่ต้องพึ่ง client-side ในการทดสอบของผมคืนค่า 0 และนั่นเป็นข้อจำกัดถาวร ไม่ใช่ค่าที่คุณลืมตั้ง มันต้องใช้ Go toolchain ดังนั้นทีมที่ไม่ได้ใช้ Go ต้องจ่ายค่า setup ล่วงหน้า module ที่คุณติดตั้ง (v2.3.0) ใหม่กว่ารุ่น tagged ล่าสุด (v2.2.0) เลยไม่ต้องตกใจถ้าหน้าเว็บแสดงเลขไม่ตรงกัน และคำว่า “เร็ว” ในที่นี้หมายถึงเส้นทาง extraction ที่ผมวัดจริง ไม่ใช่ benchmark throughput ที่ยังไม่ได้รัน ภายในกรอบนี้ Colly คือ Go crawler ที่เร็ว เชื่อถือได้ และ deploy ได้จริง — และมันสมกับชื่อเสียงทันทีที่คุณเลิกขอให้มันรัน JavaScript
ลองใช้ Thunderbit สำหรับการดึงข้อมูลเว็บ Get Started Free
คำถามที่พบบ่อย
Colly เร็วจริงไหม และมีตัวเลขรองรับหรือเปล่า? เร็วในความหมายที่สำคัญกับเส้นทางหลักที่ผมวัด: Go ที่คอมไพล์แล้ว, ดึงข้อมูล static ได้ครบ (สินค้า 12/12 ชิ้น), จัดการ JSON ได้สะอาด, และ crawl แบบ depth-2 ไปได้ 17 หน้า — ทั้งหมดออกจาก static binary ตัวเดียว สิ่งที่ผม ไม่ได้ รันคือ benchmark throughput เทียบกับ Scrapy ดังนั้นให้มอง “เร็ว” ในฐานะพฤติกรรมการดึงข้อมูลที่วัดได้ ไม่ใช่คะแนนความเร็วแบบเทียบหัวต่อหัว
Colly scrape หน้าเว็บที่เรนเดอร์ด้วย JavaScript ได้ไหม? ไม่ได้ Colly เป็น HTTP crawler — มันดาวน์โหลดและ parse HTML แต่ไม่เคยรันบราวเซอร์ หน้า fixture ที่เรนเดอร์ด้วย JavaScript ให้ผลเป็นการ์ด 0 และหน้า Quotes JS สาธารณะก็ 0 เช่นกัน ถ้าเป็นเนื้อหาฝั่ง client คุณต้องต่อ Colly กับ renderer หรือใช้เครื่องมือที่มี browser rendering ในตัว
ต้องรู้ Go ไหมถึงจะใช้ Colly ได้?
ต้องรู้ Colly เป็นไลบรารี Go ไม่ใช่ CLI แบบสำเร็จรูป — คุณ import มัน, register callback (OnHTML, OnResponse, OnError) แล้วคอมไพล์ เครื่องที่ผมทดสอบไม่มี Go ติดตั้งอยู่ จึงเริ่มจากการติดตั้ง toolchain (1.26.5) ถ้าทีมของคุณไม่ได้ทำงานด้วย Go อยู่แล้ว สภาพแวดล้อมนี้คือค่า setup จริง ๆ
ทำไมเวอร์ชันที่ติดตั้งถึงไม่ตรงกับ GitHub release ล่าสุดของ Colly?
เพราะ Go module กับ GitHub release tag แยกทางกันไปแล้ว module ล่าสุดบน Go proxy คือ v2.3.0 (ธันวาคม 2025) ส่วน tagged release ล่าสุดบน GitHub คือ v2.2.0 (มีนาคม 2025) ผมทดสอบ v2.3.0 นี่เป็นเรื่องของความต่างระหว่าง module กับ tag ไม่ใช่การติดตั้งที่พัง
Colly ใช้เชิงพาณิชย์ได้ฟรีไหม? ได้ ภายใต้ Apache-2.0 ซึ่งเป็นสัญญาอนุญาตที่ค่อนข้างเปิดและเหมาะกับการใช้งานเชิงพาณิชย์ แต่ตามปกติควรตรวจสอบ license ปัจจุบันใน repo อีกครั้งก่อนนำไปใช้จริง
