ตัวสร้างเว็บไซต์แบบสแตติก (SSG): การวิเคราะห์เชิงลึกเชิงกลยุทธ์ระดับองค์กรและแผนงานสถาปัตยกรรม

TL;DR. เจาะลึกตัวสร้างเว็บไซต์แบบสแตติกที่เขียนด้วย Rust: ความปลอดภัยระดับคอมไพล์ไทม์ รั้วกันชน WCAG และ AI แบบโลคัลเฟิร์สต์ ช่องว่างใน v0.0.41 และแผนงานระดับองค์กรสู่ 1.0

ประเด็นสำคัญ

จุดแข็งในปัจจุบัน. โค้ดเบสของ static-site-generator แสดงให้เห็นการตัดสินใจทางวิศวกรรมที่โดดเด่นหลายประการซึ่งแยกมันออกจากเอนจินรุ่นเก่าที่เขียนด้วย JavaScript และ Go:.
ช่องว่างและความเป็นจริงในโลกจริง. แม้จะมีจุดแข็งอันโดดเด่นเหล่านี้ การตรวจสอบโค้ดเบสของ v0.0.41 อย่างเข้มงวดเผยให้เห็นช่องว่างหลายประการทั้งด้านสถาปัตยกรรม การใช้งาน และประสบการณ์นักพัฒนา ระหว่างสิ่งที่เอกสารกล่าวอ้างกับโค้ด Rust ที่มีอยู่จริง:.
ช่องว่างด้านสถาปัตยกรรมที่เรายังขาด (การค้นพบใหม่). นอกเหนือจากช่องว่างใน v0.0.41 การประเมินโครงการเทียบกับโปรไฟล์ความเสี่ยงระดับสถาบันการเงินยังเผยให้เห็นความสามารถหลายประการที่มันยังไม่มี แต่ผู้ซื้อระดับองค์กรจะต้องการ:.
แผนงานเชิงกลยุทธ์สู่ 1.0. แผนงานต่อไปนี้ผสานทั้งช่องว่างที่ได้รับการแก้ไขและความสามารถระดับองค์กรที่ค้นพบใหม่ เข้าไว้ในกรอบการปล่อยเวอร์ชันแบบมีโครงสร้างตามลำดับเวลา.

วันที่วิจัย: 2026-06-22 อ้างอิงจากการตรวจสอบซอร์สโค้ดของ static-site-generator ที่เวอร์ชัน v0.0.41 และการค้นคว้าบนเว็บเกี่ยวกับภูมิทัศน์ SSG ปี 2026

สำหรับผู้เผยแพร่ที่อยู่ภายใต้การกำกับดูแล ตัวสร้างเว็บไซต์แบบสแตติกไม่ใช่เพียงเครื่องมือออกแบบอีกต่อไป แต่เป็นส่วนหนึ่งของขอบเขตความเสี่ยงเชิงปฏิบัติการ โครงการโอเพนซอร์สที่เขียนด้วย Rust อย่าง static-site-generator สร้างขึ้นบนแนวคิดดังกล่าว โดยย้ายความปลอดภัย การเข้าถึงได้ การรองรับหลายภาษา และไปป์ไลน์เนื้อหา AI ไปไว้ที่ขั้นคอมไพล์ เพื่อให้การตรวจสอบที่ล้มเหลวหยุดการบิลด์แทนที่จะหลุดไปถึงโปรดักชัน บทวิเคราะห์นี้แยกแยะสิ่งที่เวอร์ชัน 0.0.41 ส่งมอบได้จริงออกจากสิ่งที่เอกสารยังคงเพียงสัญญาไว้ ระบุห้าความสามารถระดับองค์กรที่ยังไม่มี และเสนอเส้นทางแบบเป็นเฟสสู่การปล่อยเวอร์ชัน 1.0 ที่สอดคล้องกับ DORA พระราชบัญญัติการเข้าถึงได้ของยุโรป และมาตรฐานห่วงโซ่อุปทานสมัยใหม่

บทสรุปสำหรับผู้บริหาร

การเผยแพร่เป็นขอบเขตความเสี่ยงเชิงปฏิบัติการแล้วในปัจจุบัน ภายใต้ DORA พระราชบัญญัติการเข้าถึงได้ของยุโรป และ GDPR ทุกสินทรัพย์ที่เผยแพร่สู่สาธารณะเป็นจุดเข้าที่อาจนำไปสู่การประนีประนอมห่วงโซ่อุปทาน การถูกทำลายหน้าเว็บ และความเสี่ยงด้านการกำกับดูแล โมเดลระดับคอมไพล์ไทม์ทำให้ขอบเขตนั้นแคบลงด้วยการปฏิเสธเอาต์พุตที่ไม่เป็นไปตามข้อกำหนดก่อนที่จะปล่อยออกไป

จุดต่างของเอนจินถูกบังคับโดยคอมไพเลอร์ ไม่ใช่ความมุ่งหวังในเอกสาร forbid(unsafe_code) ทั่วทั้งเวิร์กสเปซ, SHA-256/384 SRI ที่แท้จริง, การสกัด CSP อัตโนมัติ และรั้วกันชน WCAG 2.2 AA ระดับบิลด์ไทม์ เปลี่ยนความปลอดภัยและการเข้าถึงได้จากการตรวจสอบภายหลังให้กลายเป็นการบิลด์ที่ล้มเหลวอย่างเด็ดขาด

เวอร์ชัน 0.0.41 มีช่องว่างระหว่างเอกสารกับโค้ด การมินิฟายเนทีฟ การรีบิลด์แบบเพิ่มหน่วยผ่านกราฟการพึ่งพา และการรองรับ AVIF ถูกอธิบายไว้แต่ยังใช้งานไม่ได้ บทความนี้ระบุแต่ละช่องว่างเทียบกับตำแหน่งในซอร์สโค้ดที่แม่นยำ

เส้นทางสู่ 1.0 เป็นลำดับ ไม่ใช่รายการความปรารถนา ความแข็งแกร่งมาก่อน (0.0.42), จากนั้นความถูกต้องแบบเพิ่มหน่วย (0.1.0), จากนั้นความสามารถระดับองค์กรอย่างแซนด์บ็อกซ์ WASM การค้นหาเชิงความหมายแบบโลคัล และหลักฐานที่มา SLSA ที่ตรวจสอบยืนยันได้ ซึ่งผู้ซื้อภายใต้การกำกับดูแลต้องการ (1.0.0)

จุดแข็งในปัจจุบัน #

โค้ดเบสของ static-site-generator แสดงให้เห็นการตัดสินใจทางวิศวกรรมที่โดดเด่นหลายประการซึ่งแยกมันออกจากเอนจินรุ่นเก่าที่เขียนด้วย JavaScript และ Go:

ท่าทีด้านความปลอดภัยระดับคอมไพล์ไทม์: #![forbid(unsafe_code)] ทั่วทั้งเวิร์กสเปซให้การรับประกันความปลอดภัยของหน่วยความจำระดับคอมไพล์ไทม์ ไปป์ไลน์การบิลด์สร้างแฮช Subresource Integrity (SRI) แบบ SHA-256/SHA-384 ที่แท้จริง (src/plugins/assets.rs) และดำเนินการสกัด Content Security Policy (CSP) อัตโนมัติที่ลบสคริปต์และสไตล์ unsafe-inline ออก การปล่อยเวอร์ชันถูกลงลายเซ็น มาพร้อมการรับรอง Sigstore และสร้าง CycloneDX 1.5 SBOM ในทุกการบิลด์
รั้วกันชนการเข้าถึงได้ที่บังคับโดยคอมไพเลอร์: การตรวจสอบตามแนวทางการเข้าถึงเนื้อหาเว็บ (WCAG) 2.2 ระดับ AA ทำงานภายในไปป์ไลน์การคอมไพล์ผ่านตัวแยกวิเคราะห์ axe-core ระดับบิลด์ไทม์ที่ขับเคลื่อนด้วย Playwright การเข้าถึงได้จึงกลายเป็นรั้วกันชนการบิลด์อย่างเด็ดขาดแทนการตรวจสอบหลังเผยแพร่: หากหน้าใดล้มเหลว การคอมไพล์จะหยุดพร้อมข้อผิดพลาดที่ระบุหมายเลขบรรทัดอย่างแม่นยำ
ไปป์ไลน์ AI ที่อธิปไตยด้านข้อมูล: ไปป์ไลน์แปลภาษาและสกัดเมทาดาทาด้วย LLM แบบโลคัล (ผ่านเอนด์พอยต์ Ollama หรือ llama.cpp แบบโลคัล) ช่วยให้องค์กรทำการสรุปเนื้อหา สร้างสคีมา JSON-LD และแปลหลายภาษาโดยอัตโนมัติ โดยไม่ต้องส่งข้อมูลก่อนประกาศผลประกอบการหรือทรัพย์สินทางปัญญาที่ละเอียดอ่อนไปยัง API AI บนคลาวด์สาธารณะ
การคอมไพล์แบบขนาน: การรับประกันความปลอดภัยของหน่วยความจำของ Rust รองรับไปป์ไลน์ HTML และสินทรัพย์แบบขนานที่ขับเคลื่อนด้วย Rayon (src/core/pipeline.rs) ไปป์ไลน์ปลั๊กอินรันการแปลงที่หลอมรวมกัน โดย SearchPlugin, SeoPlugin, CanonicalPlugin และ JsonLdPlugin ทำงานบน par_iter() ดังนั้นแต่ละหน้าจึงถูกอ่านและเขียนลงดิสก์เพียงครั้งเดียว
สุขอนามัยของห่วงโซ่อุปทานและการพึ่งพา: การย้ายเอนจินเทมเพลตจาก Tera ไปยัง MiniJinja (v0.0.37) ลดขนาดไบนารี ลบการพึ่งพาแบบส่งผ่านอย่าง rand ออกในขั้นคอมไพล์ และสร้างรอยเท้าการพึ่งพาที่กะทัดรัดซึ่งลดการเปิดรับความเสี่ยงในห่วงโซ่อุปทานซอฟต์แวร์

ช่องว่างและความเป็นจริงในโลกจริง #

แม้จะมีจุดแข็งอันโดดเด่นเหล่านี้ การตรวจสอบโค้ดเบสของ v0.0.41 อย่างเข้มงวดเผยให้เห็นช่องว่างหลายประการทั้งด้านสถาปัตยกรรม การใช้งาน และประสบการณ์นักพัฒนา ระหว่างสิ่งที่เอกสารกล่าวอ้างกับโค้ด Rust ที่มีอยู่จริง:

ช่องว่างด้านสถาปัตยกรรม #

