ฉันทดสอบสแครปเปอร์โอเพนซอร์ส 9 ตัวบนม้านั่งทดสอบเดียวกัน และคำตอบที่ใช่

เกือบทุกบทสรุปที่บอกว่า “สแครปเปอร์โอเพนซอร์สดีที่สุด” มักมีจุดบอดเงียบ ๆ อยู่ข้อหนึ่ง: ไม่มีใครเอาเครื่องมือพวกนั้นไปทดสอบกับหน้าเว็บชุดเดียวกันจริง ๆ เลย Scrapy อาจถูกลองกับบทความข่าว, Playwright ไปอยู่บนเดโมอีคอมเมิร์ซ, Colly ได้หน้าที่ที่ผู้เขียนมีอยู่ในมือ แล้วทั้งหมดก็มาถูกจับมาเทียบและจัดอันดับชนกันตรง ๆ ราวกับว่าตัวเลขพวกนั้นหมายถึงเรื่องเดียวกัน ทั้งที่จริงมันกำลังบอกเรื่องของหน้าเว็บ ไม่ได้บอกเรื่องของเครื่องมือ

ดังนั้นผมเลยทำสิ่งที่ตรงไปตรงมา แต่คนมักข้ามไป: สร้างชุดทดสอบชุดเดียว แล้วป้อนทั้ง 9 เครื่องมือผ่านชุดนั้นทั้งหมด ตั้งแต่แคตตาล็อกแบบสแตติก, แคตตาล็อกที่เรนเดอร์ด้วย JavaScript, บทความที่มีทั้งเมนูนำทางและส่วนท้ายเว็บรก ๆ รายล้อม, เซิร์ฟเวอร์ 500 ที่ตั้งใจให้พัง, กราฟลิงก์ภายในขนาดเล็ก ไปจนถึงสองเว็บสาธารณะสำหรับฝึกใช้งาน ใช้ชุดข้อมูลจริงชุดเดียวกัน ค่าที่วัดเหมือนกัน และรันด้วยเงื่อนไขเดียวกันทั้งหมด โค้ดสคริปต์กับผลดิบทั้งหมดอยู่ใน public benchmark repo นี้ คุณจึงรันซ้ำเองได้ทุกส่วน สิ่งที่ออกมาไม่ใช่ตารางผู้นำสวยหรูแบบที่บทสรุปพวกนั้นชอบสัญญา — เพราะไม่มีผู้ชนะคนเดียวจริง ๆ — แต่มีอยู่ 3 งานที่ต่างกัน และเครื่องมือทั้ง 9 ตัวก็ค่อย ๆ ไปอยู่ในกลุ่มของตัวเอง

ลองใช้ Thunderbit เพื่อดึงข้อมูลเว็บ

ม้านั่งทดสอบนี้ทำงานอย่างไร และข้อจำกัดเดียวที่ผมขอพูดตรง ๆ

Benchmark comparison dimensions

ทุกเครื่องมือเจอ fixture รูปแบบเดียวกันหมด: สินค้าแบบสแตติก 12 รายการที่กระจายอยู่ 2 หน้า, สินค้า 8 รายการที่ถูกฉีดด้วย JavaScript หลังหน่วงเวลา, บทความที่มีเนื้อหาจริง 3 ย่อหน้า แต่ถูกรายล้อมด้วยโค้ดส่วนหัวและส่วนท้ายเว็บ, หน้า HTTP 500 ที่ตั้งใจให้ล้ม, และกราฟลิงก์ภายใน วิธีนี้แหละที่ทำให้ผลเทียบกันได้ — ถ้าบอกว่า “dynamic products 8/8” ก็หมายถึงสิ่งเดียวกัน ไม่ว่าจะสร้างผลลัพธ์ด้วย Puppeteer หรือ Crawlee

แต่มีเส้นแบ่งหนึ่งที่หลายบทสรุปมักไม่พูดถึง: ชุดไฟล์ของแต่ละเครื่องมือสะท้อน fixture ชุดเดียวกันในเวอร์ชันของตัวเอง ดังนั้นจำนวนอักขระแบบสัมบูรณ์จึงเอาไปเทียบข้ามเครื่องมือแบบตรง ๆ ไม่ได้ ให้มองเป็นสัญญาณภายในของเครื่องมือนั้น ๆ เท่านั้น ห้ามใช้เป็นคะแนนข้ามเครื่องมือ ตัวเลขที่ เทียบกันได้ จริง ๆ คือ recall (ให้คิดเป็นอัตรา), ผลผ่าน/ไม่ผ่านของ JavaScript และพฤติกรรมเชิงโครงสร้าง อีกข้อสังเกตในทำนองเดียวกันคือ การทดสอบ static catalog ของ Crawl4AI ครอบคลุมเฉพาะหน้าแรก ดังนั้นค่า 6/6 ของมันคือ recall เต็มในขอบเขตที่แคบกว่า ขณะที่เครื่องมืออื่นเก็บทั้งสองหน้าเป็น 12/12 — เป็นเรื่องของขอบเขต ไม่ใช่การพลาดครึ่งทาง รายละเอียดทั้งหมดแบบ fixture ต่อ fixture อยู่ใน methodology write-up

