ตัวสร้างเว็บไซต์แบบสแตติก (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-07-24.

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

ตัวสร้างเว็บไซต์แบบสแตติก (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-enterprise-strategic-deep-dive-architectural-roadmap/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER