Crawlee ทดสอบแล้ว: เฟรมเวิร์กเดียวบน Node สองเอนจินสำหรับการสแครป

คนส่วนใหญ่มักจะมารู้จัก Crawlee ตอนกำลังหาคำตอบให้กับอีกคำถามหนึ่งก่อนเสมอว่า “ควรใช้เบราว์เซอร์แบบ headless ตัวไหนดี?” แต่จริง ๆ แล้วคำถามนั้นไม่ตรงจุด และ Crawlee ก็คือคำตอบนั้น เพราะมันไม่ใช่เบราว์เซอร์ แต่คือเฟรมเวิร์กบน Node/TypeScript ที่จะครอบการทำงานของเบราว์เซอร์เมื่อจำเป็น และข้ามมันไปเมื่อไม่จำเป็น

ผมใช้เวลาสองสามวันทดสอบ Crawlee 3.17.0 กับชุด fixture ที่ควบคุมได้ และเว็บไซต์เดโมสาธารณะบางแห่ง บน Node v22.22.3 และ macOS จุดขายหลักที่ว่า “ไลบรารีเดียว, API เดียว, มีได้ทั้ง crawler แบบ HTTP หรือเบื้องหลังเป็นเบราว์เซอร์จริง” คือสิ่งที่ผมอยากทดสอบมากที่สุด เพราะนี่แหละคือคำตอบว่าจะคุ้มไหมที่จะเพิ่ม Crawlee เข้า stack ของคุณ หรือคุณควรเรียกใช้ Playwright ตรง ๆ ไปเลย สรุปสั้น ๆ: เรื่องสองเอนจินนี้ใช้ได้จริง แม้จะมีข้อสังเกตเล็กน้อยซึ่งผมจะเล่าต่อไป

Crawlee คืออะไร และไม่ใช่อะไร

Crawlee อธิบายตัวเองว่าเป็นไลบรารีสำหรับ web scraping และ browser automation บน Node.js ที่สร้างมาเพื่อทำ crawler ให้เชื่อถือได้ การวางตำแหน่งอย่างเป็นทางการของมัน กว้างมาก ตั้งแต่ดึงข้อมูลไปใช้กับ AI, LLMs, RAG หรือ GPTs; ดาวน์โหลด HTML, PDF, JPG, PNG และไฟล์ประเภทอื่น ๆ; ใช้ได้กับ Puppeteer, Playwright, Cheerio, JSDOM และ HTTP ดิบ; รองรับทั้งแบบเห็นหน้าและไม่เห็นหน้า; แถมมี proxy rotation มาให้ด้วย พื้นที่การใช้งานกว้างขนาดนี้ จึงควรพูดให้ชัดว่า Crawlee ไม่ใช่ อะไรบ้าง

มันไม่ใช่ rendering engine และไม่ได้มีเบราว์เซอร์ของตัวเอง เวลาคุณต้องการให้ JavaScript ทำงาน Crawlee จะไปสั่ง Playwright หรือ Puppeteer ซึ่งก็ไปสั่ง Chromium (หรือเบราว์เซอร์ตัวอื่น) อีกทีหนึ่ง มันก็ไม่ใช่บริการแบบ hosted ที่เรียกผ่านเครือข่ายได้ — แต่มันคือ dependency ที่คุณติดตั้งและรันเอง สิ่งที่ Crawlee เป็น อย่างแท้จริง คือเลเยอร์เหนือ fetcher: คลาสสำหรับ crawler, request queue, storage, และ logic สำหรับตามลิงก์ต่าง ๆ ให้อัตโนมัติ มองมันเป็นเฟรมเวิร์กสำหรับการ crawl ที่มีเอ็นจินแบบเสียบเปลี่ยนได้อยู่ด้านล่างจะเข้าใจง่ายที่สุด

เพื่อความชัดเจน เวอร์ชันที่ผมทดสอบคือ 3.17.0 (ปล่อยเมื่อ 2026-06-04) เขียนด้วย TypeScript ใช้สัญญาอนุญาต Apache-2.0 และ repo มีราว ๆ 24.6k stars ณ วันที่ 2026-07-09 บน apify/crawlee จำนวนดาวขึ้นลงตลอด — ระหว่างสองวันที่ผมเฝ้าดู repo ได้เพิ่มมา 53 ดาว — ดังนั้นให้มองตัวเลขนี้เป็นภาพ ณ ช่วงเวลาหนึ่ง ไม่ใช่ข้อเท็จจริงตายตัว