การยุบช่องว่างเทียบกับการมินิฟายเนทีฟ: แม้ README จะสัญญาว่ามี "การมินิฟาย JS/CSS เนทีฟ" แต่ MinifyPlugin (src/plugins/plugins.rs:96-116) ทำหน้าที่เป็นเพียงตัวยุบช่องว่างอย่างหยาบ มันลัดวงจรที่องค์ประกอบ <pre> และยุบช่วงช่องว่างใน HTML แต่ไม่ได้ทำการมินิฟาย CSS หรือ JS เนทีฟที่เข้าใจไวยากรณ์ ยิ่งไปกว่านั้น มันประมวลผลเฉพาะหน้าระดับบนสุดและไม่เดินสำรวจไดเรกทอรีย่อยแบบเรียกซ้ำ (เช่น /blog/ หรือ /tags/) ทำให้หน้าลึกไม่ถูกมินิฟาย
โครงสร้างพื้นฐานแบบเพิ่มหน่วยที่ตายแล้ว: กราฟติดตามการพึ่งพา (DepGraph ใน src/core/depgraph.rs) ถูกคอมไพล์และโหลดเข้าสู่ PluginContext.dep_graph แต่ไม่เคยถูกเติมข้อมูลจริงในโค้ดโปรดักชัน เมธอด add_dep() ถูกเรียกเฉพาะในยูนิตเทสต์เท่านั้น ทำให้คำกล่าวอ้างของ README เรื่อง "การรีบิลด์แบบเพิ่มหน่วยผ่านกราฟการพึ่งพา" ยังคงเป็นเพียงความมุ่งหวังในขณะนี้
การคอมไพล์แบบเป็นชุดเทียบกับการคอมไพล์แบบสตรีมมิง: โมดูล streaming::compile_batch (src/core/streaming.rs) ไม่ได้สตรีมอย่างแท้จริง แต่กลับคอมไพล์หน้าเป็นชุดๆ ไปยังไดเรกทอรีชั่วคราว รัน staticdatagen::compile ตั้งแต่ต้นสำหรับแต่ละชุด และผสานเอาต์พุตเข้าด้วยกัน ส่งผลให้เกิดภาระการอ่านเขียนดิสก์อย่างมีนัยสำคัญและการแยกวิเคราะห์ซ้ำซ้อน อันเบี่ยงเบนจากสถาปัตยกรรมสตรีมมิงที่แท้จริง
การละเมิดเฟสวงจรชีวิตของปลั๊กอิน: ปลั๊กอินที่สร้างหน้า HTML ใหม่ระหว่างกระบวนการบิลด์ เช่น TaxonomyPlugin, PaginationPlugin และ I18nPlugin เขียนลงดิสก์โดยตรงใน after_compile แทนที่จะใช้วงจรชีวิต transform_html ด้วยเหตุนี้ หน้าที่สร้างโดยปลั๊กอินเหล่านี้จึงข้ามปลั๊กอินประมวลผลภายหลังที่สำคัญ (เช่น CanonicalPlugin, JsonLdPlugin, RobotsPlugin และ AccessibilityPlugin) หากปลั๊กอินเหล่านั้นถูกลงทะเบียนไว้ก่อนหน้า ทำให้หน้าแท็ก หน้าหมวดหมู่ และหน้าที่แบ่งหน้าไม่มีลิงก์ canonical ที่ถูกต้อง สคีมา JSON-LD หรือการตรวจสอบการเข้าถึงได้
การเรียก curl ผ่านเชลล์ใน LlmPlugin: ไปป์ไลน์เนื้อหา LLM แบบโลคัล (src/plugins/llm.rs) เรียกไบนารี curl ของโฮสต์ผ่านเชลล์โดยตรงเพื่อสอบถามเอนด์พอยต์ท้องถิ่น สิ่งนี้ก่อให้เกิดบั๊กข้ามแพลตฟอร์มที่ร้ายแรง (เช่น บนโฮสต์ Windows ที่ไม่มี curl ใน PATH) เป็นความเสี่ยงด้านความปลอดภัย (ช่องทางการฉีดคำสั่งเชลล์) และล้มเหลวในสภาพแวดล้อม CI ที่ถูกล็อกดาวน์หรือแยกเครือข่าย
การจัดการสตริงอย่างหยาบในการเขียน HTML ใหม่: ตัวสกัด image_plugin.rs และ search.rs เขียนสตริง HTML ใหม่โดยใช้การดำเนินการ str::find และ str::rfind ที่เปราะบาง วิธีนี้มีความเสี่ยงสูงต่อแท็ก HTML ที่เสียหาย แท็ก <img> ภายในคอมเมนต์ เอนทิตีอักขระในข้อความ alt หรือคุณสมบัติ srcset ที่มีอยู่ก่อน ซึ่งอาจส่งผลให้เอาต์พุตเสียหาย
การรองรับ AVIF ที่ยังไม่ถูกนำไปใช้: แม้การเข้ารหัสภาพ AVIF จะมีเอกสารระบุอย่างละเอียด แต่การนำไปใช้ใน image_plugin.rs เป็นสตับที่ avif_variants เพียงคืนค่า Vec::new() ทำให้ฟีเจอร์นี้ใช้งานไม่ได้
ตัวเฝ้าดูแบบพอลลิง: ตัวเฝ้าดูของเซิร์ฟเวอร์พัฒนาแบบโลคัล (src/server/watch.rs) ใช้การพอลลิงแทน API เหตุการณ์ของระบบไฟล์ นำไปสู่การใช้ CPU ขณะว่างที่มากเกินไปและความหน่วงในการตรวจจับการแก้ไขในระดับต่ำกว่าวินาที

ช่องว่างด้านการใช้งานและประสบการณ์นักพัฒนา #

ไม่มีการติดตามการพึ่งพาแบบส่งผ่าน: กราฟการพึ่งพาไม่สามารถติดตามการพึ่งพาที่ซ้อนกัน (เช่น การเปลี่ยนแปลงเทมเพลตย่อยที่ส่งผลต่อเลย์เอาต์ที่ส่งผลต่อหน้า) ตามที่ยืนยันโดยยูนิตเทสต์ transitive_not_tracked
ไม่มีแฟล็ก CLI สำหรับการคอมไพล์แบบเพิ่มหน่วย: ไม่มีแฟล็ก CLI --incremental ที่เชื่อมต่อกับคอมไพเลอร์ในการทำงาน ทำให้นักพัฒนาไม่สามารถใช้การบิลด์ที่แคชไว้ได้
HMR จำกัดอยู่ที่ CSS: Hot Module Replacement (HMR) รองรับเฉพาะ CSS การแก้ไขไฟล์ HTML เลย์เอาต์ หรือมาร์กดาวน์ใดๆ จะทำให้เกิดการโหลดหน้าใหม่ทั้งหน้า ซึ่งบั่นทอนความเร็วของนักพัฒนา
การขาดคำสั่งย่อย: นักพัฒนาต้องส่งแฟล็กแบบละเอียดด้วยตนเอง (ssg -s public -w) เพราะคำสั่งย่อยมาตรฐานอย่าง ssg dev, ssg build, ssg check และ ssg lint ยังไม่มีอยู่

ช่องว่างด้านสถาปัตยกรรมที่เรายังขาด (การค้นพบใหม่) #

นอกเหนือจากช่องว่างใน v0.0.41 การประเมินโครงการเทียบกับโปรไฟล์ความเสี่ยงระดับสถาบันการเงินยังเผยให้เห็นความสามารถหลายประการที่มันยังไม่มี แต่ผู้ซื้อระดับองค์กรจะต้องการ:

1. การแซนด์บ็อกซ์ปลั๊กอิน WebAssembly (ส่วนขยายแบบซีโร่ทรัสต์) #

แม้ตัวไบนารีของคอมไพเลอร์เองจะเขียนด้วย Rust ที่ปลอดภัย แต่การอนุญาตให้ปลั๊กอินของบุคคลที่สามตามอำเภอใจรันแบบเนทีฟบนระบบโฮสต์ก่อให้เกิดช่องโหว่ห่วงโซ่อุปทานที่ร้ายแรง ปลั๊กอินของบุคคลที่สามที่ถูกประนีประนอมสามารถเข้าถึงระบบไฟล์ของโฮสต์ อ่านไฟล์ Markdown ที่เป็นกรรมสิทธิ์ หรือลักลอบส่งข้อมูลรับรองส่วนตัวออกไปได้อย่างง่ายดาย

ความสามารถที่ขาด: สภาพแวดล้อมการรันแบบแซนด์บ็อกซ์ เพื่อให้บรรลุการคอมไพล์แบบซีโร่ทรัสต์ คอมไพเลอร์ควรรันปลั๊กอินของบุคคลที่สามภายในรันไทม์ WebAssembly แบบฝังตัว (เช่น wasmtime) ปลั๊กอินควรโต้ตอบกับโฮสต์ผ่าน WebAssembly System Interface (WASI) ที่จำกัดเท่านั้น โดยจำกัดการเข้าถึงไว้เฉพาะหน้าที่กำลังถูกแปลงอย่างเคร่งครัด

2. การแยกวิเคราะห์ HTML แบบซีโร่คอปีผ่าน Streaming AST (`lol_html`) #

การย้ายชั้นการแยกวิเคราะห์ HTML ไปยังไลบรารี DOM ในหน่วยความจำแบบเต็ม (เช่น Kuchiki หรือ html5ever) ก่อให้เกิดภาระหน่วยความจำอย่างมีนัยสำคัญและการหยุดชะงักในการประมวลผลเมื่อจัดการไซต์ที่มีมากกว่า 100,000 หน้า

ความสามารถที่ขาด: ตัวเขียน HTML ใหม่แบบสตรีมมิงชนิดซีโร่คอปี การใช้ lol_html ของ Cloudflare (ตัวเขียน HTML ใหม่แบบ Low-Output-Latency) ช่วยให้คอมไพเลอร์แยกวิเคราะห์ ตรวจสอบ และแก้ไของค์ประกอบ HTML ในการสตรีมผ่านเพียงรอบเดียวด้วยการจัดสรรหน่วยความจำที่เกือบเป็นศูนย์ สอดคล้องกับเป้าหมายการบิลด์ในระดับต่ำกว่าวินาทีของคอมไพเลอร์สตรีมมิงแบบขนาน

3. การค้นหาเวกเตอร์เชิงความหมายแบบโลคัล (Local RAG) #

ดัชนีการค้นหาปัจจุบัน (SearchPlugin) สร้างดัชนี JSON แบบแบนราบขนาดใหญ่ที่ทำการจับคู่สตริงฝั่งไคลเอนต์อย่างง่าย ขาดการรองรับการค้นหาแบบคลุมเครือ การหารากศัพท์ หรือการสืบค้นเชิงความหมาย Pagefind เป็นการปรับปรุง แต่ก็ยังต้องอาศัยการดาวน์โหลดดัชนีขนาดใหญ่

ความสามารถที่ขาด: การค้นหาเชิงความหมายแบบฝังตัว คอมไพเลอร์ควรใช้ประโยชน์จากโมเดลฝังเวกเตอร์แบบโลคัลที่เขียนด้วย Rust ที่มีน้ำหนักเบา (เช่นโมเดล MiniLM-L6 ที่รันผ่าน candle หรือ ort / ONNX Runtime) ในขั้นบิลด์ไทม์ มันควรสร้างการฝังเวกเตอร์แบบหนาแน่นสำหรับทุกย่อหน้าของหน้าและส่งออกดัชนีเวกเตอร์ที่กะทัดรัด จากนั้นวิดเจ็ตการค้นหาฝั่งไคลเอนต์ที่คอมไพล์เป็น WASM จะสามารถทำการค้นหาเชิงความหมายแบบออฟไลน์ที่แท้จริงได้โดยตรงในเบราว์เซอร์

4. การแคชการแปลและการอนุมานแบบกำหนดผลได้แน่นอน #

