รีวิว Puppeteer 24.16: ระบบอัตโนมัติบนเบราว์เซอร์แบบโฟกัส Chrome โดยไม่ใช่เฟรมเวิร์กสำหรับครอว์ลลิง

Puppeteer คือไลบรารี Node จาก Google สำหรับควบคุม Chrome ตัวจริงผ่าน JavaScript — คุณเขียนส่วนอัตโนมัติเอง จากนั้น Chrome DevTools Protocol จะรับคำสั่งไปส่งต่อ และเบราว์เซอร์แบบเต็มรูปแบบจะเรนเดอร์หน้าเว็บก่อนที่คุณจะอ่านข้อมูลใด ๆ ตัวโครงการอยู่ที่ puppeteer/puppeteer บน GitHub: ใช้สัญญาอนุญาต Apache-2.0 เขียนด้วย TypeScript และมีดาวราว 95.3k ดวง (95,307 ดวงในวันที่ผมดึงสแน็ปช็อตมา) คำอธิบายอย่างเป็นทางการตั้งขอบเขตไว้ชัดเจนมาก — “JavaScript API สำหรับควบคุม Chrome (และ Firefox แบบทดลอง)” — ซึ่งบอกทั้งว่าเครื่องมือนี้ทำอะไรได้ และสำคัญไม่แพ้กันคือมันไม่ได้ทำอะไร

ผมทดสอบ Puppeteer 24.16.0 กับเซิร์ฟเวอร์ฟิกซ์เจอร์ชุดเดียวกันและเดโมสาธารณะชุดเดิมที่เราใช้กับไลบรารีบราวเซอร์ออโตเมชันทุกตัว: แค็ตตาล็อกแบบสแตติกที่มีเพจจิเนชัน, บทความหนึ่งหน้า, แค็ตตาล็อกที่เรนเดอร์ด้วย JavaScript, JSON API, เส้นทางที่ตอบกลับ 500, กราฟครอว์ลขนาดเล็ก รวมถึง Books to Scrape และ Quotes to Scrape งานเรนเดอร์ที่มันทำออกมานั้นสะอาดและตรงไปตรงมา และยังเหลืออีกหนึ่งงานบนโต๊ะผม — งานเดียวกับที่ไลบรารี headless browser ทุกตัวเหลือให้ — และความซื่อสัตย์ต่อช่องว่างตรงนี้แหละที่แยกรีวิวที่มีประโยชน์ออกจากข่าวประชาสัมพันธ์

ตัวเลขหนึ่งที่เด่นกว่าค่าความครอบคลุมเสียอีกคือ บนหน้าที่ดึงข้อมูลมาจาก JSON endpoint, Puppeteer ดึงข้อมูลครบทั้ง 8 รายการ โดยไม่ต้องสแครป DOM เลย — มันรัน fetch ภายในหน้าและอ่านอ็อบเจ็กต์ response โดยตรง นั่นรวมกับการเรนเดอร์แบบ native และสกรีนช็อตที่ใช้งานได้ คือภาพของเครื่องมือนี้: renderer สำหรับ Chrome ที่โตเต็มที่ ไม่ใช่เฟรมเวิร์กสำหรับครอว์ลลิง และความต่างนี้สำคัญตั้งแต่ก่อนคุณจะพิมพ์โค้ดบรรทัดแรก

Puppeteer คืออะไรกันแน่ (และมันแข่งกับอะไร)

ป้ายหมวดหมู่ของมันมีผลจริง ๆ ดังนั้นเริ่มจากตรงนี้ก่อน Puppeteer คือ ไลบรารีสำหรับทำงานอัตโนมัติกับเบราว์เซอร์ มันเปิด Chrome เปิดหน้าเว็บ ให้ JavaScript ของหน้านั้นทำงาน แล้วส่งผลลัพธ์ที่เรนเดอร์เสร็จแล้วมาให้คุณอ่านหรือแคปสกรีนช็อต นั่นคือเหตุผลทั้งหมดที่คุณเลือกใช้มันแทน HTTP client บวกตัวแปลง HTML: คุณต้องการหน้าเว็บ หลังจาก สคริปต์ทำงานเสร็จ ไม่ใช่แค่เปลือกว่าง ๆ ที่เซิร์ฟเวอร์ส่งมาก่อน