สองเอนจิน: CheerioCrawler vs PlaywrightCrawler

ตรงนี้แหละที่ดีไซน์ของมันคุ้มค่า และเป็นส่วนที่ผมใช้เวลาทดสอบมากที่สุด

CheerioCrawler คือเส้นทางแบบ HTTP มันดึง HTML ดิบผ่านเครือข่าย แล้วเอาไป parse ด้วย Cheerio — ไม่มีเบราว์เซอร์ ไม่มีการรัน JavaScript ไม่มี rendering มันเร็วและประหยัด ส่วน PlaywrightCrawler คือเส้นทางแบบเบราว์เซอร์ มันเปิด Chromium จริง แสดงผลหน้าเว็บรวมถึง JavaScript ที่สร้าง DOM และยังสามารถถ่าย screenshot ได้ด้วย

สองเอนจินนี้มีความสามารถต่างกันจริง ๆ แต่สิ่งที่ Crawlee พยายามบอกคือ ทั้งสองตัว “ใส่เสื้อผ้าแบบเดียวกัน” ทั้งคู่รับ requestHandler ทั้งคู่มี run() ทั้งคู่ crawl ลิงก์ด้วย enqueueLinks การย้ายจากเอนจินหนึ่งไปอีกเอนจินหนึ่งจึงเป็นแค่การสลับคลาส ไม่ใช่การเขียนใหม่ทั้งหมด — ผมลองแล้วโดยคงตรรกะการดึงข้อมูลให้เหมือนเดิมทุกบิต และเปลี่ยนแค่คลาส crawler ที่ครอบมันไว้

มีจุดหนึ่งที่ต้องพูดให้เป๊ะ เพราะนี่คือจุดที่ความเท่าเทียมกันเริ่มหยุดทำงาน: วิธีเข้าถึงเนื้อหาไม่เหมือนกัน ภายใน handler ของ CheerioCrawler คุณจะได้ $ — DOM แบบ static ที่ parse ไว้แล้วและ query ได้เหมือน jQuery ส่วนใน browser handler คุณจะได้อ็อบเจ็กต์ page ที่ยังทำงานอยู่ ดังนั้น queue, routing, และ plumbing ของการ “ส่งข้อมูลนี้ไป เก็บลิงก์นั้นต่อ” จะเหมือนเดิม แต่จุดที่คุณอ่านหน้าเว็บจริง ๆ จะเปลี่ยนรูปแบบ Crawlee เองก็อธิบายไว้ทำนองเดียวกัน — อินเทอร์เฟซที่แชร์ร่วมกันจะครอบเฉพาะการทำงานฝั่ง crawl ส่วนการเข้าถึงเนื้อหาจะต่างกันตามเอนจิน

เอนจิน	วิธีดึงข้อมูล	รัน JavaScript ไหม	ผลทดสอบของผม (หน้าไดนามิก 1 หน้า)	เหมาะสำหรับ
CheerioCrawler	HTTP ดิบ + parse ด้วย Cheerio	ไม่	~0.035 วินาที	HTML แบบ static, JSON API, งานที่เน้นความเร็ว
PlaywrightCrawler	Chromium จริงผ่าน Playwright	ใช่	~4.967 วินาที	หน้าเว็บที่ render ด้วย JS, screenshot

ตัวเลขเหล่านี้มาจากเครื่องเดียวและรันเพียงครั้งเดียว — ไม่ใช่ benchmark เป็นแค่ภาพของ trade-off เท่านั้น เส้นทางแบบเบราว์เซอร์ใช้เวลามากกว่าประมาณสองลำดับขั้นบน URL เดียวกัน นี่คือราคาของการ rendering และเป็นเหตุผลว่าทำไมคุณไม่ควรเลือกมันเป็นค่าเริ่มต้น

การทดสอบ: URL เดียวกัน, 0 เทียบกับ 8/8

คำพูดใครก็พูดได้ สิ่งที่ทำให้ผมเชื่อเรื่องสองเอนจินคือ ผมทำให้มันล้มเหลวได้ แล้วแก้ได้ด้วยการเปลี่ยนคลาสแค่ตัวเดียว

ผมสร้าง dynamic fixture ภายในเครื่อง — หน้ารายการสินค้าที่การ์ดสินค้าเกิดจาก JavaScript หลังหน้าโหลด ซึ่งเป็นรูปแบบที่กลายเป็นมาตรฐานของเว็บสมัยใหม่ไปแล้ว จากนั้นผมชี้ CheerioCrawler ไปที่หน้านั้น ผลคือได้การ์ดสินค้า 0 ใบ นี่ไม่ใช่บั๊ก แต่มันคือฟิสิกส์ เพราะ Cheerio ไม่เคยรัน JavaScript เลย การ์ดจึงไม่เคยมีอยู่ใน HTML ที่มัน parse จากนั้นผมชี้ PlaywrightCrawler ไปที่ URL เดิมทุกอย่างเหมือนเดิม แล้วมันก็ render สินค้าได้ 8 จาก 8 พร้อม screenshot เป็นหลักฐาน

เพื่อให้แน่ใจว่าไม่ใช่แค่แปลกเฉพาะ fixture ของผม ผมลองรูปแบบเดียวกันกับเว็บไซต์สาธารณะ — หน้าเดโม JavaScript ของ Quotes to Scrape ซึ่งสร้าง quote ฝั่ง client เช่นกัน ผลออกมาในทิศทางเดียวกัน: CheerioCrawler เห็น quote 0 รายการ ส่วน PlaywrightCrawler ดึงกลับมาได้ 10 รายการ

ผมอยากระวังนิดหนึ่งว่าข้อทดสอบนี้พิสูจน์อะไรบ้าง มันคือการยืนยันซ้ำของสิ่งที่ Crawlee อธิบายไว้แล้ว — เฟรมเวิร์กนี้ใช้ base class และอินเทอร์เฟซเดียวกันร่วมกันมานานตั้งแต่เวอร์ชัน 3.0 ดังนั้นนี่คือการ verify ไม่ใช่การค้นพบใหม่ แต่คุณค่ามันอยู่ตรงนี้แหละ: ประโยคการตลาดที่ว่า “อินเทอร์เฟซเดียว, ได้ทั้ง HTTP และ browser” เป็นของจริง และนี่คือหลักฐานจาก 0 ไปสู่ข้อมูลครบ ทั้งบน fixture ที่ผมควบคุมได้และบนเว็บที่ผมควบคุมไม่ได้

จุดที่เส้นทาง HTTP ชนะ

ถ้าอ่านส่วนก่อนหน้าอย่างเดียว คุณอาจจะคิดว่า “งั้นใช้เบราว์เซอร์ตลอดไปเลยสิ” อย่าเพิ่งคิดแบบนั้น เหตุผลที่ดีไซน์สองเอนจินสำคัญก็เพราะว่าเบราว์เซอร์คือทางเลือกสำรองที่แพงกว่า ไม่ใช่ตัวเลือกเริ่มต้น

กับคอนเทนต์แบบ static CheerioCrawler ให้ผลที่แม่นและเร็ว fixture รายการสินค้าคงที่ของผมดึงสินค้าได้ 12 จาก 12 แบบครบถ้วน ตาม pagination ด้วย enqueueLinks({ selector: '.next-page' }) ใช้เวลาประมาณ 0.155 วินาที หน้า article หนึ่งหน้าดึง title และย่อหน้าเนื้อหา 3 จาก 3 ออกมาได้ พร้อมแยก boilerplate อย่าง login/subscribe/copyright ออกจากเนื้อหาอย่างเรียบร้อย