เนื่องจากการอนุมาน LLM แบบโลคัล (เช่น ผ่าน Ollama หรือ Llama.cpp) ใช้ CPU/GPU อย่างเข้มข้น การแปลหรือสร้างเมทาดาทาสำหรับหน้าหลายพันหน้าในทุกการบิลด์จึงเป็นภาระด้านการคำนวณที่เกินจะรับได้

ความสามารถที่ขาด: การแคชการอนุมานที่อิงกับแฮชเนื้อหา คอมไพเลอร์ต้องรักษาแคชแบบกำหนดผลได้แน่นอนของการดำเนินการ LLM ทั้งหมด หากแฮช SHA-256 ของเนื้อหาไฟล์มาร์กดาวน์และพารามิเตอร์การแปลตรงกับรายการในแคช คอมไพเลอร์ควรนำการแปลและเมทาดาทาที่แคชไว้กลับมาใช้ใหม่ โดยข้ามการอนุมานแบบโลคัลที่ซ้ำซ้อน

5. การอ่านเขียนไฟล์แบบอะซิงโครนัสเพื่อการปรับขยายแบบขนาน #

แม้ไปป์ไลน์ปลั๊กอินจะถูกทำให้ขนานผ่าน Rayon แต่การเขียนดิสก์แบบซิงโครนัสมาตรฐานจะบล็อกเธรด OS ของ Rayon สร้างคอขวดด้านการอ่านเขียนเมื่อเขียนหน้าหลายหมื่นหน้า

ความสามารถที่ขาด: การอ่านเขียนดิสก์แบบอะซิงโครนัสที่ไม่บล็อก คอมไพเลอร์ควรแยกงานที่ใช้ CPU เข้มข้น (การแยกวิเคราะห์ Markdown, การมินิฟาย) ออกจากการเขียนที่ผูกกับดิสก์ โดยใช้กลุ่มเธรดการอ่านเขียนแบบอะซิงโครนัสหรือการเชื่อมโยง io_uring ของ Linux (ผ่าน rio หรือ tokio) เพื่อเขียนหน้าที่คอมไพล์แล้วแบบขนานโดยไม่บล็อกตัวรันงาน CPU แบบขนาน

แผนงานเชิงกลยุทธ์สู่ 1.0 #

แผนงานต่อไปนี้ผสานทั้งช่องว่างที่ได้รับการแก้ไขและความสามารถระดับองค์กรที่ค้นพบใหม่ เข้าไว้ในกรอบการปล่อยเวอร์ชันแบบมีโครงสร้างตามลำดับเวลา

เฟส 1: 0.0.42 (แพตช์ความแข็งแกร่งและความถูกต้อง, 1 ถึง 2 สัปดาห์) #

สร้าง MinifyPlugin ขึ้นใหม่: ผสาน minify-html, oxc_minifier และ lightningcss เพื่อการมินิฟาย HTML, JS และ CSS เนทีฟที่เข้าใจไวยากรณ์ ตรวจสอบให้แน่ใจว่าปลั๊กอินเดินสำรวจไดเรกทอรีย่อยที่ซ้อนกันทั้งหมดภายใต้ site_dir แบบเรียกซ้ำ
ทำให้ไปป์ไลน์ AI ปลอดภัย: ย้าย LlmPlugin จากการเรียก curl ผ่านเชลล์เนทีฟไปยัง ureq (ไคลเอนต์ HTTP ที่เขียนด้วย Rust ที่มีน้ำหนักเบา ซิงโครนัส และปลอดภัย) เพื่อรับประกันความเข้ากันได้ข้ามแพลตฟอร์มและกำจัดช่องโหว่การฉีดคำสั่งเชลล์
ทำการนำ AVIF ไปใช้ให้สมบูรณ์: ต่อ ravif เข้ากับไปป์ไลน์สินทรัพย์ภาพโดยตรง เปิดใช้การเข้ารหัส AVIF ประสิทธิภาพสูงควบคู่กับ WebP และ PNG
ทำการแมป HrefLang และหลายโลแคลโดยอัตโนมัติ: ตรวจจับหน้าที่แปลคู่ขนานในการบิลด์หลายภาษาโดยอัตโนมัติ และฉีดแท็ก <link rel="alternate" hreflang="..." /> ที่เป็นไปตามมาตรฐานของ Google เข้าไปในส่วนหัวของแต่ละไฟล์ HTML ที่คอมไพล์แล้ว
การรองรับ JSON Feed 1.1: ส่งมอบตัวส่ง JSON Feed 1.1 โดยเฉพาะควบคู่กับช่องทางเผยแพร่มาตรฐาน RSS 2.0 และ Atom 1.0

เฟส 2: 0.1.0 (เวอร์ชันย่อยด้านความน่าเชื่อถือและการเพิ่มหน่วย, 2 ถึง 3 เดือน) #

เติมข้อมูล DepGraph และเปิดใช้ --incremental: เชื่อมต่อ DepGraph อย่างสมบูรณ์เพื่อติดตามการพึ่งพาแบบเทมเพลตต่อหน้าและมาร์กดาวน์ต่อหน้า นำชั้นการทำให้แคชเป็นโมฆะไปใช้และเชื่อมต่อแฟล็ก CLI --incremental โดยตั้งเป้าการรีบิลด์ในระดับต่ำกว่า 200 มิลลิวินาทีสำหรับสภาพแวดล้อมที่แคชอุ่น
การเขียน AST แบบสตรีมมิงใหม่ผ่าน lol_html: แทนที่การเขียนสตริงที่เปราะบางใน image_plugin.rs, search.rs และการฉีด CSP ด้วยตัวเขียน HTML ใหม่แบบสตรีมมิงชนิดซีโร่คอปีที่ขับเคลื่อนด้วย lol_html
ตัวเฝ้าดูแบบขับเคลื่อนด้วยเหตุการณ์และ HMR ระดับคอมโพเนนต์: ย้ายโมดูลเฝ้าดูจากการพอลลิงไปยังเครต notify ที่ขับเคลื่อนด้วยเหตุการณ์ และนำการรีโหลดแบบร้อนเฉพาะ CSS และ HTML บางส่วนไปใช้เพื่อการอัปเดตเบราว์เซอร์ในระดับต่ำกว่า 100 มิลลิวินาที
CLI คำสั่งแบบรวมศูนย์: ปรับสถาปัตยกรรมอินเทอร์เฟซคอมไพเลอร์ใหม่เพื่อรองรับคำสั่งย่อยมาตรฐาน: ssg dev, ssg build, ssg check (การตรวจสอบการเข้าถึงได้/SEO) และ ssg deploy
แคชการอนุมานแบบกำหนดผลได้แน่นอน: นำชั้นการแคชที่อิงกับแฮชเนื้อหาไปใช้กับงานแปล สรุป และสกัดเมทาดาทาด้วย LLM แบบโลคัลทั้งหมด

เฟส 3: 1.0.0 (เวอร์ชันหลักระดับองค์กรและโปรดักชัน, 6 ถึง 12 เดือน) #

การแซนด์บ็อกซ์ปลั๊กอิน WASM แบบซีโร่ทรัสต์: ฝังรันไทม์ WebAssembly (wasmtime หรือ wasmer) เพื่อรันปลั๊กอินของบุคคลที่สามในสภาพแวดล้อมแบบแซนด์บ็อกซ์อย่างสมบูรณ์ พร้อมการเข้าถึงระบบไฟล์และเครือข่ายแบบอิงตามความสามารถ
การค้นหาเวกเตอร์เชิงความหมายแบบโลคัล (Local RAG): ฝังโมเดลฝังที่เขียนด้วย Rust แบบโลคัล (ผ่าน candle หรือ ort) เพื่อคอมไพล์การฝังย่อหน้าแบบหนาแน่นเป็นดัชนีที่กะทัดรัด เปิดใช้การค้นหาเชิงความหมายฝั่งไคลเอนต์แบบส่วนตัว
Server Islands และเป้าหมาย WASM Edge: นำการรันคอมโพเนนต์ <ssg-island> ไปใช้บนรันไทม์เอดจ์ (เช่น Cloudflare Workers, Vercel Edge หรือ Netlify Edge) ที่สร้างบนแกน ssg-wasm ที่คอมไพล์แล้ว
เอนจินการอ่านเขียนแบบขนานอะซิงโครนัส: ปรับสถาปัตยกรรมโมดูลการเขียนระบบไฟล์ใหม่ให้ใช้กลุ่มเธรดการอ่านเขียนแบบอะซิงโครนัสและการเชื่อมโยง io_uring กำจัดการบล็อกตัวทำงาน CPU ระหว่างการเขียนแบบขนาน
หลักฐานที่มาการบิลด์ SLSA v1.1 และการปฏิบัติตาม SPDX 3.0: จัดหาหลักฐานที่มาการบิลด์ SLSA ระดับ 3 ที่ตรวจสอบยืนยันได้ทางคณิตศาสตร์ และสร้าง SBOM ที่เป็นไปตาม SPDX 3.0 ตอบสนองมาตรฐานความปลอดภัยห่วงโซ่อุปทานซอฟต์แวร์สมัยใหม่อย่างครบถ้วน

เมทริกซ์เปรียบเทียบคู่แข่ง (ภูมิทัศน์ปี 2026) #

เมทริกซ์ต่อไปนี้เปรียบเทียบ static-site-generator (เป้าหมาย v1.0) กับเอนจินการเผยแพร่เว็บชั้นนำของปี 2026:

ความสามารถ	static-site-generator v1.0	Hugo v0.155+	Zola v0.19+	Astro 5	Eleventy 3
ภาษา / รันไทม์	Rust (Zero Unsafe)	Go	Rust	JS (Node/V8)	JS (Node/V8)
รั้วกันชนการบิลด์ A11y	Build-Time AST Validation	None	None	Post-build Linter	Post-build Linter
การเสริมความแข็งแกร่งด้านความปลอดภัย	SHA-384 SRI & CSP Injection	Manual	Manual	Manual	Manual
ความปลอดภัยห่วงโซ่อุปทาน	SLSA L3 + SPDX 3.0 + WASM Sandbox	Minimal	Minimal	Heavy NPM Tree	Heavy NPM Tree
ไปป์ไลน์เนื้อหา AI	Private, Local-First (Local LLM)	None	None	Public API Only	Public API Only
ความเร็วแบบเพิ่มหน่วย	<200ms (Warm Cache)	<100ms	<150ms	~1.5s	~140ms
การโต้ตอบแบบไดนามิก	Server Islands (WASM Targets)	None	None	Server Islands (JS)	Islands (JS)
เอนจินการค้นหา	Local Semantic WASM Search	Simple String	Simple String	Pagefind (JS)	Pagefind (JS)

การวางตำแหน่งที่ 1.0 #

ที่ 1.0 การวางตำแหน่งที่ตั้งใจไว้คือตัวสร้างเว็บไซต์แบบสแตติกที่ออกแบบมาเป็นโครงสร้างพื้นฐานซอฟต์แวร์ที่ปลอดภัยโดยปริยาย: การเขียนเนื้อหาที่ได้รับการสนับสนุนจากไปป์ไลน์ AI แบบโลคัลเฟิร์สต์ การคอมไพล์หน้ากว่า 100,000 หน้าผ่านไปป์ไลน์สตรีมมิงแบบขนาน WCAG 2.2 AA และ CSP และ SRI ที่เข้มงวดซึ่งบังคับใช้เป็นรั้วกันชนการบิลด์ และดายนามิกไอส์แลนด์แบบแซนด์บ็อกซ์ ทั้งหมดนี้ภายในไบนารี Rust เดียวที่ปลอดภัยด้านหน่วยความจำ แต่ละข้อในคำกล่าวนั้นแมปกับรายการเฉพาะในแผนงานข้างต้นมากกว่าจะเป็นความมุ่งหวังทางการตลาด