อีกข้อที่ควรระวังก่อนดูตัวเลข: แต่ละแพ็กยังมี provisional research score ติดมาด้วย แต่ผมตั้งใจไม่เอามาจัดเป็นตารางอันดับ เพราะมันเป็นเพียงเครื่องมือภายในไว้ตรวจสอบแต่ละตัวกับหลักฐานของตัวเอง ไม่ใช่ตารางแข่งขัน — ถ้านำมาพิมพ์เป็นอันดับเดียวก็จะย้อนสร้างปัญหา false precision ที่งานชิ้นนี้พยายามเลี่ยงมาตั้งแต่แรก นี่คือบทสรุปจากสิ่งที่ม้านั่งทดสอบบอก ไม่ใช่ตารางคะแนน

ภาพรวมทั้งสนามในม้านั่งเดียว

ลองไล่ดูสองคอลัมน์ในตารางนี้ — “Renders JS?” และ “Built-in crawl queue” — คุณจะเห็นงานทั้ง 3 แบบชัดขึ้นมาแทบจะทันที

เครื่องมือ	ภาษา	เรนเดอร์ JS ได้ไหม?	Static recall	โครงสร้างผลลัพธ์	มี crawl queue ในตัวไหม	น้ำหนักการติดตั้ง	ไลเซนส์
Crawl4AI	Python	ได้ (browser)	6/6 (หน้า 1)	CSS schema	มี BFS/DFS ในตัว	หนัก (browser stack 2 ชุด)	Apache-2.0
Firecrawl	Self-hosted	ได้ (playwright-service)	Markdown เต็ม	ได้	`/v1/crawl`	หนักที่สุด (6 containers)	AGPL-3.0
trafilatura	Python	ไม่ได้	3/3 บทความ	ไม่ได้ (text only)	ไม่มี	เบา	Apache-2.0
Crawlee	Node/TS	เลือก engine ได้	12/12	ผ่าน extraction	มี (RequestQueue)	ปานกลาง (+~80 MiB)	Apache-2.0
Playwright	Node/multi	ได้	12/12	ต้องเขียนเอง	ไม่มี (ต้องทำ BFS เอง)	ปานกลาง (browser)	Apache-2.0
Puppeteer	Node	ได้ (Chrome)	12/12	ต้องเขียนเอง	ไม่มี (ต้องทำ BFS เอง)	ปานกลาง (Chrome)	Apache-2.0
Scrapy	Python	ไม่ได้	12/12	Feed export (JSON/CSV/XML)	มี (built-in)	ปานกลาง (Twisted deps)	BSD-3
Colly	Go	ไม่ได้	12/12	ผ่าน callbacks	ควบคุมความลึกได้	เบา (binary เดียว + Go)	Apache-2.0
Scrapling	Python	ไม่ได้ (HTTP fetcher)	12/12	ได้	ไม่มี	ปานกลาง (`[fetchers]`)	BSD-3

Three families of open-source scrapers

หมายเหตุเรื่องเมตาดาต้าในตารางนี้และตลอดทั้งบทความ: จำนวนดาวและเวอร์ชันถูกบันทึกไว้ช่วงต้นเดือนกรกฎาคม 2026 และเปลี่ยนเร็วมาก ควรเช็กจาก GitHub และหน้าแพ็กเกจของแต่ละโปรเจกต์อีกครั้งก่อนนำไปถือว่าเป็นค่าปัจจุบัน

ดัชนีรีวิวรายเครื่องมือ

แต่ละโปรเจกต์ในบทความนี้มีรีวิวเชิงลึกประกอบอยู่ด้วย:

นี่คือภาพปกของแต่ละตัว — รวมถึงภาพหน้าจอจริง 2 ภาพจากการทดสอบเรนเดอร์ JavaScript เพื่อให้เห็นว่าคำว่า “dynamic 8/8” ไม่ได้เป็นแค่ตัวเลขบนหน้าเว็บ

Crawl4AI review cover

Firecrawl review cover

trafilatura review cover

Playwright vs Puppeteer review cover

Playwright rendered dynamic fixture screenshot

Puppeteer rendered dynamic fixture screenshot

Crawlee review cover

Scrapy review cover

Colly review cover

Scrapling review cover

งานที่ 1: เปลี่ยนหน้าเว็บให้เป็นข้อความพร้อมใช้กับ LLM

LLM-ready vs browser vs HTTP workbenches

ถ้าสิ่งที่คุณต้องการคือ Markdown ที่สะอาดเพื่อป้อนเข้า RAG pipeline มี 3 เครื่องมือที่ต้องชนกัน — และทั้งสามตัวนี้ต่างกันมากจนแทบคนละโลก

Crawl4AI แก่นจริงของมันคือเครื่องสร้าง Markdown ที่อาศัย browser อยู่ข้างหลัง แม้ชื่อการตลาดจะชอบเล่าเรื่อง “adaptive intelligence self-learning selector” ก็ตาม ซึ่งผมขอพูดตรง ๆ ว่ามันไม่มีฟีเจอร์แบบนั้น — นั่นเป็นทริกของไลบรารีอีกตัวหนึ่ง (เดี๋ยวจะกลับมาพูดถึงตอนถึง Scrapling) สิ่งที่มันทำได้จริง และทำได้ดี คือบนเว็บฝึก Books to Scrape มันปล่อย Markdown ออกมา 13,476 อักขระ รองรับการดึงข้อมูลเชิงโครงสร้างผ่าน CSS schema และ BFS deep crawl ในตัวก็พาไล่ไปได้ 5 หน้า บน fixture กราฟลิงก์ พร้อมเรนเดอร์หน้า JavaScript และจับภาพหน้าจอไว้ได้ด้วย แต่ก็มีข้อเสียอยู่ 2 จุด: Raw Markdown ของมันยังติด boilerplate ของหน้าเว็บมาด้วยถ้าไม่เปิด content filter และหน้า HTTP 500 ที่ตั้งใจให้ล้มก็ถูกส่งกลับมาเป็น success=false — ไม่ใช่เพราะ Crawl4AI จับ HTTP error ได้อย่างสวยงาม แต่เพราะ heuristic ของมันมอง body ที่เล็กนิดเดียวแล้วติดป้ายว่า minimal_text ... blocked แถมการติดตั้งยังต้องลาก browser stack สองชุดลงเครื่องคุณด้วย เวอร์ชัน 0.9.0, Apache-2.0, มีดาวประมาณ 71k เมื่อถึงต้นกรกฎาคม

Firecrawl คือรุ่นหนักของกลุ่มนี้ และการ self-host ก็ใช้งานได้จริง — ที่ผมย้ำว่า “จริง” เพราะสแตก 6 คอนเทนเนอร์ (api, playwright-service, redis, rabbitmq, nuq-postgres และ foundationdb) มันสตาร์ตขึ้นมาได้จริง และสร้าง Markdown พร้อมใช้กับ LLM ออกมา 9,222 อักขระ จากหน้า Books to Scrape หน้าเดิม มันเรนเดอร์หน้า JavaScript ผ่าน playwright-service ที่มากับระบบ และคำคม Einstein ที่ปรากฏหลังสคริปต์ทำงานก็โผล่ใน output จริง ซึ่งยืนยันว่าการเรนเดอร์ไม่ได้เป็นของปลอม ปัญหาสองอย่างที่ผมเจอเกิดจากสภาพแวดล้อม ไม่ใช่ตัว Firecrawl เอง และขออธิบายให้ชัดเพื่อไม่ให้ใครไปแก้ผิดจุด: การ build จากซอร์สชนกับบั๊กสุ่มของ containerd snapshotter บน colima (ผมจึงเปลี่ยนไปใช้ prebuilt images) และช่วง DNS 198.18.x.x ของ colima ไปกระตุ้น SSRF guard ของ Firecrawl ซึ่งผมแก้ด้วย ALLOW_LOCAL_WEBHOOKS=true — เป็นแค่ทางลัดสำหรับ local dev ไม่ใช่สิ่งที่ควรปิดในโปรดักชัน ตัว core แบบ self-hosted ยังไม่มี Fire-engine ซึ่งเป็น anti-block layer ของ cloud และผมไม่ได้ทดสอบ cloud API ด้วย ประเด็นที่ใหญ่กว่าคือไลเซนส์: core แบบ self-hosted ของ Firecrawl เป็น AGPL-3.0 ซึ่งก่อนใช้เชิงพาณิชย์ต้องอ่านและตรวจสอบจริงจัง ไม่ใช่รายละเอียดเล็ก ๆ ประมาณ 148k ดาวเมื่อต้นกรกฎาคม

