cheerio ใช้เวลา 2.9 วินาทีบนหน้าเว็บขนาด 10 MB ใน Node

บนเครื่องหนึ่ง cheerio ใน Node ใช้เวลาแยกวิเคราะห์และดึง title พร้อม href ออกจากไฟล์ HTML สังเคราะห์ขนาด 10 MB รวม 2,927.89 ms ขณะที่ selectolax ที่รันผ่าน CPython พร้อมพาร์เซอร์ฝั่ง C ทำงานเดียวกันเสร็จใน 158 ms ผลลัพธ์ของ title ที่จัดเรียงแล้วและแฮชของ href ตรงกัน นี่คือการเปรียบเทียบแบบ end-to-end ข้าม runtime ไม่ใช่คำตัดสินเฉพาะอัลกอริทึมของพาร์เซอร์ตัวใดตัวหนึ่ง

บนหน้าเว็บขนาด 10 KB ช่องว่างมีแค่ 2 เท่า ซึ่งแทบไม่มีใครสังเกตเห็น คำถามจริง ๆ คือหน้าเว็บของคุณอยู่ตรงไหนบนเส้นโค้งนั้น

cheerio คืออะไร

cheerio คือ HTML parser สำหรับ Node ที่ใช้ไวยากรณ์แบบ jQuery และด้วยเหตุผลที่ดีมันจึงเป็นตัวเลือกมาตรฐานใน ecosystem นี้: 30,449 GitHub stars, ใช้สัญญาอนุญาต MIT และมีการ push เข้าระบบก่อนวันที่ฉันทดสอบเพียงหนึ่งวัน เวอร์ชันที่ทดสอบ: 1.2.0

เอกสารอ้างอิงอย่างเป็นทางการ: บทนำอย่างเป็นทางการของ Cheerio.

import * as cheerio from "cheerio";
const $ = cheerio.load(html);
const titles = $("h3.title").map((_, e) => $(e).text()).get();
const hrefs = $("a").map((_, e) => $(e).attr("href")).get();

ถ้าคุณเคยเขียน jQuery มาก่อน คุณก็จะคุ้นกับ API นี้อยู่แล้ว ความคุ้นมือแบบนี้เองคือเหตุผลสำคัญที่มันชนะใน ecosystem ของตัวเอง

ภายในไม่ได้มีพาร์เซอร์ตัวเดียว แต่เป็นสแต็กของหลายส่วน: htmlparser2 และ parse5 สำหรับการ parse, domhandler และ domutils สำหรับโครงสร้าง tree, cheerio-select สำหรับ selector รวมถึง undici, encoding-sniffer และอื่น ๆ — มี 11 direct dependencies, เมื่อ resolve แล้วกลายเป็น 22 แพ็กเกจระดับบนสุด และกินพื้นที่ 9.0 MiB บนดิสก์ แพ็กเกจเหล่านี้ช่วยเรื่องการ parse และการตรวจจับ encoding แต่ก็เพิ่มภาระของ dependency footprint ด้วย รีวิวนี้ทดสอบผลลัพธ์จาก input ที่ผิดรูปแบบ แต่ไม่ได้ทดสอบความถูกต้องของ encoding หรือแยกทดสอบ backend ของพาร์เซอร์แต่ละตัว

วิธีวัดผล และทำไมจึงเชื่อถือได้

ฐานข้อมูลการวิจัยชุดนี้มี benchmark พาร์เซอร์อยู่แล้ว: ขนาดหน้าเว็บ 5 ระดับตั้งแต่ 1 KB ถึง 10 MB, 50 รอบต่อหนึ่งขนาด, รันอิสระ 3 ครั้ง และส่วนสำคัญที่สุดคือ มี parity gate ที่แฮชเนื้อหาที่ดึงออกมา โดยใช้ title ที่เรียงแล้วกับ href ที่เรียงแล้ว เทียบกับ reference parser ถ้าพาร์เซอร์ตัวใดเงียบ ๆ ข้ามงานบางส่วน มันจะไม่ผ่านให้เวลาที่ดูดี

การเพิ่ม cheerio เข้ามาต้องตรวจสองเรื่องก่อนจะนับตัวเลขใด ๆ

reference ยังอยู่ตำแหน่งเดิมไหม? มีการรัน selectolax ซ้ำใน session เดียวกัน ด้วย fixtures ชุดเดิม hash ของเนื้อหาที่ดึงออกมาตรงกันใน 5 จาก 5 ขนาด และค่า p50 อยู่ระหว่าง 0.989× ถึง 1.079× ของตัวเลขที่เผยแพร่ไว้ ดังนั้นนี่คือเครื่องเดิมที่สร้างตารางต้นฉบับ

cheerio สร้างฟิลด์ที่ให้คะแนนเหมือนกันไหม? hash ของเนื้อหา — คำนวณใน Node ด้วยกฎเดียวกันทุกประการ คือ SHA-256 บน title text ที่เรียงแล้วและ href ที่เรียงแล้ว — ตรงกับ reference ครบ 5 จาก 5 ขนาด นั่นยืนยันความสอดคล้องของฟิลด์ที่จัดเรียงเหล่านี้บน fixtures ชุดนี้เท่านั้น ไม่ได้ยืนยันรูปทรง DOM, ลำดับในเอกสาร, attributes, normalization ของข้อความ หรือการกู้คืนจาก error

เมื่อผ่านสองด่านนี้แล้ว ตัวเลขเวลาใช้งานจึงค่อยมีความหมาย

p50 หน่วยมิลลิวินาที เป็นค่ามัธยฐานจาก 3 ครั้งรัน parser-bench.json. พาร์เซอร์ Python ทั้ง 3 ตัวรันในโปรเซสเดียว ส่วน cheerio รันใน Node 22 ซึ่งเป็นทั้งเส้นแบ่งของ runtime และ library — ดูด้านล่าง

อ่านตารางนี้อย่างซื่อสัตย์

แถว 1 KB เป็น noise ในพาร์เซอร์ Python ทั้ง 3 ตัว ช่องว่างที่ขนาดนี้อยู่ที่ 77.6% และผลแต่ละรอบทับกันมาก — selectolax อยู่ระหว่าง 0.0267 ถึง 0.0404 ms ใน 3 ครั้งที่รัน เมื่ออยู่ที่ 28 ไมโครวินาที ความละเอียดของ timer และ scheduling จะเป็นตัวกำหนดหลัก ผมจะไม่จัดอันดับอะไรที่ 1 KB รวมถึง cheerio ด้วย

ช่วงกลางของตารางไม่ได้น่าตื่นเต้น ต่างกันราว 2× ถึง 4× บนหน้าขนาด 10 KB ถึง 1 MB ถ้าเป็น scraper ที่ประมวลผลแค่ไม่กี่ร้อยหน้า นั่นก็แค่ 45 มิลลิวินาทีต่อหน้าแทนที่จะเป็น 15 และคุณแทบไม่รู้สึก

แถว 10 MB ไม่ใช่ noise cheerio ใน 3 รอบรันได้ 2,839, 2,928 และ 2,954 ms — ค่อนข้างแน่น และแยกจากแถวอื่นอย่างชัดเจน ผลแบบ end-to-end ที่ 10 MB เบี่ยงออกจากแพตเทิร์นของขนาดเล็กอย่างมาก จุดข้อมูล 5 จุดยังไม่พอจะสรุป asymptotic complexity หรือชี้ว่า runtime, parser, selector, allocation หรือ garbage collection layer ไหนเป็นตัวทำให้กระโดด

มันไปอยู่ในโซนเดียวกับ BeautifulSoup benchmark ที่เผยแพร่ไว้ได้วัดพาร์เซอร์อีก 4 ตัวบน fixture 10 MB เดียวกัน และการเอา cheerio ที่ 2,927.89 ms ไปวางเทียบกับตัวเหล่านั้นคือสิ่งที่มีประโยชน์ที่สุดในบทความนี้:

4 แถวของ Python เป็นตัวเลขที่เผยแพร่ไว้จาก bench_parse.json; ส่วน cheerio มาจากการรันครั้งนี้ reference parser ทำซ้ำได้ภายในช่วง 0.989×–1.079× ระหว่างสองรอบ ดังนั้นความต่างที่น้อยกว่าประมาณ 8% ให้ถือว่าอยู่ในช่วงความไม่แน่นอนนั้น — cheerio เทียบกับ backend html.parser ของ BeautifulSoup (ต่างกัน 5%) ยังอยู่ในช่วงนี้ แต่ cheerio เทียบกับ selectolax (18×) ไม่อยู่

BeautifulSoup คือไลบรารีที่คนหยิบมาใช้เมื่ออยากได้ความสะดวก และยอมรับอยู่แล้วว่ามันช้า — เป็นตัวที่ทุกเธรดเรื่อง performance ใน Python มักจะแนะนำให้เปลี่ยนออก บนเอกสาร 10 MB cheerio ไปอยู่ปลายล่างของโซนเดียวกันนั้น ไม่ได้อยู่ในโซนของพาร์เซอร์ที่ใช้ C ซึ่งมันมักถูกจับไปเทียบด้วย

คำถามเรื่องตัวแทนฝั่ง Node ยังเปิดอยู่ในบทความนี้ โดยไม่ได้ทดสอบทางเลือก Node รุ่นใหม่ ๆ ดังนั้นผลนี้จึงไม่สามารถบอกได้ว่าการสลับไลบรารีเป็นไปไม่ได้ หรือจะตัดทิ้งว่าไม่น่าเชื่อถือพอ มันแค่แสดงเส้นทางของ cheerio ที่วัดได้เมื่อเทียบกับสแต็ก Python ที่ระบุไว้

นี่คือการเปรียบเทียบทั้ง runtime และ library ค่ามิลลิวินาทีของ cheerio มาจาก JIT และ garbage collector ของ Node ส่วนตัวอื่นมาจาก CPython ที่เรียกพาร์เซอร์ฝั่ง C hash ของเนื้อหาเป็นหลักฐานว่างานเดียวกันถูกทำจริง และตัวเลขทั้งสองชุดคือสิ่งที่นักพัฒนาที่เลือกสแต็กจะเจอในทางปฏิบัติ แต่ไม่ควรมีใครตีความว่านี่หมายความว่า "อัลกอริทึมของ cheerio แย่กว่า selectolax 18 เท่า" มันคือสิ่งที่เกิดขึ้นบนเครื่องนี้ ภายใน runtime ดั้งเดิมของแต่ละไลบรารี

สภาพการใช้งานจริง

เอกสารอ้างอิงอย่างเป็นทางการ: Cheerio configuration documentation.

metadata-snapshot.json, ดึงข้อมูลในวันที่เขียนบทความ

npm install cheerio ใช้เวลาไม่ถึง 2 วินาที และดึงมา 9.0 MiB ส่วน cold import วัดได้ 0.056 s ในการรัน converter แยกต่างหากบนเครื่องเดียวกัน

Direct dependencies 11 ตัวถือว่าเยอะสำหรับพาร์เซอร์ และเป็นข้อมูลที่ควรรู้หากคุณตรวจสอบ dependency tree ของตัวเอง: htmlparser2, parse5, parse5-htmlparser2-tree-adapter, parse5-parser-stream, domhandler, domutils, dom-serializer, cheerio-select, encoding-sniffer, undici และ whatwg-mimetype ภายในมีพาร์เซอร์ครบสองชุด เพราะ cheerio เลือกใช้ได้ทั้งสองแบบตามสิ่งที่คุณร้องขอ

30,000 stars และมีการ push เมื่อหนึ่งวันก่อนทดสอบ ถือว่าเป็นสัญญาณการบำรุงรักษาที่ดีมากในหมวดนี้

หน่วยความจำ และ HTML ที่เสียหายส่งผลอย่างไร

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

บริบทการทดสอบความทนทานในภาพรวมดูได้จาก การเปรียบเทียบหน่วยความจำและ HTML ผิดรูปแบบของไลบรารี 10 ตัว.

หน่วยความจำ resident สูงสุด, ใช้ /usr/bin/time -l, เปิดโปรเซสใหม่หนึ่งครั้งต่อหนึ่งเซลล์ — ค่า import floor คือสิ่งที่ไลบรารีใช้เมื่อโหลดแล้วแต่ไม่ทำอะไร ส่วนค่าสูงสุดรวมเอกสารเข้าไปด้วย

memory-results.json. ค่าพื้นฐานของ Python และ Node ไม่ได้เทียบกันตรง ๆ เพราะ interpreter อยู่ในทั้งสองฝั่ง

cheerio มี import floor สูงสุดในตารางผสมนี้ ที่ 66.8 MiB รวมทั้ง Node runtime และ dependencies โปรเซสพีคที่ 398.5 MiB บน fixture 10 MB แถวอื่น ๆ รวมทั้งพาร์เซอร์, ตัวแปลง และตัวดึงบทความ ทำงานหลักไม่เหมือนกัน จึงควรใช้เป็นบริบทเรื่อง process footprint มากกว่าการจัดอันดับประสิทธิภาพเทียบกันโดยตรง แถว turndown ที่เป็น runtime เดียวกันมีพีคสูงกว่ามาก แต่หน้าที่ของมันคือการแปลงเนื้อหา ไม่ใช่สัญญาเรื่องการเลือก title และ href แบบที่วัดสำหรับ cheerio

HTML ที่เสียรูปแบบ เอกสาร 12 ชิ้น แต่ละชิ้นเสียหายคนละอย่าง — tag ไม่ปิด, inline element ซ้อนผิด, attribute ไม่ใส่ quote แต่มีช่องว่าง, มี closer โผล่มาเกิน, ไม่มี <html> เลย, attribute ซ้ำ, เอกสารถูกตัดกลางแท็ก, entity ผิด, <script> ไม่ปิด, ประกาศ charset ที่หลอก, comment ที่มี markup อยู่ข้างใน และการซ้อนลึก 600 ชั้น — บวกกับ control ที่ถูกต้องตามโครงสร้าง 2 ชิ้นในขนาดที่จับคู่กัน เพราะคำว่า "มันคืนค่าอะไรไม่ออกเลย" จะบอกอะไรเกี่ยวกับความ malformed ได้ก็ต่อเมื่อไลบรารีไม่ได้เงียบกับเอกสารที่สะอาดในขนาดเดียวกันด้วย

cheerio โยน error ใน 0 จาก 14 และไม่ได้คืนค่าว่างใน 0 กรณี กู้ sentinel ที่ให้คะแนนได้ 11/22 จาก fixtures ที่ผิดรูปแบบ (malformed-results.json) สำหรับพาร์เซอร์ ตัว scorer จะตรวจ sentinel ของ heading และลิงก์ใน malformed documents ที่ให้คะแนนได้ 11 ชุดเท่านั้น มันไม่ให้คะแนน paragraph sentinel และ fixture ที่มี <script> ไม่ปิดถูกตัดออกไป หากไม่มี baseline ที่ใช้สัญญาเดียวกันในส่วนนี้ 11/22 จึงไม่ใช่อันดับคุณภาพ ข้อสรุปที่รองรับได้คือ cheerio คืนผลลัพธ์ที่ไม่ว่างและไม่โยน error ในทุก input ทั้ง 14 ชิ้นที่เป็น malformed-plus-control ขณะเดียวกันก็กู้ marker ที่ให้คะแนนได้ครึ่งหนึ่ง

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

ข้อดี ไวยากรณ์แบบ jQuery ที่คุ้นมือ ใช้สัญญาอนุญาต MIT มีสัญญาณการบำรุงรักษาที่เห็นเวลาได้จริงด้วย 30,449 stars และ activity ของ repository ในวันก่อนทดสอบ มี parser backend สองแบบและแพ็กเกจที่เกี่ยวข้องกับ encoding แม้การกู้คืนของ backend และความถูกต้องของ encoding จะไม่ได้แยกทดสอบในครั้งนี้ และ hash ของ title + href ที่เรียงแล้วตรงกับ reference ทุกขนาดของ fixture

ข้อเสีย ช้ากว่า selectolax 18.5× บนเอกสาร 10 MB และ 4× บน 1 MB มี direct dependencies 11 ตัว รวมพาร์เซอร์เต็มรูปแบบสองชุด รันได้เฉพาะ Node และเอกสารก็ไม่ได้บอกว่ามีขนาดเท่าไรถึงจะเลิกเป็นตัวเลือกที่ชัดเจน

ใครควรใช้ และใครไม่ควรใช้

ใช้ cheerio ถ้าคุณอยู่บน Node, API แบบ jQuery มีคุณค่า และหน้าเว็บตัวอย่างมีลักษณะใกล้กับขนาดที่ทดสอบจนถึง 1 MB หนึ่งเมกะไบต์คือจุดใหญ่ที่สุดที่ทดสอบก่อนจะกระโดดแรงที่ 10 MB บทความนี้ไม่ได้หาจุดตัดระหว่างสองช่วงนั้นหรืออ้างว่ามีสัดส่วนเว็บเท่าไรอยู่ต่ำกว่านั้น

ควร benchmark ก่อนใช้ หากคุณต้องจัดการ HTML ขนาดใหญ่มาก เช่น รายงานที่สร้างขึ้นอัตโนมัติ, catalog dump หรือหน้ารายการที่ยาวมาก พฤติกรรมกับ XML sitemap ไม่ได้ทดสอบไว้ บน fixture HTML ขนาด 10 MB เวลาราว 2.9 วินาทีต่อเอกสารถือเป็นต้นทุนที่สะสมได้จริง

ถ้าคุณอยู่ฝั่ง Python การเปรียบเทียบนี้บอกอีกเรื่องหนึ่ง: selectolax, lxml และ PyQuery แทบเสมอกันตั้งแต่ 10 KB ขึ้นไป (ต่างกันเพียง 0.5% ถึง 5.4% และช่วงรันซ้อนกัน) ดังนั้นให้เลือกจาก API มากกว่าความเร็ว ช่องว่างของ cheerio เมื่อเทียบกับทั้งสามตัวคือเลขที่น่าสนใจ ไม่ใช่ความต่างระหว่างทั้งสามตัวนั้น

managed API เข้ามาอยู่ตรงไหน

cheerio parse HTML ที่คุณมีอยู่แล้ว มันไม่ได้ดึงข้อมูล, ไม่ render JavaScript และไม่จัดการชั้น anti-bot — ซึ่งบนหลายเป้าหมายจริง นั่นแหละคือครึ่งงานที่ยากกว่า

บริการแบบ managed สำหรับ fetch/render/extraction รวมถึง Thunderbit ของเราเอง อยู่คนละขอบเขตความรับผิดชอบ Thunderbit ไม่ได้ถูก benchmark ในบทความนี้ ประเด็นสำคัญคือการ parse HTML ที่ส่งมาให้ด้วย selector เทียบกับการจ้างระบบอื่นให้ดูแล acquisition, rendering และ extraction; บทความนี้ไม่มีการเปรียบเทียบด้านคุณภาพ, latency หรือค่าใช้จ่ายด้วยเมตริกเดียวกัน

พูดให้แฟร์: ถ้าคุณมี HTML อยู่ในมือและรู้ selector ของตัวเอง cheerio ใช้งานฟรีและสบายมือ แต่ถ้าคุณต้องดึงหน้าเว็บจำนวนมาก หรืออยากบอกแค่ข้อมูลที่ต้องการแทนที่จะไล่ DOM นั่นคือการตัดสินใจอีกแบบหนึ่ง

สำหรับภาพรวมที่กว้างกว่า ดู web scraping API roundup ของเรา และ open-source scraper pillar สำหรับฝั่ง self-hosted ถ้าผลลัพธ์ที่ parse แล้วจะถูกส่งต่อให้โมเดล บทความ converting HTML to Markdown in Python จะช่วยอธิบายว่าความเที่ยงตรงเริ่มหายไปตรงไหน

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

ควรใช้ cheerio ไหม?

ควร ถ้าคุณอยู่บน Node, ความพอดีกับ API สำคัญ และเอกสารตัวอย่างยังอยู่ใกล้ช่วงเล็กถึง 1 MB ที่ทดสอบไว้

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

ตัวเลขที่ต้องจำคือค่า 10 MB บางจุดระหว่าง 1 MB กับ 10 MB ค่าใช้จ่ายของ cheerio จะเลิกไล่ตามตัวอื่นและเริ่มทวีคูณ — 4× กลายเป็น 18.5× ถ้าคลังข้อมูลของคุณมีเอกสารใหญ่ระดับนั้น ควร benchmark ก่อนตัดสินใจ เพราะไม่มีอะไรในตัวไลบรารีที่จะเตือนคุณ

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

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

การเปรียบเทียบ cheerio กับพาร์เซอร์ Python ยุติธรรมหรือไม่? มันคือการเปรียบเทียบสแต็ก ไม่ใช่การเปรียบเทียบอัลกอริทึม พาร์เซอร์ทั้ง 4 ตัวให้ผล title text และ href ที่เรียงแล้วเหมือนกันภายใต้กฎ hash ครบ 5 จาก 5 ขนาดหน้าเว็บ แต่ไม่ได้พิสูจน์ว่าพาร์เซอร์ทั้งหมดเท่ากันทุกมิติ เวลาใช้งานของ cheerio รวมพฤติกรรม runtime ของ Node ส่วนตัวอื่นรวม CPython ที่เรียกพาร์เซอร์ฝั่ง C; การเปรียบเทียบนี้จึงอธิบายตัวเลือก end-to-end เหล่านั้น

ทำไมแถว 1 KB ไม่ถูกจัดอันดับ? เพราะที่ 28 ไมโครวินาที การวัดถูก noise ครอบงำ ใน 3 รอบรัน พาร์เซอร์ Python กระจายกัน 77.6% และผลแต่ละรอบก็ทับกัน การจัดลำดับในขนาดนั้นจึงเป็นแค่อาร์ติแฟกต์ ตั้งแต่ 10 KB ขึ้นไปตัวเลขเสถียรพอให้อ่านได้

อะไรเป็นสาเหตุให้กระโดดที่ 10 MB? การทดสอบนี้ไม่ได้บอก สิ่งที่ยืนยันได้คือการกระโดดนั้นเกิดขึ้นจริงและไม่ใช่ noise: cheerio ใน 3 รอบรันได้ 2,839, 2,928 และ 2,954 ms แยกจากตัวอื่นชัดเจน ขณะที่ช่องว่างที่ 1 MB ยังอยู่ที่ 4× การแยกสาเหตุต้อง profiling backend ของ cheerio แยกกัน ซึ่งอยู่นอกขอบเขตครั้งนี้

มันมี dependencies กี่ตัวกันแน่? Direct dependencies 11 ตัว, เมื่อ resolve แล้วเป็น 22 แพ็กเกจระดับบนสุด, ใช้พื้นที่ 9.0 MiB บนดิสก์ สองตัวในนั้นเป็นพาร์เซอร์เต็มรูปแบบ — htmlparser2 และ parse5 — เพราะ cheerio ใช้ได้ทั้งสองแบบ นั่นคือราคาของการรองรับทั้ง parsing แบบยืดหยุ่นและแบบตามสเปก และเป็นข้อมูลที่ควรรู้ถ้าคุณตรวจสอบ dependency tree

อะไรที่ไม่ได้ทดสอบในบทความนี้? การทดสอบครอบคลุมหน่วยความจำพีคของโปรเซสบนเอกสาร 226 KB หนึ่งชิ้นและ 10 MB หนึ่งชิ้น รวมถึงชุด malformed-plus-control 14 อินพุตที่ cheerio ไม่โยน error เลย คืนผลไม่ว่างทุกอินพุต และกู้ sentinel ที่ให้คะแนนได้ 11/22 มันไม่ได้ทดสอบ streaming ผ่าน parse5-parser-stream, ความถูกต้องของ encoding, การกู้คืนเฉพาะ backend, ตำแหน่งของจุดกระโดดระหว่าง 1 และ 10 MB, การ parse XML หรือทางเลือก Node รุ่นใหม่ ๆ