การผสานรวมด้านการกำกับดูแลและการปฏิบัติตามข้อกำหนด #

ในภาคองค์กรและการเงินที่มีความเสี่ยงสูง ซอฟต์แวร์ถูกประเมินผ่านมุมมองของการปฏิบัติตามข้อกำหนดและทุนความเสี่ยง แผนงานสถาปัตยกรรมของ static-site-generator สอดคล้องโดยตรงกับข้อบังคับด้านการกำกับดูแลที่สำคัญ:

DORA มาตรา 6 (การจัดการความเสี่ยง ICT): การคำนวณและฉีดแฮช SHA-384 SRI และ Content Security Policy ที่เข้มงวดในขั้นคอมไพล์ไทม์ ตอบสนองข้อกำหนดในการปกป้องช่องทางการเผยแพร่ดิจิทัลจากการฉีดในห่วงโซ่อุปทาน การทำลายหน้าเว็บ และช่องทางการสคริปต์ข้ามไซต์ (XSS)
DORA มาตรา 7 (ความยืดหยุ่นของระบบ ICT): ด้วยการย้ายไปสู่สินทรัพย์สแตติกที่ไม่เปลี่ยนแปลงและตรวจสอบยืนยันในขั้นคอมไพล์ไทม์ สถาบันการเงินกำจัดช่องโหว่ของฐานข้อมูลและเซิร์ฟเวอร์รันไทม์ ลดตัวคูณความเสี่ยงเชิงปฏิบัติการ และลดเงินสำรองทุนความเสี่ยงที่ต้องมีภายใต้ Basel III
พระราชบัญญัติการเข้าถึงได้ของยุโรป (EAA) คำสั่ง (EU) 2019/882: การเลื่อนการตรวจสอบการเข้าถึงได้ไปทางซ้ายเข้าสู่ไปป์ไลน์การคอมไพล์ในฐานะรั้วกันชนคอมไพเลอร์อย่างเด็ดขาด รับประกันการปฏิบัติตามข้อกำหนด 100% ก่อนการนำไปใช้งาน กำจัดความเสี่ยงของความเสียหายต่อแบรนด์และการฟ้องร้องทางแพ่งภายใต้ EAA และ ADA Title III
GDPR มาตรา 25 (ความเป็นส่วนตัวโดยการออกแบบ): การรันไปป์ไลน์การแปลและเมทาดาทาบนฮาร์ดแวร์แบบโลคัลที่แยกเครือข่าย ช่วยเก็บฉบับร่างที่เป็นกรรมสิทธิ์ ตัวชี้วัดทางการเงิน และข้อมูลส่วนบุคคลออกจากผู้ให้บริการ LLM บนคลาวด์ของบุคคลที่สามที่เป็นสาธารณะ สนับสนุนการปฏิบัติตามหลักการอธิปไตยด้านข้อมูล

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

เวอร์ชัน 0.0.41 ส่งมอบอะไรจริงในวันนี้ เทียบกับสิ่งที่ README กล่าวอ้าง? โมเดลความปลอดภัยและการเข้าถึงได้เป็นของจริงและถูกบังคับใช้ในโค้ด: forbid(unsafe_code) ทั่วทั้งเวิร์กสเปซ, การสร้าง SHA-256/384 SRI, การสกัด CSP, การปล่อยเวอร์ชันที่ลงลายเซ็นพร้อมการรับรอง Sigstore และ CycloneDX SBOM และรั้วกันชน WCAG 2.2 AA ที่หยุดการบิลด์ ฟีเจอร์ที่มีเอกสารระบุสามอย่างยังใช้งานไม่ได้ใน v0.0.41 MinifyPlugin เป็นตัวยุบช่องว่างมากกว่าตัวมินิฟายที่เข้าใจไวยากรณ์ DepGraph ที่ควรขับเคลื่อนการรีบิลด์แบบเพิ่มหน่วยถูกคอมไพล์แต่ไม่เคยถูกเติมข้อมูลในโค้ดโปรดักชัน และการเข้ารหัส AVIF เป็นสตับที่ avif_variants คืนค่าเวกเตอร์ว่างเปล่า

รั้วกันชนการเข้าถึงได้เป็นรั้วกันชนคอมไพเลอร์ที่แท้จริงหรือเป็น linter หลังบิลด์? มันเป็นรั้วกันชนการบิลด์ การตรวจสอบ WCAG 2.2 AA ทำงานภายในไปป์ไลน์การคอมไพล์ผ่านตัวแยกวิเคราะห์ axe-core ระดับบิลด์ไทม์ที่ขับเคลื่อนด้วย Playwright และหน้าที่ล้มเหลวจะหยุดการคอมไพล์พร้อมข้อผิดพลาดที่ระบุหมายเลขบรรทัดอย่างแม่นยำ แทนที่จะออกคำเตือนภายหลัง นั่นคือคุณสมบัติที่ภาระผูกพันตามพระราชบัญญัติการเข้าถึงได้ของยุโรปต้องการ: เอาต์พุตที่ไม่เป็นไปตามข้อกำหนดไม่สามารถไปถึงการนำไปใช้งานได้