trafilatura คือคนละฝั่งของกลุ่มนี้ และเป็นตัวที่บทความ AI-hype มักลืมถึง ไม่มี browser ไม่มีแถวข้อมูลเชิงโครงสร้าง มีแค่ตัวดึงบทความที่เร็วและสะอาด เขียนด้วย Python ล้วน ๆ บน fixture บทความ มันดึงได้ทั้ง title และ ย่อหน้าจริงครบ 3 จาก 3 ย่อหน้า, ตัด boilerplate ทิ้งแบบหมดจด — ไม่มี “Login”, “Subscribe” หรือ “Copyright” หลุดมาเลย — และยังดึง author กับวันที่กลับมาได้ด้วย บนหน้าสินค้าสาธารณะหน้าเดียวกัน มันคืนข้อความสะอาดยาว 1,324 อักขระ ข้อจำกัดของมันตรงตามที่ดีไซน์บอกไว้ชัดเจน: ถ้าโยนหน้า catalog ให้ มันจะส่งกลับชื่อสินค้า 12 รายการในรูปข้อความ แต่ไม่มีแถวโครงสร้างเลย 0 แถว — ข้อความมีอยู่ แต่โครงสร้างไม่มี — และมันไม่เรนเดอร์ JavaScript เวอร์ชัน 2.1.0 (release ปัจจุบัน), Apache-2.0, ดาวราว 6.2k ถ้าเป็นงานดึงบทความล้วน ๆ นี่คือสิ่งแรกที่ผมจะหยิบใช้

ตัวเลขอักขระ Markdown สองค่าที่เห็น — 13,476 จาก Crawl4AI และ 9,222 จาก Firecrawl — มาจากหน้า public เดียวกันก็จริง แต่ห้ามอ่านเป็นช่องว่างด้านคุณภาพ มันสะท้อนกลยุทธ์ Markdown ที่ต่างกัน (เก็บ chrome ของหน้าไว้มากน้อยแค่ไหน) ไม่ใช่คำตัดสินว่า output ไหนดีกว่า นี่คือตัวอย่างของกฎ “สัญญาณภายในของแต่ละเครื่องมือ” ที่พูดไปก่อนหน้านี้ ซึ่งเห็นชัด ๆ ตรงนี้

งานที่ 2: เรนเดอร์ JavaScript ให้เสถียร

JavaScript rendering decision

ข้อมูลบางอย่างไม่มีอยู่ใน HTML จนกว่าสคริปต์จะรันถึงจุดนั้น และนั่นคือช่วงที่ browser จริงไม่ใช่ของเสริมอีกต่อไป มี 3 เครื่องมือที่รับงานนี้ และ 2 ใน 3 กลับแทบจะเหมือนกันเป๊ะ

Playwright และ Puppeteer เสมอกันทุกการทดสอบที่ผมโยนให้ ทั้งคู่เรนเดอร์สินค้า dynamic ได้ 8/8 บน fixture ภายใน และ 10 บนไซต์ Quotes JS สาธารณะ ทั้งคู่ทำ static recall ได้ 12/12 และจัดการหน้า 500 ได้เรียบร้อย (Puppeteer คืน response object แทนที่จะ throw) ทั้งสองตัวไม่มี crawl queue ในตัว จึงต้องเขียน BFS เองเพื่อเดินกราฟลิงก์ 12 หน้า ความต่างจริง ๆ มีแค่ขอบเขต: Playwright ควบคุม Chromium, Firefox และ WebKit ได้ และใช้ได้ทั้ง Python กับ .NET ส่วน Puppeteer เน้น Chrome และใช้กับ Node เท่านั้น มีข้อเท็จจริงสองอย่างที่ควรรู้เพราะเวอร์ชันเปลี่ยนเร็ว: ผมทดสอบ Playwright 1.56.0 เทียบกับ current 1.61.1 และใช้แค่ Chromium; ส่วน Puppeteer 24.16.0 เทียบกับ current 25.3.0 — เวลานำผลไปใช้ควรรันซ้ำหรือหักส่วนนี้ออกตามสมควร ทั้งคู่เป็น Apache-2.0 และมีดาวประมาณ 92k กับ 95k ตามลำดับ