ประเด็นที่ควรจำให้ขึ้นใจคือ หน้าเว็บที่โหลดข้อมูลด้วย JavaScript มักมี JSON API ซ่อนอยู่ด้านหลัง fixture ไดนามิกของผมมีข้อมูลอยู่ที่ endpoint และเมื่อผมชี้ CheerioCrawler ไปที่ API ตรง ๆ มันดึงสินค้าได้ 8 จาก 8 โดยไม่ต้องเปิดเบราว์เซอร์ ใช้เวลาเพียงประมาณ 0.035 วินาที เป็นข้อมูลชุดเดียวกับที่เส้นทางเบราว์เซอร์ต้องใช้เวลาเกือบห้าวินาทีในการ render บทเรียนนี้เก่าแต่ยังจริงเสมอ: ถ้าคุณยิง request ต้นทางได้ ก็ทำแบบนั้นแทนการเปิด Chromium Crawlee เปิดโอกาสให้คุณเลือกสิ่งนี้แยกกันในแต่ละ crawler โดยไม่ต้องเปลี่ยนเฟรมเวิร์ก

ส่วนที่เป็น “crawl framework” จริง ๆ (เหตุผลที่ควรเลือก Crawlee แทนไลบรารีเบราว์เซอร์ล้วน ๆ)

ถ้าคุณแค่ต้อง render หน้าเว็บหนึ่งหน้า คุณไม่จำเป็นต้องใช้ Crawlee — Playwright หรือ Puppeteer ก็พอ แต่สิ่งที่ browser library ทั่วไปไม่ได้ให้คุณคือการ crawl: queue, deduplication, การคุม depth, retries นี่คือส่วนของ Crawlee ที่ไม่เกี่ยวกับเอนจินเลย

ผมรัน crawl ภายใน hostname เดียวกันจาก root ของ fixture โดยใช้ enqueueLinks พร้อมติดตาม depth Crawlee เดินผ่าน 11 หน้า ในระดับ depth {0:1, 1:3, 2:7} — หน้า root 1 หน้า, หน้า hop แรก 3 หน้า, และหน้า hop ที่สอง 7 หน้า — และเคารพ maxRequestsPerCrawl เป็นเงื่อนไขหยุดทำงาน RequestQueue จัดการ bookkeeping ให้ทั้งหมด เมื่อผมส่ง request ไปยังหน้าที่ตอบ HTTP 500 Crawlee จะ retry แล้วค่อยส่งความล้มเหลวผ่าน failedRequestHandler แทนที่จะกลืน error เงียบ ๆ หรือทำให้ run พัง

นี่คือเหตุผลที่แข็งแรงที่สุดในการเลือก Crawlee แทนเครื่องมือเบราว์เซอร์แบบเดี่ยว ๆ: orchestration ของการ crawl มีมาให้ในตัว และที่สำคัญ มันใช้ orchestration เดียวกันไม่ว่าเอนจินด้านล่างจะเป็น HTTP หรือเบราว์เซอร์ คุณเขียนตรรกะเรื่อง queue และการตามลิงก์เพียงครั้งเดียว จากนั้นค่อยตัดสินแยกกันว่า crawler แต่ละตัวควรรัน JavaScript หรือไม่

การติดตั้งและการดาวน์โหลดเบราว์เซอร์ที่ซ่อนอยู่

การติดตั้งโดยรวมค่อนข้างราบรื่น มีแค่กับดักจุดหนึ่งที่ผู้ใช้ครั้งแรกมักเจอ

npm install crawlee playwright ติดตั้งได้เรียบร้อย — รายงานว่าไม่มีช่องโหว่เลย แต่ PlaywrightCrawler จะยังไม่เปิดใช้งานจนกว่าคุณจะรัน npx playwright install chromium เพิ่ม ซึ่งจะดาวน์โหลด Chromium binary ขนาดประมาณ 81.7 MiB การติดตั้งแพ็กเกจ crawlee เพียงอย่างเดียว ไม่ได้ ดึงเบราว์เซอร์มาด้วย ถ้าคุณข้ามขั้นตอนนี้แล้วรีบไปใช้ browser crawler ทันที คุณจะเจอ error ตอน launch ที่ไม่ชัดเจนนักถ้าคุณไม่คุ้นกับโมเดลการแพ็กของ Playwright อยู่แล้ว นี่ไม่ใช่ข้อบกพร่องของ Crawlee แต่เป็นพฤติกรรมตามแบบของ Playwright ทว่ามันก็เป็นจุด friction ตอนเริ่มใช้งานครั้งแรกที่ควรระบุไว้