ในเชิงรูปแบบ มันแข่งกับไลบรารีเบราว์เซอร์จริงอย่าง Playwright และ Selenium ไม่ได้แข่งกับเฟรมเวิร์กครอว์ลลิงอย่าง Scrapy หรือเครื่องมือ LLM-Markdown ถ้าคุณส่ง URL เป็นพัน ๆ ให้ Puppeteer แล้วคาดหวังให้มันคิวงาน, กัน URL ซ้ำ, ควบคุมอัตราการดึงอย่างสุภาพ และเขียนชุดข้อมูลให้ คุณกำลังเอา renderer ไปแก้ปัญหาครอว์ลลิง มันจะเรนเดอร์ทุกหน้าสวยมาก แต่จะไม่จัดการออร์เคสตราชันให้เลย (นี่คือขอบเขตการใช้งาน ไม่ใช่บั๊ก — ผมจะย้อนกลับมาพูดเรื่องนี้อีก เพราะนี่คือสิ่งสำคัญที่สุดที่ต้องเข้าใจก่อนเริ่มใช้เครื่องมือนี้)

Puppeteer มาจากทีม Chrome ของ Google จึงถูกออกแบบให้เป็น Chrome-first และ API ของมันก็อ่านเหมือนถุงมือบาง ๆ ที่คลุมโปรโตคอลดีบักของเบราว์เซอร์อยู่พอดี มันแก่พอที่จะน่าเบื่อในทางที่ดี: เมธอดที่คุณต้องใช้เสถียรมาหลายปีแล้ว เอกสารละเอียด และระบบนิเวศรอบตัวลึกมาก

การเรนเดอร์แบบ native และแพตเทิร์น fetch ภายในหน้า

มีพฤติกรรมสองอย่างที่ควรดึงออกมาพูดแยกจากตารางผลลัพธ์ เพราะมันสะท้อนวิธีใช้งานจริงของเครื่องมือนี้ได้ชัดเจน

อย่างแรกคือการเรนเดอร์แบบ native แค็ตตาล็อกที่เรนเดอร์ด้วย JavaScript — หน้าเว็บที่สร้างกริดสินค้าในฝั่ง client หลังโหลดเสร็จ — ได้ผล 8/8 พร้อมบันทึกสกรีนช็อตเต็มหน้าไว้ในดิสก์ การตั้งค่าค่อนข้างน้อยแต่มีการรอเนื้อหาหลัง goto อยู่ด้วย หน้า Quotes to Scrape JS สาธารณะก็ดึงครบทั้งสิบคำคมด้วยแพตเทิร์นเดียวกัน นี่คือผลลัพธ์จากฟิกซ์เจอร์ ไม่ใช่คะแนน recall แบบทั่วไปของการเรนเดอร์

อย่างที่สองคือฟิกซ์เจอร์ JSON API โหลดสินค้าจาก /api/dynamic-products การรัน fetch แบบ same-origin ผ่าน page.evaluate ดึงข้อมูลครบทั้ง 8 รายการได้โดยไม่ต้องพาร์สแถวที่เรนเดอร์ออกมา นี่คือแพตเทิร์นการประเมินผลฝั่งเบราว์เซอร์ทั่วไป ไม่ใช่ความสามารถค้นพบข้อมูลเฉพาะของ Puppeteer มันช่วยให้การดึงข้อมูลง่ายขึ้นได้เมื่อรู้ endpoint และสัญญาการเรียกใช้งาน แต่เฮดเดอร์การยืนยันตัวตน โทเค็นขณะรัน นโยบายคุกกี้ CORS/CSP service worker และเพจจิเนชัน ยังอาจทำให้ request จริงของแอปแตกต่างออกไป

สิ่งที่สามที่ควรจำไปต่อไม่ใช่ตัวเลข แต่เป็นกรอบความคิด: Puppeteer คือ Chrome renderer ที่โตเต็มที่ และมันไม่ใช่ crawler ทั้งสองอย่างนี้จริงหมด และครึ่งหลังคือสิ่งที่บทความจำนวนมากมักละไว้

Puppeteer คุยกับ Chrome อย่างไร

บน Chrome, Puppeteer ใช้ Chrome DevTools Protocol (CDP) ซึ่งเป็นช่องทาง JSON-over-WebSocket ที่ DevTools ของเบราว์เซอร์ใช้ puppeteer.launch() จะสตาร์ต Chrome และเปิดการเชื่อมต่อโปรโตคอลนี้ คำสั่งอย่าง goto, $$eval และ screenshot จะแสดงความสามารถของเบราว์เซอร์ผ่าน API ระดับสูงกว่า ส่วนการรองรับ Firefox จะใช้เส้นทาง WebDriver BiDi ตามที่อธิบายไว้ด้านล่าง ดังนั้นไม่ใช่ทุกคำสั่งของ Puppeteer จะเป็น CDP command ได้เหมือนกันหมด