Crawlee คือเครื่องมือที่แก้ปัญหา queue ซึ่งอีกสองตัวปล่อยให้ค้างไว้ มันห่อเอา Cheerio (HTTP) engine กับ Playwright (browser) engine มาไว้ใต้ API เดียว และความต่างบนหน้าเดียวก็เป็นหัวใจของจุดขายนี้เลย: Cheerio engine มองไม่เห็นรายการที่ถูกฉีดด้วย JavaScript เลย 0, ส่วน Playwright engine มองเห็นครบ 8/8 บน fixture ภายใน (และ 10 บนไซต์สาธารณะ) แถมสลับกันได้ด้วยการเปลี่ยนโค้ดแค่บรรทัดเดียว นอกจากนี้มันยังมี RequestQueue จริง ๆ ให้ใช้ ซึ่งนี่แหละที่ทำให้มันถูกนับอยู่ในงานนี้ ไม่ใช่งานที่ 3 ข้อควรระวังที่ไม่มีใครชอบใส่ในพาดหัวคือ browser engine ต้องติดตั้ง npx playwright install แยกต่างหาก ซึ่งกินอีกประมาณ 80 MiB ที่ npm install crawlee ไม่ได้ดึงมาให้ เวอร์ชัน 3.17.0, TypeScript, Apache-2.0, ดาวราว 24.6k

งานที่ 3: crawl ให้เร็วโดยไม่ใช้ browser

ถ้าในหน้าเว็บไม่มี JavaScript browser ก็แพงเกินจำเป็นอยู่ดี มี 3 เครื่องมือสาย HTTP ที่มาชนกันตรงนี้ แยกตามปรัชญาของภาษา และแต่ละตัวก็มองปัญหาไม่เหมือนกันน่าสนใจ

Scrapy คือเฟรมเวิร์กระดับวิศวกรรมของกลุ่มนี้ — มี spiders, feed export เป็น JSON/CSV/XML, AutoThrottle และของครบ ๆ มันทำ static recall ได้ 12/12, ดึงย่อหน้าบทความครบ 3/3, เดินกราฟลิงก์ได้ 11 หน้า บน depth 0–2 และจับหน้า 500 ได้ผ่าน handle_httpstatus_list สิ่งที่น่าสนใจกว่าคือมุมมองของมัน: มันไม่เรนเดอร์ แต่มันจำลอง request ใหม่ ถ้าโยนหน้า JavaScript ให้ มันได้ 0 nodes — แล้ว JSON API ที่อยู่หลังหน้าเดิมกลับส่งมาให้ 8/8 นี่คือปรัชญา Scrapy ในตัวอย่างเดียว: หา request ที่หน้าเว็บใช้ แล้ว replay มัน แทนที่จะขับ browser ข้อแลกเปลี่ยนคือ dependency stack หนักพอสมควร (Twisted, lxml, parsel) และผมทดสอบมันกับ fixture ขนาดเล็กเท่านั้น เวอร์ชัน 2.17.0, BSD-3-Clause, ดาวราว 63k

Colly คือคำตอบฝั่ง Go และมันพูดตรงมากว่าเป็นอะไร: binary เดียว, ขับเคลื่อนด้วย callback ผ่าน OnHTML, OnResponse, และ OnError, พร้อมควบคุมความลึกได้ มันเก็บ static recall ได้ 12/12, ดึง 8/8 จาก JSON API ผ่าน OnResponse, จับ 500 ผ่าน OnError, และไต่ได้ 17 หน้าในการ crawl depth-2 — ผมตั้งใจใช้ถ้อยคำแบบนี้ เพราะจำนวนหน้านั้นเป็นตัวนับของ harness เอง ไม่ใช่คำรับรองความครบถ้วนจาก Colly สิ่งที่มันไม่ทำคือ JavaScript: fixture แบบ dynamic และ Quotes JS site ต่างก็ตอบกลับมา 0 ตามที่ออกแบบไว้ คุณจะต้องมี Go toolchain เพื่อ build มัน และ module version (v2.3.0) ตอนนี้วิ่งนำ tagged release (v2.2.0) อยู่ Apache-2.0, ดาวราว 25k

Scrapling คือผู้เชี่ยวชาญเฉพาะทาง และมันสมชื่อจริง ๆ adaptive selectors ของมันถูกสร้างมาเพื่อหา element เดิมให้เจออีกครั้งเมื่อ markup เปลี่ยน — ดังนั้นตอนที่ผมเปลี่ยน class HTML ของเป้าหมายจาก product-name เป็น product-title, selector แบบธรรมดามองไม่เห็นอะไรเลย 0, แต่ adaptive re-match ยังตามเจอ element ที่เฝ้าไว้กลับมาได้อยู่ บนงานดึงข้อมูล HTTP ปกติ มันทำ static ได้ 12/12 และ JSON API ได้ 8/8 ส่วนข้อจำกัดที่ docs ของมันเองก็ไม่ได้ปิดบัง: ใน synthetic multi-element test มันกู้คืนได้ 1 จาก 3 — นี่คือการติดตาม element อย่างทนทาน ไม่ใช่การกู้คืนทั้งหมด เพราะฉะนั้นอย่าเผลอคิดว่ามันทำได้ทุกอย่างจากชื่อฟีเจอร์เดียว การติดตั้งเริ่มต้น pip install scrapling ยังต้องเพิ่ม extra [fetchers] เพื่อให้ใช้งานได้ และ StealthyFetcher ก็เป็นประเด็นด้าน compliance มากกว่าจะเป็นฟีเจอร์ที่ผมอยากเอาไปใส่สไลด์ เวอร์ชัน 0.4.10 (release ปัจจุบัน), BSD-3-Clause, ดาวราว 68.7k

รูปแบบที่ซ่อนอยู่ใต้ทั้ง 3 งาน

ถ้าวางทั้ง 9 ตัวลงเรียงกัน สิ่งหนึ่งจะชัดขึ้นทันที: static recall เต็มแบบแบน ๆ 12/12 คือขั้นต่ำที่ทุกเครื่องมือสาย HTTP ทำได้ ไม่มีตัวไหนพลาดกรณีง่าย ๆ เลย ดังนั้นมันจึงไม่ใช่จุดต่าง เครื่องมือสาย browser จะคุ้มค่าน้ำหนักที่เพิ่มขึ้นก็ต่อเมื่อมี JavaScript เข้ามาจริง ๆ และทุกตัวก็ต้องจ่ายต้นทุนการติดตั้งในรูปแบบใดแบบหนึ่ง ไม่ว่าจะเป็น browser stack, การติดตั้งเพิ่ม หรือ container หลายก้อน ส่วนคอลัมน์ “built-in crawl queue” จริง ๆ แล้วคือเส้นแบ่งระหว่าง framework กับ engine — Scrapy กับ Crawlee มี orchestration มาให้ ขณะที่ Playwright กับ Puppeteer บังคับให้คุณเขียน BFS เอง นั่นคือโครงสร้างของสนามนี้ ไม่มีผู้ชนะรวม เพราะไม่มีใครกำลังเล่นเกมเดียวกัน

แล้วจริง ๆ ควรเลือกตัวไหน

ม้านั่งทดสอบนี้ไม่ยอมมอบมงกุฎให้ผู้ชนะคนเดียว เพราะคำตอบที่ถูกไม่ใช่ชื่อเครื่องมือ แต่มันคือคำถาม — คุณกำลังทำงานแบบไหนกันแน่

ต้องการ Markdown พร้อมให้ LLM ใช้? เลือก trafilatura เมื่อคุณต้องการบทความสะอาด ๆ, เลือก Crawl4AI ถ้าคุณอยากได้ CSS extraction และ JavaScript rendering ในไลบรารีเดียว, และเลือก Firecrawl ถ้าคุณต้องการบริการ self-hosted จริง ๆ และพร้อมรับทั้งไลเซนส์ AGPL-3.0 กับภาระ 6 containers
ต้องเรนเดอร์ JavaScript? ใช้ Playwright หรือ Puppeteer สำหรับเรนเดอร์ล้วน ๆ — เลือกตาม engine และภาษา เพราะผลลัพธ์โดยรวมสูสีมาก — และเลือก Crawlee เมื่อคุณอยากได้ทั้งการเรนเดอร์และ orchestration ของการ crawl โดยไม่ต้องเขียนเองทั้งหมด
ต้อง crawl หน้า static หรือ API ที่ทำซ้ำได้ในสเกลใหญ่? ใช้ Scrapy ถ้าต้องการ framework Python เต็มรูปแบบ, ใช้ Colly ถ้าต้องการความเร็วดิบของ Go ใน binary เดียว, และใช้ Scrapling ถ้าปัญหาประจำของคุณคือ markup เปลี่ยนบ่อยแล้ว selector เดิมพัง

จับเครื่องมือให้ตรงงาน แล้วทุกตัวเลือกในนี้ก็พอปกป้องได้ทั้งนั้น แต่ถ้าเลือกผิดหมวด — เอา browser tool ไปใช้กับหน้า static หรือเอา HTTP parser ไปใช้กับเว็บแอป JavaScript — ต่อให้เป็นไลบรารีอันดับดีสุดในอินเทอร์เน็ตก็ยังทำให้คุณผิดหวังได้อยู่ดี