อีกเรื่องด้านการใช้งานจริงคือ โดยค่าเริ่มต้น Crawlee จะเขียนข้อมูลลงโฟลเดอร์ local storage/ ระบบทดสอบของผมเปลี่ยนเส้นทางไปยัง temp dir ชั่วคราวและปิด persistence เพื่อให้สะอาด แต่ถ้าคุณรันแบบปกติ จะมีโฟลเดอร์ storage/ โผล่ในโปรเจ็กต์ ไม่ใช่ปัญหา แค่ควรรู้ไว้ก่อนที่มันจะไปโผล่ใน git status ของคุณ

เอนจินที่สาม แบบสั้น ๆ

เรื่องความเท่าเทียมของ Crawlee ไม่ได้มีแค่ Cheerio กับ Playwright เท่านั้น ยังมี PuppeteerCrawler ด้วย และผมดูด้วยว่าเคลมเรื่อง “อินเทอร์เฟซเดียวกัน” ขยายไปถึงมันได้แค่ไหน — ในระดับคลาสและ surface ของ API ไม่ใช่การ crawl จริง

crawler ทั้งสามคลาสนี้สืบทอดมาจาก BasicCrawler เดียวกัน CheerioCrawler วิ่งผ่าน HttpCrawler ส่วน PlaywrightCrawler และ PuppeteerCrawler วิ่งผ่าน BrowserCrawler ที่แชร์ร่วมกัน หาก introspect แพ็กเกจที่ติดตั้งอยู่ จะพบ public methods 24 ตัวที่แชร์ร่วมกันในทั้งสามเอนจิน รวมถึง operation ของ queue และ storage ที่เป็นแกนของดีไซน์นี้ทั้งหมด — run, addRequests, pushData, getData, getDataset, exportData, getRequestQueue, useState, stop PuppeteerCrawler กับ PlaywrightCrawler ยังมีชุด public methods เหมือนกันเป๊ะ ๆ อีกด้วย ความต่างระหว่างเอนจินมีอยู่เฉพาะตรงเส้นแบ่ง HTTP กับ browser ซึ่งก็เป็นจุดที่คุณคาดไว้แล้ว

ข้อจำกัดที่ควรพูดให้ชัด: ผมไม่ได้รัน PuppeteerCrawler แบบ live นะครับ เพราะ peer dependency ของ puppeteer เป็นตัวเลือกเสริมและไม่ได้ติดตั้งในชุดทดสอบของผม และการจะทดสอบมันก็หมายถึงต้องดาวน์โหลดเบราว์เซอร์เพิ่มอีกหนึ่งชุด ดังนั้นส่วนที่ยืนยันเรื่อง Puppeteer ตรงนี้จึงเป็นการยืนยันเชิงโครงสร้าง — base class เดียวกัน, methods ที่แชร์ร่วมกันเหมือนกัน, รูปแบบ handler context เหมือนกัน — ไม่ใช่การรันจริง และถึงแม้อินเทอร์เฟซจะตรงกัน พฤติกรรมเบื้องหลังก็ไม่ได้เหมือนกันทั้งหมด: คำแนะนำจาก Crawlee เอง ระบุว่า Playwright จะ auto-wait ให้ element ปรากฏ แต่ Puppeteer ต้องสั่งรอเอง นั่นคือคุณสมบัติของเอนจิน ไม่ใช่ความผิดของ Crawlee แต่หมายความว่า “API เดียวกัน” ไม่ได้แปลว่า “โค้ดเดียวกันทุกบรรทัดภายใน handler” เสมอไป

สิ่งที่ผมไม่ได้ทดสอบ

นี่คือสิ่งที่รอบนี้ผมตั้งใจเว้นไว้ เพื่อไม่ให้คุณตีความผลลัพธ์กว้างเกินจริง