page.evaluate รันฟังก์ชันในบริบทของหน้าเว็บ ดังนั้น fetch('/api/...') แบบ relative จะใช้ origin ของหน้านั้น และอาจใช้คุกกี้กับสถานะเซสชันที่เข้ากันได้ซ้ำได้ มันไม่ได้จำลองเฮดเดอร์ยืนยันตัวตนที่แอปสร้างขึ้นเอง, ตัวเลือก request, โทเค็น หรือพฤติกรรมของ service worker โดยอัตโนมัติ บนฟิกซ์เจอร์ same-origin ชุดนี้มันคืน JSON ได้ตรง ๆ แต่ request ในโปรดักชันจำเป็นต้องตรวจสัญญาจริงของมัน

และนี่คือเหตุผลที่ Puppeteer “หนัก” ด้วย ทุกหน้าเว็บคือแท็บเบราว์เซอร์จริงที่มี engine จริงอยู่เบื้องหลัง ซึ่งแลกกับความถูกต้องบนหน้าที่พึ่งพา JavaScript สูง แต่ต้องจ่ายด้วยหน่วยความจำและเวลาเริ่มต้นมากกว่าเครื่องมือที่ดึงด้วย HTTP อย่างเดียว ไม่มีการเรนเดอร์ฟรี ๆ; CDP แค่ทำให้ใบเสร็จอ่านง่ายขึ้น

เรื่องของเอนจิน พูดกันตรง ๆ

มีคำพูดติดปากที่บอกว่า Puppeteer คือ “Chrome-only” สำหรับเวอร์ชันที่ผมทดสอบนั้น ไม่จริง และการเข้าใจให้ถูกจะเปลี่ยนการเทียบเครื่องมือไปเลย

ทั้ง Chrome for Developers และ Mozilla ต่างออกมาประกาศการรองรับ Firefox ตอนที่ฟีเจอร์นี้เปิดตัวจริง รุ่นที่ผมรันคือ 24.16.0 ซึ่งเลย v23 ไปมากแล้ว ดังนั้นคำว่า “Chrome-only” จึงบอกความจริงได้น้อยกว่าที่แพ็กเกจนี้มีอยู่จริง การไม่มี WebKit รวมถึงเรื่อง cross-engine ที่เพิ่งเริ่มต้นเมื่อเทียบกับ Playwright ต่างหากคือความแตกต่างด้านความกว้างที่แท้จริง — ไม่ใช่แค่ “หนึ่งเอนจินเทียบกับสามเอนจิน”

เส้นทาง Firefox/BiDi มีเอกสารรองรับและใช้งานได้ในเวอร์ชันที่ผมทดสอบ แต่ผมไม่ได้รันฟิกซ์เจอร์ผ่านเส้นทางนั้น ดังนั้นผมรายงานในฐานะความสามารถ ไม่ใช่ผลการวัด ถ้า Firefox เป็นเรื่องสำคัญกับเป้าหมายของคุณ ควรลองกับหน้าเว็บจริงของคุณก่อนตัดสินใจ สำหรับคนที่อยากเทียบแบบตัวต่อตัวทั้งเรื่องเอนจินและภาษาที่รองรับ บทความ Playwright-vs-Puppeteer comparison ของเราใช้ชุดทดสอบเดียวกันทั้งสองฝั่งและสรุปคำตอบว่า “ควรเลือกตัวไหน” ไว้ที่นั่น ส่วนบทความนี้โฟกัสที่ Puppeteer เพียงตัวเดียว

การติดตั้งและการใช้งานจริง: ตัวหนักคือตัวเบราว์เซอร์

เส้นทางค่าเริ่มต้น npm install puppeteer จะดาวน์โหลด Chrome for Testing รุ่นที่เข้ากันได้ พฤติกรรมนี้สามารถปิดหรือเปลี่ยนเส้นทางได้ผ่านคอนฟิก และผู้ใช้สามารถชี้ Puppeteer ไปยัง executable ตัวอื่นได้ ดังนั้นการจับคู่เวอร์ชันจึงขึ้นอยู่กับทางเลือกในการดีพลอย การดาวน์โหลดเบราว์เซอร์คือส่วนที่หนักที่สุดของการติดตั้งครั้งนี้; สแน็ปช็อตจากตัวจัดการแพ็กเกจไม่ถือเป็นคุณสมบัติด้านความปลอดภัยถาวร

การแพ็กเบราว์เซอร์มาให้โดยอัตโนมัติเป็นทั้งข้อดีด้านการใช้งานจริง และก็เป็นภาระด้านขนาดไฟล์จริง ๆ เช่นกัน และควรพูดถึงทั้งสองด้าน ข้อดีคือคุณไม่ต้องหาบราวเซอร์ที่เข้ากันหรือ pin เวอร์ชันเอง npm install ก็ได้คู่ที่ใช้งานได้เลย ข้อเสียคือคุณกำลังดาวน์โหลดเบราว์เซอร์ทั้งตัว จึงต้องเผื่อพื้นที่ดิสก์และแบนด์วิดท์ โดยเฉพาะใน CI ที่แคชว่างจะต้องจ่ายค่านี้ทุกครั้งที่ runner ใหม่เริ่มทำงาน

นี่ยังเป็นความต่างที่ชัดเจนกับ Playwright ซึ่งแยกเป็นสองขั้นตอน — ติดตั้งไลบรารีก่อน แล้วค่อยรัน npx playwright install เพื่อดึง browser build ของมันมา ทั้งสองวิธีไม่ได้ลำบาก เพียงแต่ล้มเหลวคนละแบบ Puppeteer สั่งครั้งเดียวอาจทำให้คุณประหลาดใจกับขนาดไฟล์บนเครือข่ายที่คิดปริมาณตามการใช้งาน ขณะที่ขั้นตอนที่สองของ Playwright อาจถูกลืม Know ว่าคุณกำลังใช้แบบไหนอยู่

ผลลัพธ์ภาคปฏิบัติ

การทดสอบทุกชุดรันบนเซิร์ฟเวอร์ฟิกซ์เจอร์ภายในที่ 127.0.0.1 ร่วมกับเว็บสาธารณะสำหรับฝึกอีกสองแห่ง บน Node v22.22.3, macOS arm64 โดยใช้ Puppeteer 24.16.0 และ Chrome ที่มากับแพ็กเกจเอง ข้อมูลจริงของแต่ละฟิกซ์เจอร์ถูกบันทึกไว้ก่อนรัน ดังนั้น recall จึงวัดเทียบกับชุดที่คาดไว้แบบตายตัว ไม่ใช่สิ่งที่ Puppeteer พิมพ์ออกมาในรอบนั้น

ชุดวิจัยสาธารณะมี fixture server, test runner และ ground truth อยู่แล้ว แต่ไม่ได้ใส่ dependency lock และ raw run summary ไว้ในแพ็กเกจเผยแพร่ เพราะการตรวจสอบความปลอดภัยแบบเข้มงวดไม่ผ่านข้อมูล dependency-lock และข้อมูล endpoint ที่ผูกกับสภาพแวดล้อม หากต้องการทำซ้ำฟิกซ์เจอร์ local ที่ปลอดภัย ให้รัน npm install แล้วตามด้วย node run_puppeteer_material_tests.mjs ภายใน tools/puppeteer/tests จากนั้นเปรียบเทียบผลกับ ground truth ที่เผยแพร่ไว้ หน้าเดโมสาธารณะอาจเปลี่ยนได้ ดังนั้นฟิกซ์เจอร์ local จึงเป็นฐานที่เสถียรกว่าสำหรับการตรวจจำนวนที่คาดไว้

ถ้าต้องการกู้คืน dependency ตามประวัติแบบเป๊ะ ๆ ให้สร้างและตรวจไฟล์ lock ใหม่ในเครื่อง แทนการเอา lock ที่ไม่ได้เผยแพร่มาใช้เป็นหลักฐานสาธารณะ

มีบางจุดที่ควรขยายความมากกว่าที่ตารางบอก

โค้ดเพจจิเนชันที่เขียนเองดึงรายการในแค็ตตาล็อกที่คาดไว้ครบทั้ง 12 รายการ ตัวเลือกสำหรับดึงบทความจับ title และย่อหน้าหลักที่ต้องการได้ครบ 3 ย่อหน้า ส่วน boilerplate รอบ ๆ ยังคงอยู่ใน DOM ให้เข้าถึงได้ Puppeteer เป็นคนส่ง DOM ที่เรนเดอร์มาให้ ส่วนลอจิกของ selector — ไม่ใช่ Puppeteer เอง — คือสิ่งที่กำหนดว่าอะไรนับเป็นเนื้อหาบทความ

บนเส้นทาง HTTP 500 ที่ทดสอบ goto คืน response object ที่ตรวจสถานะ 500 ได้ และไม่โยน exception สิ่งนี้ไม่ได้บอกอะไรเกี่ยวกับ timeout, DNS failure, browser crash, detached frame หรือ error อื่น ๆ ของการนำทาง ซึ่งยังต้องจัดการแยกเอง

กราฟครอว์ลคือกรณีที่เล่าเรื่องได้ครบที่สุด การไล่ลิงก์ภายในของฟิกซ์เจอร์ไปครบ 12 หน้า พร้อมติดตามความลึกเพื่อไม่ให้เยี่ยม URL เดิมซ้ำ จำเป็นต้องใช้ breadth-first search ที่เขียนเอง — เพราะ Puppeteer ไม่มีคิวครอว์ลในตัว มันเจอครบทั้ง 12 หน้าในระดับความลึก {0:1, 1:4, 2:7} ซึ่งแปลว่า BFS ของผมทำงาน แต่ BFS นั้นเป็นของผมเอง Puppeteer แค่เรนเดอร์แต่ละหน้า ส่วนลอจิกเดินเว็บไซต์คือโค้ดที่ผมเขียน สำหรับ 12 หน้า นั่นก็แค่โค้ดไม่กี่บรรทัดและไม่ใช่เรื่องใหญ่ แต่ถ้าเป็น URL หลายพันพร้อม dedup, retry และหน่วงแบบสุภาพ โค้ดไม่กี่บรรทัดนั้นจะกลายเป็นโปรเจกต์เต็มตัว

ข้อควรระวังอีกข้อที่ผมจะย้ำ เพราะเอาไปใช้เกินขอบเขตได้ง่าย: ใน artifacts มีเวลาที่ใช้ต่อการทดสอบ แต่เป็นการสังเกตจากการรันครั้งเดียว เครื่องเดียว ไม่ใช่ benchmark ผมไม่ได้เอา Puppeteer ไปจัดอันดับความเร็วเทียบกับอะไรจากแล็ปท็อปเครื่องเดียวและการรันครั้งเดียว ตัวเลขที่นี่รองรับเรื่อง recall และพฤติกรรมในหน้าเว็บ 8 ประเภท — ไม่ใช่คำอ้างเรื่องความเร็วแบบจับเวลา

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

เพื่อไม่ให้ผลลัพธ์ถูกตีความกว้างเกินจริง นี่คือสิ่งที่อยู่นอกการทดสอบ และจึงอยู่นอกตัวเลขชุดนี้ด้วย:

ไม่มีข้อไหนเป็นการลดคุณค่าของเครื่องมือนี้ นี่คือขอบเขตที่การรันฟิกซ์เจอร์หนึ่งรอบควรอ้างได้อย่างซื่อสัตย์

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

ข้อดี:

• การเรนเดอร์ JavaScript แบบ native พร้อมการรอเนื้อหาแบบชัดเจน: 8/8 บนฟิกซ์เจอร์ไดนามิกและครบทั้ง 10 คำคมบนเดโมสาธารณะ พร้อมสกรีนช็อต
• ตัวเลือกเพจจิเนชันและตัวดึงบทความที่เขียนเองดึงรายการตามฟิกซ์เจอร์ได้ครบ
• fetch ภายในหน้าอ่านข้อมูลจาก same-origin endpoint ที่รู้จักได้ครบ 8 รายการโดยไม่ต้องพาร์ส DOM
• HTTP 500 ที่ทดสอบกลับมาเป็น response ที่ตรวจสอบได้โดยไม่เกิด exception
• การติดตั้งค่าเริ่มต้นดาวน์โหลด Chrome for Testing ที่เข้ากันได้ และยังตั้งค่าใช้ executable อื่นหรือข้ามการดาวน์โหลดได้
• API ที่โตเต็มที่และเน้น Chrome ผ่าน CDP พร้อม ecosystem ลึกและเอกสารละเอียด, Apache-2.0
• กว้างกว่าชื่อเสียงที่คนมองไว้: มีเอกสารรองรับ Firefox ผ่าน WebDriver BiDi ตั้งแต่ v23

ข้อเสีย:

• ไม่มีคิวครอว์ล, ตัวเขียน dataset หรือ throttle ในตัว — งานระดับครอว์ลต้องเขียนเองหรือใช้ wrapper ช่วย
• ไม่มีเอนจิน WebKit และเรื่อง cross-engine ยังใหม่กว่า Playwright
• ภาระของเบราว์เซอร์จริง: ต้องดาวน์โหลด Chrome ที่แพ็กมาด้วย และมีต้นทุนหน่วยความจำต่อหน้าเมื่อเทียบกับเครื่องมือ HTTP-only
• เป็นฝั่ง Node; ถ้าจะใช้จากภาษาอื่นต้องสร้างและดูแลสะพานเชื่อมเอง
• เวอร์ชันที่ผมรัน (24.16.0) ตามหลัง npm latest (25.3.0) อยู่หนึ่ง major version — ควรตรวจซ้ำกับเวอร์ชันปัจจุบันก่อนเชื่อเลขแบบเป๊ะ ๆ

เหมาะกับใคร และใครควรข้าม

เลือก Puppeteer ถ้าคุณทำงานใน Node, เป้าหมายของคุณแสดงผลได้ดีใน Chrome (ซึ่งส่วนใหญ่เป็นแบบนั้น) และคุณต้องการไลบรารีที่โตเต็มที่และโฟกัสชัดเจน ที่เปลี่ยน “หน้าเว็บหลัง JavaScript ทำงานเสร็จ” ให้กลายเป็นสิ่งที่คุณอ่านและแคปสกรีนช็อตได้ สำหรับการสแครปหน้าไดนามิกหลาย ๆ หน้า หรือดึง JSON API ด้วยเซสชันของหน้าเอง หรือเก็บสกรีนช็อตของหน้าที่เรนเดอร์แล้วไว้เป็นหลักฐาน มันเป็นตัวเลือกตั้งต้นที่ดีและไม่วุ่นวาย เส้นทาง Firefox ผ่าน BiDi มีให้ใช้ถ้าคุณขยายการใช้งานไปถึงจุดนั้น และ ecosystem ของมันก็หมายความว่าปัญหาส่วนใหญ่ที่คุณเจอ มักมีคนเจอมาก่อนแล้ว

แต่ควรคิดให้ดีกว่าหนึ่งครั้งถ้าปัญหาของคุณคือการจัดการครอว์ล ไม่ใช่การเรนเดอร์ ถ้าคุณต้องไล่ URL หลายร้อยหรือหลายพันรายการพร้อม dedup, retry และ rate limit, Puppeteer เพียงอย่างเดียวจะบังคับให้คุณสร้าง crawler ขึ้นมาเอง — ซึ่งเป็นระดับชั้นงานที่ไม่เหมาะกับมันเลย ถ้าเพจของคุณไม่ต้องใช้ JavaScript เพื่อเปิดเผยข้อมูล ก็ไม่ต้องใช้ headless browser ทั้งก้อน เพราะเมื่อ HTTP request กับ parser ดึงเนื้อหาได้ เบราว์เซอร์จริงก็เป็นของแพงที่เกินจำเป็น และแค่เปลืองหน่วยความจำกับเวลาเซ็ตอัป และถ้าคุณต้องการความแม่นใน WebKit หรือไคลเอนต์ที่ไม่ใช่ JavaScript เครื่องมือนี้ก็ไม่ตรงโจทย์

ทางเลือกอื่น และ Thunderbit เข้ามาตรงไหน

เริ่มจากกรอบความคิดที่ซื่อสัตย์ก่อน: Puppeteer ฟรี ใช้ Apache-2.0 โฮสต์เองได้ และคุณต้องดูแลทุกส่วนของการใช้งานมันเอง — ทั้ง browser fleet, โค้ดครอว์ลที่คุณต่อเพิ่ม และเกมไล่จับ anti-bot ที่ไม่มีวันจบ สำหรับหลายโปรเจกต์ การเป็นเจ้าของแบบนี้คือคำตอบที่ถูกต้อง และไม่มีบริการแบบ managed ใดจะเรนเดอร์หน้าเว็บที่คุณได้รับอนุญาตได้ถูกกว่าเบราว์เซอร์ที่คุณมีอยู่แล้ว

