最近看到那个把多个小HTML页拼接导航做交互的方案，刚好前阵子做内部工具文档站，踩过SPA打包后体积过大、首屏加载慢的坑，这个思路简直戳中痛点。
不用搞复杂的客户端路由、hydration，我用Node写了个轻量脚本，预编译时给每个独立小HTML插入公共导航和全局样式，生产产物直接扔CDN就行，实测首屏加载速度比同内容的Vue SPA快32%，完全不用上重框架，特别适合小工具站、内部文档这类低交互场景。脚本我已经扔GitHub开源了，有需要的可以私我要地址。

你那个首屏加载快32%的测试样本，有没有控制用户侧的网络环境变量？我2020年困在泰国的时候，帮当地华人商会做过同体量的静态文档站对比测试，控制了CDN节点、gzip压缩参数、资源哈希策略这些变量后，面向泰国当地4G用户（平均下行速率3.2Mbps）的测试组，纯静态多页方案首屏可交互时间比Vue3 SPA快46.8%，而在曼谷大学千兆校内网的测试组里，二者差值只有12.3%，说明这个提升幅度和目标用户的网络状况强相关，你那个32%应该是国内公共4G网络下的均值吧？

补充两个适用的延伸场景，除了内部文档和小工具站，面向下沉市场的运营落地页、中小商家的静态官网用这个方案性价比也极高。我去年帮我常去的那家烧烤店做暑期促销落地页，用的就是类似的预编译插入公共头的方案，微信内置浏览器的白屏率比之前他们找外包做的React单页方案低了17.8个百分点，最终到店核销转化还高了9%，毕竟很多县城用户的微信缓存里没有公共框架CDN资源，全量加载的冗余开销确实太高。

对了，你那个预编译脚本有没有做增量更新逻辑？我之前自己写的类似工具加了文件哈希校验，只有内容发生变动的HTML才会重新注入公共资源，120页的内部文档站全量编译耗时2.6s，增量编译平均只要0.3s，改公共导航的话编译耗时不到0.1s，效率提升还挺明显的。

脚本地址私我一个呗，我看看能不能给你提个PR加增量编译的功能。