แล้ว managed AI API เข้ามาอยู่ตรงไหนแทน

Firecrawl AGPL-3.0 license callout

เครื่องมือทั้งหมดข้างต้นใช้ฟรี เป็นโอเพนซอร์ส และคุณรันเองได้ นั่นก็คือข้อแลกเปลี่ยนที่ม้านั่งทดสอบนี้เผยให้เห็นอยู่เรื่อย ๆ: คุณต้องดูแลสภาพแวดล้อม browser, โค้ด crawl, การต่อสู้กับ anti-bot และการบำรุงรักษาทุกชิ้นเอง สำหรับหลายทีม นี่แหละคือข้อดี เพราะคุณคุมได้เต็มที่ และแผนที่ไลเซนส์ก็สำคัญมากเมื่อจะเอาไปใช้จริง — ส่วนใหญ่เป็นไลเซนส์แบบผ่อนปรน (Apache-2.0 ใน Crawl4AI, Crawlee, Playwright, Puppeteer และ Colly; BSD-3 ใน Scrapy และ Scrapling) โดยมี Firecrawl core แบบ self-hosted ที่เป็น AGPL-3.0 เป็นตัวที่ต้องตรวจสอบจริงจังก่อนเอาไปใช้เชิงพาณิชย์

แต่สังเกตด้วยว่า ม้านั่งทดสอบนี้ยังชี้ให้เห็นอีกอย่าง: เครื่องมือเหล่านี้ ไม่ได้ ทำทุกอย่างให้คุณ render, crawl, structure และหมุนหลบ block ไปพร้อมกันได้ — ทำได้ไม่บ่อย และไม่เคยโดยไม่มีงานดูแลจากคุณเอง managed AI scraping API จึงเข้ามาย่อทั้งสแตกเหล่านี้ให้เหลือแค่การเรียกหนึ่งครั้ง surface สำหรับนักพัฒนาของเราเองที่ Thunderbit ก็เป็นหนึ่งทางเลือกในนั้น และสำหรับคนสายเทคนิค สิ่งที่สำคัญคือ API, MCP server และ CLI ไม่ใช่ browser extension POST /distill จะคืน Markdown ที่สะอาด ส่วน POST /extract จะคืน JSON ตาม schema โดยจัดการ JavaScript rendering และ anti-bot ฝั่งเซิร์ฟเวอร์แทนที่จะให้เครื่องคุณรับภาระเอง มี MCP server ทางการสำหรับเอเจนต์และ coding assistant — thunderbit_suggest_fields ใช้ฟรีเพื่อวางแผนการดึงข้อมูล จากนั้น thunderbit_distill (1 credit) และ thunderbit_extract (20 credits) จะทำงานต่อ และยังมี CLI ที่เรียกใช้ได้ด้วย npx @thunderbit/thunderbit-cli สำหรับงานใน terminal และ cron jobs สำหรับคนที่ไม่ใช่นักพัฒนาในทีม ก็ยังมี Chrome extension แบบ no-code และ pricing ที่ครอบคลุมทั้งสองมิติ

ข้อแลกเปลี่ยนก็ยังเป็นแบบเดิมที่ทั้งม้านั่งทดสอบนี้วนกลับมาชี้ซ้ำ: คุณจะรันและดูแลไลบรารีได้สูงสุด 9 ตัวเองโดยไม่เสียค่าต่อการเรียกเลย หรือจะยกภาระ plumbing ออกไปแล้วจ่ายตาม request ไม่มีคำตอบไหนผิด มันขึ้นอยู่กับว่าคุณอยากเป็นเจ้าของสแตกมากแค่ไหน ถ้าอยากดูตัวอย่างการดึงข้อมูลจริงแบบเห็นภาพมากขึ้น Thunderbit YouTube channel ก็มีสอนให้ดู

บทสรุป

ไม่มีสแครปเปอร์โอเพนซอร์สที่ดีที่สุดเพียงตัวเดียว และทุกลิสต์ที่ประกาศชื่อผู้ชนะอย่างมั่นใจมักกำลังซ่อนคำถามสำคัญที่เป็นตัวตัดสินจริงอยู่เงียบ ๆ: คุณกำลังทำงานแบบไหนกันแน่? แปลงหน้าเว็บเป็นข้อความ, เรนเดอร์ JavaScript, หรือ crawl ให้เร็วโดยไม่ใช้ browser — สนามนี้แยกออกเป็น 3 กลุ่มอย่างชัดเจน และภายในแต่ละกลุ่ม คำตอบจะลงเอยที่ภาษาและน้ำหนักการติดตั้ง มากกว่าจะเป็นแชมป์สากลสักตัว

ถ้าจะเอานิสัยเดียวจากบทความนี้ไปใช้ ผมอยากให้เอาข้อนี้ไป: ทดสอบกับหน้าเว็บของคุณเองก่อนจะผูกมัดกับอะไรสักอย่าง ตัวเลขทั้งหมดในนี้รันซ้ำได้ใน benchmark repo ด้วยเหตุผลนั้นพอดี — เพราะเครื่องมือที่ชนะใน roundup ทั่วไป กับเครื่องมือที่เอาตัวรอดบน target จริงของคุณ อาจไม่ใช่ตัวเดียวกันเสมอไป

ลองใช้ Thunderbit เพื่อดึงข้อมูลเว็บ Get Started Free

คำถามที่พบบ่อย

สแครปเปอร์โอเพนซอร์สตัวไหนดีที่สุด? ไม่มีตัวเดียวที่ดีที่สุดเสมอไป — ขึ้นอยู่กับงาน ถ้าต้องการข้อความพร้อมใช้กับ LLM ให้ดู trafilatura หรือ Crawl4AI; ถ้าต้องเรนเดอร์ JavaScript ให้ดู Playwright, Puppeteer หรือ Crawlee; ถ้าต้อง crawl HTTP ให้เร็วให้ดู Scrapy หรือ Colly ในม้านั่งทดสอบเดียวกัน เครื่องมือแต่ละตัวแข็งที่สุดในหมวดของตัวเอง และอ่อนลงชัดเจนเมื่อออกนอกหมวด จึงเป็นเหตุผลว่าทำไมอันดับแบบ one-size-fits-all ถึงชวนเข้าใจผิด

สแครปเปอร์โอเพนซอร์สตัวไหนเรนเดอร์ JavaScript ได้? Crawl4AI, Firecrawl, Playwright, Puppeteer และเอนจิน Playwright ของ Crawlee เรนเดอร์ JavaScript ได้ ส่วน Scrapy, Colly, trafilatura และ HTTP fetcher ค่าเริ่มต้นของ Scrapling ทำไม่ได้ — พวกมันต้องอาศัย API ที่ทำซ้ำได้อยู่หลังหน้าเว็บ (แนวทางของ Scrapy ซึ่งดึงได้ 8/8 จาก JSON endpoint) หรือไม่ก็ต้องใช้ browser mode แยกต่างหาก

จำเป็นต้องใช้ headless browser เพื่อ scrape เว็บไซต์ไหม? เฉพาะเมื่อข้อมูลปรากฏหลังจาก JavaScript ทำงานเท่านั้น ถ้า HTTP request ปกติร่วมกับ parser เข้าถึงเนื้อหาได้ browser จะเป็นภาระที่เกินจำเป็นมาก — กรณีนั้น Scrapy, Colly หรือ Scrapling จะเบาและเร็วกว่าเยอะ

ตัวไหนไลเซนส์เป็นมิตรกับการใช้งานเชิงพาณิชย์ที่สุด? ส่วนใหญ่เป็นแบบผ่อนปรน: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) หรือ BSD-3-Clause (Scrapy, Scrapling) ข้อยกเว้นคือ core แบบ self-hosted ของ Firecrawl ซึ่งเป็น AGPL-3.0 และควรได้รับการตรวจสอบไลเซนส์อย่างจริงจังก่อนนำไปสร้างผลิตภัณฑ์เชิงพาณิชย์

ตัวเลข benchmark เหล่านี้รันซ้ำได้จริงไหม? ได้ ทุก runner, fixture และผลลัพธ์ดิบอยู่ใน repo สาธารณะที่ใช้ MIT license ข้อควรจำมีหนึ่งอย่าง: recall และผลเชิงโครงสร้างเทียบข้ามเครื่องมือได้ แต่จำนวนอักขระแบบสัมบูรณ์เป็นสัญญาณภายในของแต่ละเครื่องมือเท่านั้น เพราะแต่ละแพ็กสะท้อน fixture ของตัวเอง ไม่ได้แชร์สำเนามาตรฐานชุดเดียวกัน ดังนั้นให้เทียบอัตราและผลผ่าน/ไม่ผ่าน ไม่ใช่จำนวนอักขระดิบ