• สเกล ทุกอย่างรันบน fixture ขนาดเล็กและ crawl สั้น ๆ บนเว็บสาธารณะ ไม่มีการทดสอบยาว 100–1,000 หน้า จึงยังพูดอะไรไม่ได้มากเรื่อง autoscaling หรือความเสถียรเมื่อเจอโหลดจริง
• การเก็บคิวและ resume ผมไม่เคย kill crawl กลางทางเพื่อดูว่า RequestQueue จะกลับมาทำงานต่อได้สะอาดไหม นี่เป็นความสามารถสำคัญสำหรับงานระยะยาว แต่ผมยังไม่ได้ทดสอบ
• การ export จาก Dataset และ KeyValueStore ผมเขียน export JSON/CSV เองใน harness ดังนั้นความสะดวกของ Dataset/KeyValueStore ที่เป็นจุดเด่นของเฟรมเวิร์ก ผมยังไม่ได้ลอง
• proxy และ session pools Crawlee มีฟีเจอร์ proxy rotation และ fingerprinting มาให้ ผมมองเรื่องนี้ในมุม compliance และ operations เท่านั้น ไม่ได้มองเป็นฟีเจอร์สำหรับหลบ anti-bot และก็ไม่ได้ stress test มันในทางใดทางหนึ่ง

และตัวเลขเวลาทั้งหมดเป็นการรันบนเครื่องเดียว ครั้งเดียว พวกมันแสดงให้เห็น รูปแบบ ของต้นทุนระหว่าง HTTP กับ browser เท่านั้น ไม่ใช่ benchmark และผมจะไม่อ้างแบบนั้น

ข้อดีและข้อเสีย

ข้อดี

• API เดียวใช้ได้ทั้งฝั่ง HTTP และ browser — การสลับเอนจินเป็นแค่การเปลี่ยนคลาสจริง ๆ ยืนยันแล้วจากผล 0 → ข้อมูลครบ ทั้งบน fixture ภายในเครื่องและเว็บไซต์สาธารณะ
• เป็น crawl framework จริง: มี RequestQueue, enqueueLinks พร้อมควบคุม depth, retries และ failedRequestHandler ไม่ใช่แค่ตัว render หน้าเว็บ
• ดึงข้อมูลฝั่ง HTTP ได้แม่นยำและเร็ว (static 12/12, article 3/3, ผ่าน JSON API 8/8) เมื่อ JavaScript ไม่ได้เป็นอุปสรรค
• เส้นทาง browser กู้ข้อมูลที่ HTTP มองไม่เห็น และถ่าย screenshot ได้
• ใช้สัญญาอนุญาต Apache-2.0, เขียนด้วย TypeScript, และยังมีการดูแลต่อเนื่อง

ข้อเสีย

• browser crawler ต้องติดตั้ง npx playwright install chromium แยกต่างหาก (~81.7 MiB) ซึ่ง npm install crawlee ไม่ได้จัดการให้ — ลืมได้ง่าย
• การ render ด้วยเบราว์เซอร์มีต้นทุนต่อหน้าเว็บจริง (~5 วินาที เทียบกับต่ำกว่าหนึ่งวินาทีในการทดสอบหน้าเดียวของผม)
• รันแบบปกติแล้วจะมี side effect คือสร้างโฟลเดอร์ storage/
• เรื่องสเกล, การเก็บคิว/รีซูมหลัง crash, และความสะดวกของการ export จาก Dataset ยังไม่ได้พิสูจน์จากการทดสอบของผม
• ฟีเจอร์ proxy และ fingerprinting ต้องใช้อย่างถูกต้องตามเงื่อนไขของเว็บไซต์และกฎหมาย — เป็นความรับผิดชอบ ไม่ใช่ข้ออ้างให้ใช้งานแบบไม่ระวัง

เมื่อไหร่ควรเลือก Crawlee เทียบกับ Managed API

Crawlee เป็นเครื่องมือแบบคุณสร้างเอง และสำหรับหลายทีม นั่นคือทางเลือกที่เหมาะสมที่สุด เลือกใช้เมื่อคุณอยากถือครอง crawler ไว้ใน codebase Node ของตัวเอง ต้องการผสมการ crawl แบบ HTTP และ browser ในโปรเจ็กต์เดียวโดยไม่ต้องเปลี่ยนเฟรมเวิร์ก และอยากควบคุม queue กับ storage ด้วยตัวเอง ถ้าคุณพร้อมจะรัน และในอนาคตสเกล browser fleet เอง Crawlee จะให้โครงสร้างแกนกลางที่สะอาดและออกแบบมาดีสำหรับรองรับงานนั้น

อีกทางหนึ่งคือไม่ต้องรับภาระโครงสร้างพื้นฐานพวกนั้นเลย ถ้าคุณไม่อยากเสียเวลาคอยดูแล Chromium instances, proxy rotation และการจัดการ anti-bot ทางเลือกคือ managed API — และนั่นคือจุดที่ developer stack ของเราเองที่ Thunderbit เข้ามาเหมาะ สำหรับผู้ใช้สายเทคนิค Thunderbit ไม่ใช่แค่ Chrome extension แต่คือ AI scraping แบบ API, MCP server, และ CLI คุณเรียก POST /distill เพื่อแปลงหน้าเว็บเป็น Markdown ที่สะอาดพร้อมใช้งานกับ LLM หรือ POST /extract พร้อม JSON Schema เพื่อให้ได้ข้อมูลเชิงโครงสร้างกลับมา โดยมี renderMode เป็น none, basic, หรือ full ให้คุณเลือกเองว่าเมื่อไรควรใช้ browser เต็มรูปแบบ MCP server ช่วยให้ AI agent (เช่น Claude, Cursor และ MCP client อื่น ๆ) สั่งสแครปได้ระหว่างทำงาน ส่วน CLI ก็รันได้จาก terminal หรือ CI:

ลองใช้ Thunderbit สำหรับการดึงข้อมูลเว็บ

npx -y @thunderbit/thunderbit-cli distill "<url>" -f markdown > out.md

ความต่างที่สำคัญสำหรับนักพัฒนาคือ Crawlee ส่งมอบวัตถุดิบดิบให้คุณ — HTML ที่ render แล้ว, nodes ที่ parse แล้ว — แล้วคุณเป็นเจ้าของ pipeline เอง ส่วน managed API จะส่ง JSON โครงสร้างพร้อม schema กลับมาให้ โดยจัดการ rendering, CAPTCHA และ anti-bot ฝั่งเซิร์ฟเวอร์ให้แล้ว งานคนละแบบ ถ้าคุณอยากคุมทุกอย่างเองและไม่ติดเรื่อง ops เลือก Crawlee ถ้าอยากได้ข้อมูลโดยไม่ต้องดูแล browser fleet เอง เลือก managed route หลายทีมสุดท้ายใช้ทั้งสองแบบ — แบบหนึ่งสำหรับ crawl เฉพาะกิจ อีกแบบสำหรับงาน “ขอแค่ข้อมูลเป็นโครงสร้างให้ฉัน” คุณดูต้นทุนเปรียบเทียบได้ที่ ราคา Thunderbit

บทสรุป

ควรใช้ Crawlee ไหม? ควร — ถ้าคุณเป็นนักพัฒนา Node หรือ TypeScript ที่อยากได้เฟรมเวิร์กเดียวซึ่งครอบได้ทั้งการ crawl แบบ HTTP และ browser โดยมีคิวการ crawl จริงอยู่ข้างใต้ จุดขายเรื่องสองเอนจินนี่แหละคือเหตุผลหลักในการเลือกมัน และมันผ่านการทดสอบของผมได้ดี: URL เดียวกันเปลี่ยนจาก 0 เป็นข้อมูลครบด้วยการสลับแค่คลาสเดียว การดึงข้อมูลแบบ static แม่นและเร็ว และการ crawl แบบ queue กับ depth ก็ทำงานตรงตามที่เอกสารบอก

แต่ควรเข้าใจสองเรื่องไว้ก่อน: เตรียมงบสำหรับการดาวน์โหลดเบราว์เซอร์ที่ซ่อนอยู่ครั้งแรกที่คุณใช้ PlaywrightCrawler และอย่าคิดว่าสิ่งที่ผมยังไม่ได้ทดสอบ — อย่างสเกล, การ resume หลัง crash, และ export ในตัว — จะดีพอ ๆ กับส่วนที่ผมทดสอบแล้ว จนกว่าคุณจะลองมันบน workload ของตัวเอง ในฐานะรากฐานสำหรับสร้าง crawler ของคุณเอง Crawlee เป็นงานวิศวกรรมที่แข็งแรงและออกแบบมาดีมาก แต่ถ้าคุณต้องการ pipeline ข้อมูลที่เสร็จสมบูรณ์และไม่ต้องลงมือดูแลมาก มันยังเป็นแค่จุดเริ่มต้น ไม่ใช่จุดหมายปลายทาง