ทำไมการเรียก curl ผ่านเชลล์ในปลั๊กอิน LLM จึงสำคัญ? ไปป์ไลน์ LLM แบบโลคัล (src/plugins/llm.rs) เรียกไบนารี curl ของโฮสต์เพื่อเข้าถึงเอนด์พอยต์ท้องถิ่น นั่นผูกการบิลด์เข้ากับไฟล์ปฏิบัติการของโฮสต์ ล้มเหลวบนระบบที่ไม่มี curl ใน PATH ก่อให้เกิดพื้นผิวการฉีดคำสั่งเชลล์ และพังในสภาพแวดล้อม CI ที่แยกเครือข่าย การย้ายการเรียกไปยังไคลเอนต์ HTTP ที่เขียนด้วย Rust อย่าง ureq ลบการพึ่งพาภายนอกและช่องทางการฉีดออกไป ซึ่งเป็นเหตุผลที่มันเป็นรายการที่สองในแพตช์ 0.0.42

รายการที่สำคัญที่สุดเพียงรายการเดียวบนเส้นทางสู่ 1.0 คืออะไร? การเติมข้อมูล DepGraph และการเชื่อมต่อแฟล็ก --incremental การรีบิลด์แบบเพิ่มหน่วยคือช่องว่างด้านความน่าเชื่อถือระหว่างเอนจินที่มีเอกสารระบุกับเอนจินที่มีอยู่จริง และทุกคำกล่าวอ้างในภายหลังเกี่ยวกับการบิลด์ในระดับต่ำกว่าวินาทีที่หน้ากว่า 100,000 หน้า ล้วนขึ้นอยู่กับกราฟการพึ่งพาที่ติดตามขอบแบบเทมเพลตต่อหน้าและมาร์กดาวน์ต่อหน้า มากกว่าจะยังคงเป็นโครงสร้างพื้นฐานที่ใช้ในเทสต์เท่านั้น

เอกสารอ้างอิง #

Cloudflare, lol-html: Low-Output-Latency streaming HTML rewriter ⧉. [ตัวเขียน HTML ใหม่แบบสตรีมมิงชนิดซีโร่คอปีที่เสนอให้แทนที่การจัดการสตริงที่เปราะบางในเฟส 0.1.0]
W3C, Web Content Accessibility Guidelines (WCAG) 2.2 ⧉. [เกณฑ์ความสำเร็จระดับ AA ที่บังคับใช้โดยรั้วกันชนการเข้าถึงได้ระดับคอมไพล์ไทม์]
European Union, Regulation (EU) 2022/2554 (DORA) ⧉. [มาตราการจัดการความเสี่ยง ICT และความยืดหยุ่นที่ท่าทีด้านความปลอดภัยแมปเข้าด้วย]
OpenSSF, Supply-chain Levels for Software Artifacts (SLSA) v1.0 ⧉. [กรอบหลักฐานที่มาการบิลด์ที่ตั้งเป้าไว้สำหรับการรับรองระดับ 3 ที่ตรวจสอบยืนยันได้ที่ 1.0]
Armin Ronacher, MiniJinja template engine ⧉. [เอนจินที่พึ่งพาน้อยซึ่งแทนที่ Tera และตัดต้นไม้การพึ่งพาแบบส่งผ่านให้เล็กลง]
CycloneDX, Software Bill of Materials specification v1.5 ⧉. [รูปแบบ SBOM ที่ถูกสร้างในทุกการบิลด์สำหรับการตรวจสอบห่วงโซ่อุปทาน]
European Union, Directive (EU) 2019/882 (European Accessibility Act) ⧉. [ภาระผูกพันด้านการเข้าถึงได้ที่รั้วกันชน WCAG ระดับบิลด์ไทม์ถูกออกแบบมาเพื่อตอบสนอง]

ทบทวนล่าสุดเดือนกรกฎาคม 2026 บทวิเคราะห์ต้นฉบับอ้างอิงจากการตรวจสอบโค้ดเบส static-site-generator ที่เวอร์ชัน v0.0.41 แหล่งข้อมูลถูกอ้างอิง ไม่ได้ทำซ้ำ หมายเลขเวอร์ชันและสถานะฟีเจอร์เปลี่ยนแปลงอย่างรวดเร็ว โปรดตรวจสอบเทียบกับที่เก็บโค้ดก่อนการเผยแพร่ซ้ำ อนุญาตภายใต้ CC-BY-4.0

ทบทวนล่าสุด 2026-08-28.

เผยแพร่บทความนี้ซ้ำ

ตัวสร้างเว็บไซต์แบบสแตติก (SSG): การวิเคราะห์เชิงลึกเชิงกลยุทธ์ระดับองค์กรและแผนงานสถาปัตยกรรม — Sebastien Rousseau

เจาะลึกตัวสร้างเว็บไซต์แบบสแตติกที่เขียนด้วย Rust: ความปลอดภัยระดับคอมไพล์ไทม์ รั้วกันชน WCAG และ AI แบบโลคัลเฟิร์สต์ ช่องว่างใน v0.0.41 และแผนงานระดับองค์กรสู่ 1.0

บทความนี้เผยแพร่ภายใต้สัญญาอนุญาต Creative Commons Attribution 4.0 International. การเผยแพร่ซ้ำต้องระบุที่มาเป็น URL ต้นฉบับ

ตัวสร้างเว็บไซต์แบบสแตติก (SSG): การวิเคราะห์เชิงลึกเชิงกลยุทธ์ระดับองค์กรและแผนงานสถาปัตยกรรม — Sebastien Rousseau

เจาะลึกตัวสร้างเว็บไซต์แบบสแตติกที่เขียนด้วย Rust: ความปลอดภัยระดับคอมไพล์ไทม์ รั้วกันชน WCAG และ AI แบบโลคัลเฟิร์สต์ ช่องว่างใน v0.0.41 และแผนงานระดับองค์กรสู่ 1.0

Originally published at https://sebastienrousseau.com/th/2026-07-22-ssg-kan-wikhro-choeng-luek-lae-phaenngan/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER