PyQuery เพิ่มไวยากรณ์แบบ jQuery โดยไม่เพิ่มโอเวอร์เฮดของตัวเลือกในระดับที่มีผลต่อการตัดสินใจตามเบนช์มาร์กนี้

PyQuery นำ API สไตล์ jQuery มาครอบ lxml ไว้ พอเอาไปทดสอบกับหน้าเว็บ 5 ขนาด ตั้งแต่ 1 KB ไปจนถึง 10 MB ค่ามัธยฐานของทั้ง 5 รายการก็ยังต่ำกว่า lxml แบบตรง ๆ อยู่ โดยรวมถึงส่วนต่าง 1.5% ในขนาดใหญ่สุดด้วย แต่ benchmark นี้ยังสรุปไม่ได้ว่า wrapper เร็วกว่า แค่บอกได้ว่าไม่เจอความต่างมากพอจะทำให้ต้องเปลี่ยนใจเรื่องตัวเลือกและการอ่านข้อมูลในการทดสอบครั้งนี้

ผลก็ยังออกมาใกล้ ๆ selectolax ภายในไม่กี่เปอร์เซ็นต์ตั้งแต่ 10 KB ขึ้นไปในค่ามัธยฐานที่แสดง แต่เพราะไม่ได้กำหนดเกณฑ์ความเท่าเทียมไว้ล่วงหน้า ผลแบบนี้จึงควรถูกมองว่า “ใกล้เคียงกัน” มากกว่าจะเรียกว่าเสมอกันทางสถิติ

PyQuery คืออะไร

PyQuery คือไลบรารี Python ที่ให้ API แบบ jQuery สำหรับการเลือกและต่อคำสั่งบนโครงสร้างเอกสาร lxml เวอร์ชันที่ทดสอบคือ 2.1.0, ใช้ไลเซนส์ BSD, มีดาวบน GitHub 2,380 ดวง, เปิดอยู่ 59 issue และมีการ push ล่าสุดเมื่อ 2026-07-27

เอกสารอ้างอิงทางการ: PyQuery documentation.

from pyquery import PyQuery as pq
d = pq(html)
titles = [e.text_content() for e in d("h3.title")]
hrefs = [e.get("href") for e in d("a")]

สิ่งที่มันส่งกลับมายังเป็น element ของ lxml อยู่ดี เพราะฉะนั้นสิ่งที่ทำกับ lxml ได้ก็ยังใช้ได้เหมือนเดิม แนวคิดของเครื่องมือนี้คือ PyQuery เป็นชั้นช่วยให้ใช้งานง่ายขึ้น ไม่ใช่ parser เอง pip install pyquery จะติดตั้ง 3 แพ็กเกจ — lxml, cssselect และ PyQuery เอง — และกินพื้นที่ 20.1 MiB ซึ่งแทบทั้งหมดมาจาก compiled extensions ของ lxml

ถ้าคุณเคยใช้ cheerio บน Node แนวคิด API มันก็คล้ายกันมาก ในการทดสอบนี้ selector สองแบบที่ลองใช้ใช้ได้ทั้งคู่ แต่การทดสอบครั้งนี้ยังไม่ได้พิสูจน์ว่า language ของ selector ระหว่าง cssselect กับ cheerio ตรงกันทั้งหมด

วิธีวัดผล

ฐานงานวิจัยชุดนี้มี benchmark parser อยู่แล้ว และมีจุดแข็งที่ benchmark ทั่วไปมักไม่มี: parity gate ที่ตรวจด้วยการแฮชเนื้อหาที่ดึงออกมา — คือ titles ที่เรียงแล้วบวกกับ hrefs ที่เรียงแล้ว — เทียบกับ parser อ้างอิง เพื่อไม่ให้ library ที่ลดงานโดยข้ามบางขั้นตอนดูเร็วเกินจริง ทดสอบ 5 ขนาดหน้า, 50 รอบต่อชุด และรันอิสระ 3 ครั้ง

การเพิ่ม PyQuery เข้าไปต้องทำ 2 เรื่อง

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

รัน lxml ใน process เดียวกันด้วย benchmark ที่เผยแพร่เดิมบันทึกเครื่องและเวอร์ชัน Python ไว้ แต่ ไม่ได้บันทึกเวอร์ชันไลบรารี ดังนั้นแถวของ lxml อาจมาจาก lxml คนละรุ่นกับที่ PyQuery ครอบอยู่ในครั้งนี้ ถ้าไปเทียบข้ามช่องว่างนั้นก็อาจกลายเป็นการเอา lxml สองเวอร์ชันมาเทียบกัน แล้วเรียกว่าเป็นภาษีจาก wrapper การรัน lxml ควบคู่กันจึงตัดประเด็นนี้ออกไป — ทั้งคู่ใช้ lxml 6.1.1 ใน virtual environment นี้

p50 เป็นมิลลิวินาที ค่ามัธยฐานจากการรัน 3 ครั้ง ทั้งหมดอยู่ใน process เดียวกัน parser-bench.json. แฮชของเนื้อหาทั้ง 3 ชุดตรงกับ reference ทุกขนาด

ภาษีจาก wrapper ที่ไม่พบ

PyQuery ทำเวลาได้ เท่ากับหรือดีกว่า raw lxml ในทุกค่ามัธยฐานที่แสดง นี่ไม่ใช่หลักฐานว่า wrapper ทำให้ parsing เร็วขึ้น สิ่งที่ข้อมูล 3 รอบกับการที่ไม่ได้กำหนดเกณฑ์ความเท่าเทียมไว้ล่วงหน้าสนับสนุนคือ ข้อสรุปแบบแคบ ๆ ว่า test fixture นี้ไม่แสดงโอเวอร์เฮดของ selector ที่มีผลต่อการตัดสินใจ

ที่ 10 MB PyQuery มีรัน 3 ครั้งเป็น 162.86, 163.17 และ 161.13 ms ส่วน lxml เป็น 169.46, 165.25 และ 164.18 ช่วงค่าค่อนข้างใกล้กันแต่ไม่ทับกัน ที่ 1 MB ค่ามัธยฐานของทั้งสองต่างกันแค่ 0.5% ชุดรันเล็ก ๆ แบบนี้ช่วยให้ตัดสินในเชิงปฏิบัติได้ แต่ยังไม่พอจะอ้างความเท่าเทียมทางสถิติ

กลไกตรงไปตรงมามาก: pq(html) สร้างต้นไม้ lxml ครั้งเดียว, d("h3.title") คอมไพล์ CSS selector ผ่าน cssselect เหมือน tree.cssselect(), และ element ที่ส่งกลับมาก็ยังเป็น lxml elements อยู่ดี ดังนั้นใน hot path ที่วัดนี้ PyQuery แทบไม่ได้ทำงานเพิ่มเลย ส่วนการ traverse, การปรับแต่ง, การ query ซ้ำ, เวลา import และ memory ยังไม่ได้ถูกรวมอยู่ในคำอ้างเรื่องเวลาของ selector นี้

ผลที่ใกล้กันตั้งแต่ 10 KB ขึ้นไป

สิ่งที่น่าสนใจกว่าคือคอลัมน์แรก

ตั้งแต่ 10 KB ขึ้นไป ช่วงต่างระหว่างตัวที่เร็วสุดกับช้าที่สุดใน selectolax, lxml และ PyQuery อยู่ที่ 4.5% ที่ 10 KB, 5.4% ที่ 100 KB, 0.5% ที่ 1 MB, และ 4.5% ที่ 10 MB การรันนี้ไม่ใช่การทดสอบ equivalence แต่ข้อสรุปเชิงปฏิบัติคือ ช่องว่างระดับนี้ไม่น่าจะเปลี่ยนการเลือก parser สำหรับงานลักษณะนี้ของคนส่วนใหญ่

selectolax เร็วจริงที่ 1 KB — 0.0286 ms เทียบกับ 0.0456 และ 0.0508 — แต่แถวนั้นยังใช้ตัดสินอันดับไม่ได้ เพราะในระดับไมโครวินาที ความผันผวนครอบงำผลลัพธ์ทั้งหมด ระหว่าง parser ทั้ง 3 ตัว ส่วนต่างในขนาดนั้นอยู่ที่ 77.6% และ 3 รันของ selectolax เองก็แกว่งระหว่าง 0.0267 ถึง 0.0404 ms ที่ 28 ไมโครวินาที ตัวจับเวลาและ scheduler มีอิทธิพลมากเกินไป จึงไม่จัดอันดับอะไรจากจุดนั้น

สำหรับ workload แบบเลือก selector แล้วอ่านข้อมูลนี้ ควรเลือกจาก API และข้อเท็จจริงเรื่อง dependency ที่วัดได้ มากกว่าลำดับความเร็วที่เดาเอาเอง PyQuery ไม่ได้มีโทษด้านประสิทธิภาพที่มีนัยต่อการตัดสินใจเมื่อเทียบกับ lxml ส่วน selectolax ใช้ parser stack คนละชุด แต่บทความนี้ไม่ได้วัดขนาดที่ติดตั้ง, wheel coverage หรือข้อกำหนดในการ build บนฐานเดียวกัน

เพื่อให้เห็นภาพเปรียบเทียบ benchmark ที่เผยแพร่ไว้ยังมีอีก 2 ตัวเลือก Python บน fixture ขนาด 10 MB เดียวกัน และตัวเลขเหล่านั้นต่างกันจริง ๆ:

ค่าที่เผยแพร่มาจาก bench_parse.json.

แถว benchmark ในอดีตชี้ว่า BeautifulSoup ช้ากว่าค่ามัธยฐานของ parser ที่เร็วกว่าใน fixture นี้มากกว่า 1 ลำดับขั้น แต่แถวดังกล่าวไม่ได้รันซ้ำร่วมกับ PyQuery/lxml ใน process ปัจจุบัน จึงควรใช้เป็นบริบทประกอบ ไม่ใช่ตัวคูณที่ควบคุมได้สำหรับข้อสรุปหลัก

แถวที่บันทึกไว้ของ cheerio คือ 2,927.89 ms (2927.8857 ใน parser-bench.json) และแฮชของเนื้อหาที่ดึงออกมาตรงกัน ผลข้าม runtime แบบนี้ยังขึ้นกับ Node, เวอร์ชันแพ็กเกจ และตัวควบคุมการรันในอดีต จึงไม่ควรตีความว่าเป็นตัวคูณความเร็วของไลบรารีเพียงอย่างเดียว

สภาพแวดล้อมการติดตั้ง

อ้างอิงทางการ: PyQuery on PyPI.

metadata-snapshot.json.

3 แพ็กเกจถือว่า dependency footprint เรียบร้อยดี และ 2 ใน 3 ตัว — lxml กับ cssselect — เป็นของที่โปรเจกต์ scraping Python จำนวนมากมีอยู่แล้ว ดังนั้นต้นทุนเพิ่มของ PyQuery จึงมีแค่ไม่กี่สิบกิโลไบต์

ส่วน 20.1 MiB นั้นคือ compiled extensions ของ lxml ไม่ใช่ PyQuery เอง และเป็น 20 MiB ชุดเดียวกับที่คุณต้องจ่ายอยู่แล้วถ้าใช้ lxml โดยตรง

แพ็กเกจนี้ใช้ไลเซนส์ BSD ใน snapshot ที่อ้างถึงมี 59 issue เปิดอยู่ และมีการ push ก่อนการทดสอบประมาณ 3 สัปดาห์ ข้อสังเกตพวกนี้อย่างเดียวไม่ได้ยืนยันคุณภาพการดูแลโค้ดหรือความเข้ากันได้ในอนาคต

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

มี 2 เรื่องที่รีวิวทุกชิ้นในชุดนี้บอกว่ายังไม่ได้ทดสอบ และตอนนี้วัดแล้ว

บริบทการ stress test ที่กว้างกว่านี้ดูได้ใน ten-library memory and malformed-HTML comparison.

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

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

PyQuery ใช้หน่วยความจำน้อยกว่า resiliparse เมื่อเจอกับเอกสารขนาดใหญ่ — 172.5 MiB เทียบกับ 225.1 — แม้จะมี import floor สูงกว่า tree ของ lxml ค่อนข้างกะทัดรัด และ 30.3 MiB ของ PyQuery ส่วนใหญ่เป็นค่าของ lxml ที่ถูกโหลดเข้ามามากกว่าสิ่งที่ PyQuery เองทำ

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

pyquery โยน error ใน 0 จาก 14 และคืนค่าว่างใน 1 กรณี โดยกู้ sentinel กลับมาได้ 10/22 ตัวในชุด fixture ที่พัง malformed-results.json. มี 1 fixture ที่ไม่นับในตัวเลขนี้: ตาม HTML5 ทุกอย่างหลัง <script> ที่ไม่ปิดยังถือเป็น script content ดังนั้นการหายไปในกรณีนั้นจึงถูกต้อง และสิ่งที่ถือว่าเบี่ยงเบนคือการกู้กลับมาได้ หากไม่มี sentinel results ของตัวเลือกอื่นวางเทียบข้าง ๆ ตัวเลข 10/22 จึงเป็นข้อสังเกตด้านความทนทาน ไม่ใช่อันดับการเลือก parser

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

ข้อดี ไวยากรณ์แบบ jQuery ซึ่งคุ้นมือสำหรับคนที่เคยเขียน JavaScript ฝั่ง front-end หรือใช้ cheerio มาก่อน ไม่พบโอเวอร์เฮดของ selector ที่มีผลต่อการตัดสินใจเมื่อเทียบกับ raw lxml ใน fixture นี้ มีเพียง 3 แพ็กเกจ และ 2 ตัวน่าจะอยู่ในโปรเจกต์ของคุณอยู่แล้ว ส่งกลับมาเป็น lxml elements ดังนั้นยังใช้เทคนิคของ lxml ได้ ไลเซนส์ BSD แฮชของเนื้อหาตรงกับ reference ครบทั้ง 5 ขนาด

ข้อเสีย ใช้พื้นที่ 20.1 MiB เพราะ lxml มี community ขนาดเล็กกว่า cheerio ที่มี 30,449 ดาวมาก — เวลามีอะไรแปลก ๆ ตัวอย่างที่ผ่านมือจะน้อยกว่า เป็นเพียงชั้นอำนวยความสะดวก ดังนั้นสิ่งที่ lxml ทำไม่ได้ PyQuery ก็ทำไม่ได้ และถ้าคุณหวังว่า API แบบ jQuery จะทำให้เร็วขึ้น มันไม่ใช่ — สิ่งที่ได้คือความสะดวก ส่วนงานจริงยังเป็น parser ข้างใต้ที่ทำงาน

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

ควรใช้ PyQuery เมื่อคุณหรือทีมชอบ selector สไตล์ jQuery ใน Python เส้นทางที่วัดไว้คือการสร้างอ็อบเจกต์, เลือกสองครั้ง และอ่านข้อมูล ซึ่งไม่พบโทษด้านประสิทธิภาพที่มีนัยเทียบกับ lxml ส่วนงานอื่น ๆ ของ PyQuery ไม่ได้ถูกจับเวลา

ควรใช้ lxml โดยตรง ถ้าคุณชอบ XPath หรืออยากลดจำนวนแพ็กเกจลงอีกหนึ่งตัว การรันครั้งนี้ไม่พบเหตุผลด้านความเร็วของ selector ที่ทำให้ต้องเลือกฝั่งใดฝั่งหนึ่ง

ควรพิจารณา selectolax ถ้า API ของ parser และ stack ของ dependency เหมาะกับโปรเจกต์คุณ แถว 1 KB ถูกระบุว่าไม่จัดอันดับ และบทความนี้ก็ไม่ได้สนับสนุนข้ออ้างเรื่อง “dependency เล็กที่สุด”

ในฝั่ง Node cheerio คือ API ที่มีแนวคิดใกล้เคียงกัน ผลที่บันทึกไว้ข้าม runtime ช้ากว่าในงานนี้ แต่ความต่างของ runtime และการรันในอดีตทำให้ยังสรุปแบบชี้เฉพาะตัวไลบรารีไม่ได้

บทบาทของ managed API อยู่ตรงไหน

PyQuery ใช้กับ HTML ที่คุณมีอยู่แล้ว มันไม่ดึงหน้าเว็บ ไม่เรนเดอร์ JavaScript และไม่จัดการ anti-bot layer — parser ในการเปรียบเทียบนี้ก็ทำไม่ได้เหมือนกัน และในเป้าหมายจริงจำนวนมาก ปัญหาครึ่งที่ยากกว่านั้นคือฝั่ง acquisition

หมายเหตุจากผู้เขียน: Thunderbit คือทางเลือกแบบ managed ของเราสำหรับการดึง/เรนเดอร์ URL และการ extract ข้อมูล ซึ่งไม่ได้ถูกนำมา benchmark เทียบกับ PyQuery ในบทความนี้ ประเด็นสำคัญคือคุณมี HTML อยู่แล้วและอยากใช้ selector แบบ local หรือคุณต้องการให้การดึงหน้าและ extraction ถูกจัดการเป็นบริการ

พูดตรง ๆ คือ ถ้าคุณถือ HTML อยู่ในมือและรู้ selector ของตัวเอง PyQuery ก็ฟรีและใช้งานสบาย แต่ถ้า selector เริ่มพังบ่อย หรือคุณต้องดึงข้อมูลในระดับสเกลใหญ่ นั่นเป็นการตัดสินใจอีกแบบหนึ่ง

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

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

ควรใช้ PyQuery ไหม?

ควร ถ้าคุณต้องการ syntax แบบ jQuery ใน Python และเส้นทางการเลือกข้อมูลกับการอ่านข้อมูลที่วัดไว้ตรงกับงานจริงของคุณ

benchmark พบว่าไม่มีโอเวอร์เฮดของ selector ที่มีผลต่อการตัดสินใจเมื่อเทียบกับ lxml และยังคง parity ของ content hash ไว้ได้ แต่ก็ไม่ได้พิสูจน์ว่าทั้งไลบรารีไม่มีต้นทุนเลย

เมื่อมองทั้ง 5 ขนาด ค่ามัธยฐานของ parser Python ทั้ง 3 ตัวอยู่ใกล้กันมากพอที่ความเหมาะสมของ API น่าจะเป็นตัวแปรหลักของงานนี้ ถ้าจะสรุปเป็น ranking parser ที่กว้างกว่านี้ ควรกำหนด equivalence margin แล้วรันทดสอบตัวเลือกเดิมแบบเดิมอีกครั้งก่อน

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

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

PyQuery ทำให้ lxml ช้าลงไหม? ในการรันนี้ไม่พบโอเวอร์เฮดของ selector ที่มีผลต่อการตัดสินใจ ทั้ง 5 ขนาดหน้า ค่ามัธยฐานอยู่ที่หรือดีกว่า lxml แบบตรง ๆ โดยทั้งคู่ใช้ lxml 6.1.1 ใน process เดียวกัน ที่ 10 MB ช่วงค่าค่อนข้างใกล้กันแต่ไม่ทับกัน: PyQuery 161.13–163.17 ms และ lxml 164.18–169.46 ms pq(html) สร้าง tree ของ lxml และ selector ที่ทดสอบคอมไพล์ผ่าน cssselect

selectolax เร็วกว่า PyQuery ไหม? ค่ามัธยฐานที่ 1 KB ต่ำกว่า แต่แถวนั้นไม่จัดอันดับ เพราะความแปรปรวนในระดับไมโครวินาทีครอบงำผลลัพธ์ ตั้งแต่ 10 KB ขึ้นไป ส่วนต่างของค่ามัธยฐานอยู่ที่ 0.5%–5.4% ซึ่งถือว่าใกล้กันสำหรับงานนี้ ไม่ใช่หลักฐานของความเท่าเทียมหรือช่วงค่าที่ทับซ้อนกันทุกกรณี

ทำไมต้องรัน lxml ใหม่ แทนที่จะอ้างตัวเลขที่เผยแพร่ไว้? เพราะ benchmark ที่เผยแพร่บันทึกเครื่องและเวอร์ชัน Python ไว้ แต่ไม่ได้บันทึกเวอร์ชันไลบรารี แถว lxml เดิมอาจมาจาก lxml คนละรุ่นกับที่ PyQuery ครอบอยู่ตอนนี้ และช่องว่างของเวอร์ชันอาจดูเหมือนเป็นภาษีจาก wrapper ทั้งที่จริงไม่มี การรันทั้งสองใน process เดียวกันด้วย lxml 6.1.1 ทำให้ความกำกวมหายไป

เทียบกับ cheerio เป็นอย่างไร? แนวคิด API คล้ายกัน แต่ระบบนิเวศต่างกัน selector สองแบบที่ทดสอบในนี้ใช้ได้ทั้งคู่ และแฮชของเนื้อหาตรงกันครบทั้ง 5 ขนาด แต่ไม่ได้พิสูจน์ว่ารองรับ selector เหมือนกันทั้งหมด เวลาใน cheerio ที่เก็บไว้ช้ากว่า แต่เพราะมีความต่างของ runtime และการควบคุมการรันในอดีต จึงยังไม่ควรสรุปเป็นตัวคูณของไลบรารีเพียงอย่างเดียว

อะไรที่ไม่ได้ทดสอบในบทความนี้? วัดหน่วยความจำในรูป peak RSS สำหรับกรณี import อย่างเดียว, เอกสาร 226 KB และเอกสาร 10 MB แล้ว ส่วน malformed HTML ทดสอบด้วยเอกสารที่เสีย 12 ชุดบวก control 2 ชุด สิ่งที่ยังไม่ทดสอบคือประสิทธิภาพด้านการ manipulate และ traversal ของ PyQuery, caching ของการ query ซ้ำ, การดึง URL, concurrency และ workload จริงจากเว็บไซต์ตัวอย่าง นอกจากนี้เวลา 1 KB ยังไม่ถูกจัดอันดับ