คำกล่าวอ้างเรื่องประสิทธิภาพส่วนใหญ่ในโลกของเครื่องมือ JavaScript นั้นมีอายุการใช้งานสั้นพอๆ กับนม ใครบางคนอาจจะติดตั้งแพ็กเกจไม่กี่ตัวในเช้าวันอังคารที่เงียบสงบ บันทึกผลลัพธ์จากเทอร์มินัล แล้วก็เผยแพร่กราฟแท่งที่ดูหวือหวาออกมา แต่พอถึงการทำงานรอบถัดไป (sprint) เครื่องมือตัวหนึ่งก็ดันปล่อยแพตช์ใหม่ที่ทำให้ข้อมูลทั้งหมดนั้นใช้ไม่ได้ขึ้นมา ทว่าโพสต์นั้นยังคงถูกดัชนีโดย Search Engine และกราฟนั้นก็ยังถูกแชร์ต่อไปเรื่อยๆ ทั้งที่ตัวเลขเหล่านั้นกำลังโกหกคุณอยู่

นี่คือความเน่าเฟะที่แพร่กระจายอยู่ในเกือบทุกการทดสอบประสิทธิภาพ (benchmark) ของ package manager มันเหมือนกับการถ่ายภาพเหตุการณ์ที่เกิดขึ้นแล้ว ทั้งที่สิ่งที่เราต้องการจริงๆ คือการถ่ายทอดสด

โปรเจกต์ที่ชื่อว่า depjs/canary มองปัญหานี้ว่าเป็นหน้าที่ของเครื่องจักร มากกว่าจะเป็นงานในปฏิทินคอนเทนต์ มันคือการทดสอบประสิทธิภาพที่มีชีวิต ซึ่งจะคอยเฝ้าดู npm, pnpm, Yarn และ dep จากนั้นจะรันชุดการทดสอบทั้งหมดใหม่ทันทีที่มีตัวใดตัวหนึ่งปล่อยเวอร์ชันใหม่ออกมา ผลลัพธ์ที่ได้จะเป็นสาธารณะ ต่อเนื่อง และหลีกเลี่ยงไม่ได้ เมื่อมีบางอย่างพัง สถานะใน repository จะยังคงเป็นสีแดงจนกว่าจะได้รับการแก้ไข ไม่มีการเลือกเฉพาะข้อมูลที่ต้องการ (cherry-picking) ไม่มีการหลบหลังบล็อกโพสต์เก่าๆ และไม่มีการทึกทักเอาเองว่าผู้ชนะเมื่อเดือนที่แล้วจะยังคงครองตำแหน่งอยู่

ทำไมคำกล่าวอ้างเรื่องความเร็วถึงต้องมีวันหมดอายุ

Package manager ของ JavaScript ไม่เคยหยุดนิ่ง ช่องว่างระหว่างเวอร์ชันย่อยอาจรวมถึงการเขียนอัลกอริทึมการหาความสัมพันธ์ (resolution algorithms) ใหม่, การเปลี่ยนกลยุทธ์การทำ hoisting หรือการเปลี่ยนวิธีจัดการคีย์ของ global cache การทดสอบที่บันทึกค่าของ npm 10.2.1 และ pnpm 8.11.0 แทบจะไม่ได้บอกอะไรคุณเลยเกี่ยวกับพฤติกรรมของเครื่องมือเดิมเหล่านั้นหลังจากผ่านไปอีกสองเวอร์ชัน แต่ถึงอย่างนั้น บนเว็บก็ยังเต็มไปด้วยคำกล่าวอ้างที่ดูเด็ดขาดอย่าง "เครื่องมือ X เร็วกว่าสามเท่า" โดยอ้างอิงจากภาพนิ่งที่ถูกแช่แข็งไว้แบบนั้น

ที่แย่กว่านั้นคือ การทดสอบหลายอย่างมักละเลยเงื่อนไขที่สร้างความลำบากให้แก่นักพัฒนาในโลกความเป็นจริง Package manager อาจจะติดตั้งได้อย่างรวดเร็วปานสายฟ้าในสภาพแวดล้อมที่พร้อมและมีการเตรียมการมาอย่างดี (warm cache) แต่กลับทำงานช้าเหมือนเต่าบน CI runner ที่เริ่มทำงานด้วยดิสก์ที่ว่างเปล่า หากไม่มีการทดสอบทั้งสองขั้วสุดโต่ง การทดสอบประสิทธิภาพนั้นก็จะกลายเป็นเพียงข่าวประชาสัมพันธ์ มากกว่าจะเป็นข้อมูลทางวิศวกรรมที่นำไปใช้งานได้จริง

วิธีที่ Canary ทำให้การเปรียบเทียบเป็นไปอย่างอัตโนมัติ

ทุกๆ สองชั่วโมง งานหนึ่งจะทำการตรวจสอบ (poll) npm registry หากพบเวอร์ชันใหม่ของ npm, pnpm, Yarn หรือ dep ตัว canary จะตื่นขึ้นมา มันไม่รอให้มนุษย์มาสังเกตเห็น changelog แต่มันจะเริ่มรัน test matrix แบบเต็มรูปแบบทันที โดยนำ manager ทั้งสี่ตัวมาประชันกันกับแพ็กเกจยอดนิยมในโลกความเป็นจริง 5 ตัว การคัดเลือกนี้รวมถึงตัวหลักๆ อย่าง React, Next.js และ Vite ซึ่งเป็น codebase ที่นักพัฒนาใช้งานจริงในทุกๆ วัน สิ่งเหล่านี้ไม่ใช่โปรเจกต์ขนาดเล็กที่สร้างขึ้นมาหลอกๆ เพื่อเอาใจเครื่องมือตัวใดตัวหนึ่ง

แนวทางที่ถูกกระตุ้นโดยการออกเวอร์ชันใหม่นี้มีความสำคัญ เพราะมันเชื่อมโยงการวัดผลเข้ากับการเปลี่ยนแปลงโดยตรง หากการทดสอบรันตามตารางเวลาประจำคืน มันอาจจะพลาดการแก้ไขด่วน (hotfix) ระหว่างวัน หรือปล่อยให้ปัญหาประสิทธิภาพถดถอย (regression) ลอยนวลอยู่หลายชั่วโมง การรันเฉพาะเมื่อมีเวอร์ชันใหม่ทำให้ canary ตั้งคำถามโดยตรงในทุกครั้งว่า: การปล่อยเวอร์ชันนี้ทำให้ทุกอย่างดีขึ้นหรือแย่ลง?

สี่สถานการณ์ที่ทดสอบความสามารถในด้านที่ต่างกัน

Test matrix ถูกสร้างขึ้นรอบๆ สี่การตั้งค่าที่แตกต่างกัน ซึ่งตรงกับเวิร์กโฟลว์ที่คุณคุ้นเคย

  • Cold cache, no lockfile: นี่คือการ clone โปรเจกต์ใหม่ลงบนแล็ปท็อปเครื่องใหม่ หรือการติดตั้งครั้งแรกหลังจากลบ node_modules ทิ้ง ไม่มีอะไรถูกแคชไว้ ไม่มีอะไรถูกล็อกไว้ Package manager ต้องทำการ resolve, fetch และเขียนข้อมูลทุกอย่างใหม่ตั้งแต่ต้น
  • Warm cache, with lockfile: นี่คือเส้นทางที่ราบรื่นสำหรับการทำ continuous integration เมื่อทุกอย่างเป็นไปตามแผน มี lockfile อยู่ในเครื่อง และแคชยังมีไฟล์ tarballs จากการรันครั้งก่อนอยู่ เครื่องมือควรจะทำงานได้รวดเร็วเพราะการตัดสินใจส่วนใหญ่ถูกทำไว้หมดแล้ว
  • Cold cache, with lockfile: ในกรณีนี้มี lockfile อยู่ แต่แคชถูกล้างไปแล้ว Manager สามารถข้ามขั้นตอนการหาความสัมพันธ์ (dependency resolution) ได้ แต่ยังคงต้องดาวน์โหลดทุกไบต์ผ่านเครือข่าย วิธีนี้ช่วยแยกความเร็วของเครือข่ายออกจากความเร็วในการหาความสัมพันธ์
  • Warm cache, no lockfile: แคชพร้อมใช้งาน แต่ไม่มี lockfile แล้ว Package manager ต้องทำการ re-resolve dependency tree ใหม่ก่อนที่จะเริ่มแตกไฟล์ได้ สิ่งนี้ทดสอบประสิทธิภาพของ solver และตัวแยกแยะข้อมูลเมทาดาตา (metadata parser) ภายใต้สภาวะเครือข่ายที่เหมาะสมที่สุด

แต่ละสถานการณ์จะถูกรันทั้งหมดห้าครั้ง และ canary จะเก็บเฉพาะค่ามัธยฐาน (median) ไว้ การเลือกวิธีนี้ช่วยกำจัดสัญญาณรบกวน (noise) ได้มหาศาล ปัญหาเครือข่ายชั่วคราวหรือความหน่วงของ registry ที่พุ่งสูงขึ้นเพียงชั่วขณะจะไม่สามารถบิดเบือนผลลัพธ์ได้ ค่าที่ผิดปกติ (outlier) จะถูกละเลย ส่วนประสบการณ์การใช้งานทั่วไปจะถูกบันทึกไว้

Smoke Tests ดีกว่าการใช้ตัวจับเวลาที่ว่างเปล่า

Raw speed is easy to fake if you do not verify the outcome. A package manager could skip postinstall steps, corrupt a few symlinks, or install the wrong versions and still post an impressive timestamp. The canary refuses to stop at the timer. After the installation finishes, it actually exercises the installed code.

For example, it boots up an Express application and confirms that the server starts listening on the expected port. If the code does not run, the benchmark fails outright. The smoke test transforms the suite from a race into an audit. It answers the question that speed alone cannot: does the installation actually work?

Radical Honesty as a Feature

The author of the canary wrote three rules into the process that most benchmark authors treat as optional.

Same playing field. Flags are used to normalize behavior across tools. If one package manager hides a performance flaw behind a default setting, the benchmark exposes it rather than letting the tool look good by accident.

Genuine cold starts. Before every single repetition, not just the first one, the npm cache and the pnpm store get wiped. That word "every" is doing heavy labor. Many benchmarks clear the cache once, then run five installs in a row. The second through fifth runs are not truly cold, and the numbers inflate accordingly. The canary starts from zero each time.

Public failure states. When a new release breaks something, the repository remains in a red failure state. It sits there on the front page, ugly and unresolved, until a fix ships. There is no silent suppression to keep the dashboard looking green. This policy forces visibility. A user evaluating tools can see not just which one is fastest, but which one stayed reliable over time.

Inspectability Is Non-Negotiable

A benchmark that you cannot reproduce is a campaign slogan. The canary addresses this with a single bash script that lets anyone run any slice of the suite locally. You do not need to trust a cloud provider’s networking or a maintainer’s hand-tweaked environment. If you suspect the numbers are off, you can generate your own.

That transparency also makes the project useful for maintainers. When a regression hits, a downstream developer can pull the script, bisect the tool’s releases, and hand the upstream team a