ในโลก open source การเทียบที่มีประโยชน์ควรมองตามงาน ไม่ใช่ตามโลโก้ สำหรับงานระดับครอว์ลโดยเฉพาะ Crawlee คือคู่ประกบที่เหมาะ: PuppeteerCrawler ของมันห่อ Puppeteer ด้วย request queue, dataset และ throttling ที่ไลบรารีไม่ได้ให้มา คุณจึงได้ส่วนเรนเดอร์และได้ออร์เคสตราชันเพิ่ม ถ้าเป้าหมายผลลัพธ์ของคุณคือ Markdown ที่สะอาดเพื่อป้อนเข้า pipeline ของ LLM ไม่ใช่ DOM ที่เรนเดอร์แล้ว Crawl4AI ก็ขับเบราว์เซอร์จริงและสร้างสิ่งนั้นออกมาได้พอดี ถ้าเว็บของคุณไม่ต้องใช้เบราว์เซอร์เลย เฟรมเวิร์กแบบ HTTP-first อย่าง Scrapy ก็เป็นหมวดหมู่ที่ต่างและเบากว่า เมื่อคุณกำลังชั่งหลายตัวพร้อมกัน คู่มือ open-source scraper roundup ของเราจะวางหมวดหมู่เหล่านี้เทียบกันให้เห็นชัด

บริการแบบ managed อย่าง Thunderbit จะย้ายงานดูแลเบราว์เซอร์และการดึงข้อมูลไปอยู่หลัง API รีวิวนี้ไม่ได้รันผ่านฟิกซ์เจอร์ของ Puppeteer ชุดนี้ ดังนั้นจึงไม่มีการอ้างที่จับคู่กันแบบตรง ๆ ในแง่การเรนเดอร์ การบล็อก คุณภาพการดึง หรือค่าใช้จ่าย เส้นแบ่งการตัดสินใจอยู่ที่การรับผิดชอบเชิงปฏิบัติการ: คุณจะดูแลโค้ดเบราว์เซอร์และครอว์ลเอง หรือจ่ายให้ผู้ให้บริการช่วยรับภาระบางส่วนของชั้นงานนั้น

กับ Puppeteer คุณไม่ต้องจ่ายค่าการใช้งานกับ vendor แต่ compute, bandwidth, การดูแลเบราว์เซอร์, การจัดการออร์เคสตราชัน และงานปฏิบัติการยังเป็นภาระของคุณทั้งหมด เส้นทางแบบ managed จะคิดค่าตามการใช้งานและย้ายความรับผิดชอบบางส่วนไปให้ผู้ให้บริการ การทดลองนี้ไม่ได้เปรียบเทียบผลลัพธ์ระหว่างสองทาง

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

บทสรุป

Puppeteer 24.16.0 คุ้มค่าแก่การประเมิน ถ้าคุณทำงานใน Node และต้องการ browser automation แบบเน้น Chrome เฟรมเวิร์กฟิกซ์เจอร์ที่เขียนเองดึงรายการสแตติกได้ 12 รายการ, ดึงรายการไดนามิกได้ 8 รายการ และดึงคำคมจากเดโมสาธารณะได้ 10 คำคม; JSON API same-origin ที่รู้จักดึงได้ 8 รายการผ่าน page.evaluate; สกรีนช็อตใช้งานได้; และ HTTP 500 ที่ทดสอบยังตรวจสอบได้ แต่ผลลัพธ์เหล่านี้เป็นของฟิกซ์เจอร์ที่ระบุชื่อและเวอร์ชัน major ที่เก่ากว่า ไม่ใช่ของการดึงข้อมูลโดยรวม

อย่างไรก็ต้องประเมินขอบเขตให้ถูก Puppeteer คือ renderer ไม่ใช่ crawler: การไล่ 12 หน้าของผมต้องใช้ BFS ที่เขียนเอง เพราะไม่มีคิวในตัว และในสเกลใหญ่ช่องว่างนี้คืองานจริง — จะให้ Crawlee ช่วยหรือเขียนเครื่องจักรเองก็ได้ มันเป็น Chrome-first พร้อมการรองรับ Firefox ผ่าน BiDi แบบมีเอกสาร แต่ไม่มี WebKit ดังนั้นมันไม่ใช่เครื่องมือสำหรับความกว้างข้ามเอนจิน และมันแบกน้ำหนักของเบราว์เซอร์จริง ผมทดสอบ 24.16.0 เทียบกับ latest 25.3.0 ดังนั้นก่อนเชื่อตัวเลขเป๊ะ ๆ ควรรันทดสอบซ้ำบนเวอร์ชันปัจจุบัน ถ้ารู้ทั้งสี่ข้อนี้ก่อนเริ่มใช้ Puppeteer คือไลบรารี Chrome automation ที่ยอดเยี่ยม แต่ถ้าคาดหวังให้มันครอว์ลเว็บไซต์แทนคุณ คุณกำลังจะเขียน crawler ที่คิดว่าตัวเองดาวน์โหลดมาแล้ว

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

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

Puppeteer เรนเดอร์หน้า JavaScript ได้ไหม หรือจำเป็นต้องมีปลั๊กอิน? มันเรนเดอร์ได้เลยแบบ native ไม่ต้องมีปลั๊กอิน บนฟิกซ์เจอร์ไดนามิกของผม มันดึงสินค้าที่สร้างฝั่ง client ได้ครบ 8 จาก 8 รายการด้วย recall 1.0 พร้อมสกรีนช็อตเต็มหน้า และหน้า Quotes to Scrape JS สาธารณะก็ดึงครบทั้ง 10 คำคมด้วยวิธีเดียวกัน — แค่ goto แล้วอ่าน DOM ที่เรนเดอร์เสร็จแล้ว เพราะ Puppeteer ควบคุม Chrome จริงผ่าน DevTools Protocol สคริปต์ของหน้าจึงทำงานก่อนที่คุณจะอ่านอะไร

Puppeteer ดึงข้อมูลจาก JSON API โดยไม่ต้องพาร์ส HTML ได้ไหม? ได้ ถ้า endpoint และสัญญาการเรียกใช้งานเอื้อให้ทำ page.evaluate สามารถส่ง request จาก origin ของหน้า และอาจใช้คุกกี้ที่มีสิทธิ์ร่วมได้ แต่ไม่ได้จำลองเฮดเดอร์ แอป, โทเค็น, ตัวเลือก หรือพฤติกรรมของ service worker ให้อัตโนมัติ บนฟิกซ์เจอร์ same-origin มันดึงครบทั้ง 8 รายการโดยไม่ต้องพาร์ส DOM

Puppeteer เป็น web crawler ไหม? ไม่ใช่ — มันคือไลบรารีทำงานอัตโนมัติกับเบราว์เซอร์ ไม่ใช่เฟรมเวิร์กครอว์ลลิง มันไม่มีคิว request, ตัวเขียน dataset หรือ throttle ในตัว ดังนั้นการครอว์ล 12 หน้า (ระดับความลึก {0:1, 1:4, 2:7}) ของผมจึงต้องใช้ breadth-first search ที่เขียนเอง นี่คือขอบเขตการใช้งาน ไม่ใช่ข้อบกพร่อง ถ้าจะทำงานระดับครอว์ล ให้จับคู่กับ wrapper อย่าง PuppeteerCrawler ของ Crawlee ซึ่งเพิ่มคิวและกลไก dataset ที่ Puppeteer ไม่ได้ให้มา

Puppeteer ใช้ได้เฉพาะ Chrome ไหม? ไม่ใช่อีกต่อไปแล้ว มันเน้น Chrome ผ่าน CDP แต่ตั้งแต่ v23 เป็นต้นมา มีเอกสารรองรับ Firefox ผ่าน WebDriver BiDi และเวอร์ชันที่ผมทดสอบ (24.16.0) ก็เลยจุดนั้นมานานแล้ว สิ่งที่มันไม่รองรับคือ WebKit และเส้นทาง cross-engine ของมันยังใหม่กว่า Playwright — ตรงนี้ต่างหากคือข้อจำกัดที่ถูกต้อง ไม่ใช่ “Chrome-only” อย่างที่มักพูดกัน ผมทดสอบเฉพาะ Chrome ที่นี่ ดังนั้นสิ่งที่กล่าวถึง Firefox ผ่าน BiDi จึงเป็นการอ้างอิงตามเอกสาร ไม่ใช่ผลที่ผมวัดจริง

ติดตั้ง Puppeteer แล้วมันดาวน์โหลดอะไรมาให้จริง ๆ? โดยค่าเริ่มต้น npm install puppeteer จะดาวน์โหลด Chrome for Testing รุ่นที่เข้ากันได้ การดาวน์โหลดนี้สามารถข้ามหรือเปลี่ยนเส้นทางได้ และยังตั้งค่า executable ตัวอื่นได้ด้วย ดังนั้นการจับคู่เวอร์ชันขึ้นอยู่กับทางเลือกในการดีพลอย คุณควรเผื่อพื้นที่ดิสก์และแบนด์วิดท์สำหรับเบราว์เซอร์ โดยเฉพาะบน CI runner ที่ยังไม่มีแคช รีวิวนี้ทดสอบ 24.16.0; ควรรันทดสอบหลักซ้ำบนเวอร์ชันที่เป็น current ตอนเผยแพร่