ลองใช้ Thunderbit สำหรับการดึงข้อมูลเว็บ Get Started Free

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

Crawlee ฟรีไหม และใช้ไลเซนส์อะไร? ฟรีครับ Crawlee เป็นโอเพนซอร์สภายใต้ไลเซนส์ Apache-2.0 และติดตั้งได้จาก npm (npm install crawlee) เวอร์ชันที่ผมทดสอบคือ 3.17.0 การรัน browser crawler ต้องดาวน์โหลด Chromium แยกผ่าน Playwright ซึ่งก็ฟรี แต่จะเพิ่มขนาดการติดตั้งอีกราว 81.7 MiB

CheerioCrawler กับ PlaywrightCrawler ควรใช้อะไร? ใช้ CheerioCrawler เมื่อข้อมูลอยู่ใน HTML ดิบหรือ JSON API ที่อยู่เบื้องหลัง เพราะมันเร็วมากและไม่เปิดเบราว์เซอร์เลย ใช้ PlaywrightCrawler เมื่อคอนเทนต์ถูกสร้างด้วย JavaScript ซึ่งสังเกตได้จากฝั่ง HTTP ที่คืนผลว่างเปล่า ในการทดสอบของผม เอนจินฝั่ง HTTP ได้ 0 รายการบนหน้าที่ render ด้วย JS ส่วนเอนจินเบราว์เซอร์ได้ครบทั้งหมด เพราะทั้งสองใช้ API เดียวกัน การสลับจึงเป็นแค่การเปลี่ยนคลาส ไม่ใช่การเขียนใหม่

Crawlee ต้องมีเบราว์เซอร์ถึงจะรันได้ไหม? เฉพาะ browser crawler เท่านั้น CheerioCrawler ไม่ต้องใช้เบราว์เซอร์เลย PlaywrightCrawler (และ PuppeteerCrawler) ต้องมี browser binary — ติดตั้งด้วย npx playwright install chromium โปรดทราบว่า npm install crawlee อย่างเดียวจะไม่ได้ดึงเบราว์เซอร์มาให้ ซึ่งเป็นจุดพลาดตอนเริ่มใช้งานครั้งแรกที่พบบ่อยที่สุด

Crawlee รองรับ pagination และ crawl หลายหน้าไหม? รองรับ และนี่คือเหตุผลหลักข้อหนึ่งที่ควรเลือกใช้แทนไลบรารีเบราว์เซอร์เดี่ยว ๆ enqueueLinks ใช้ตามลิงก์ต่อได้ รวมถึง selector สำหรับ pagination เช่น .next-page ส่วน RequestQueue จะ deduplicate และจัดการการ crawl ให้ พร้อมทั้งมีการคุม depth และข้อจำกัด maxRequestsPerCrawl ในการทดสอบ ผม crawl ภายใน hostname เดียวกันได้ 11 หน้าใน depth 0–2 และ request ที่ล้มเหลวก็ถูกส่งผ่าน failedRequestHandler

Crawlee ต่างจาก scraping API แบบ hosted ยังไง? Crawlee เป็นแบบ self-hosted: คุณเขียนและรัน crawler เอง แล้วต้องดูแลเรื่องสเกล, proxies และ anti-bot เอง ส่วน managed API อย่าง endpoints distill/extract ของ Thunderbit จะส่งกลับ Markdown ที่สะอาดหรือ JSON ที่ตรงตาม schema โดยจัดการ rendering และ anti-bot ฝั่งเซิร์ฟเวอร์ให้แล้ว ผ่าน API, MCP server และ CLI เลือก Crawlee ถ้าคุณอยากควบคุม pipeline ของตัวเองแบบเต็มที่; เลือก managed API ถ้าคุณไม่อยากดูแลและสเกล browser infrastructure เอง