静态优先微前端模型要求子应用以HTML为入口并内联关键CSS、预加载字体等资源，由主应用提前fetch解析HTML并注入静态资源，避免JS执行阻塞首屏渲染。
静态优先的微前端加载模型，核心是让子应用的 HTML、CSS、字体、图标等非 JS 资源在 JS 执行前就完成下载和就绪，从而让浏览器能尽早触发渲染（FP/FCP），而不是卡在 JS 解析执行上干等。这直接对抗冷启动白屏——尤其对首次访问、弱网、低端设备效果显著。
为什么不能只靠 preloadApp 预加载 JS？
很多团队调用无界微前端的 preloadApp 后发现白屏没明显改善，问题常出在这里：该接口默认只预加载子应用的 entry JS（比如 main.js），但实际首屏渲染依赖的是 HTML 中内联的 CSS、<link rel="stylesheet">、<link rel="preload" as="font"> 这类静态资源。JS 本身不参与首帧绘制，它只是“指挥渲染”的角色。等 JS 下载完、解析完、执行到挂载逻辑，页面才真正开始动——此时白屏早已持续 1~2 秒。
实操建议：
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 用浏览器 Network 面板过滤
document和stylesheet类型，确认子应用 HTML 是否被主应用以fetch或 iframe 方式加载；若走的是 JS Entry 模式（如import('http://subapp/main.js')），那 HTML/CSS 根本不会提前触达浏览器，静态优先无从谈起 - 强制子应用采用 HTML Entry：入口必须是 HTML 文件（如
http://subapp/index.html），且该 HTML 内需内联关键 CSS、预加载字体、声明<link rel="preload" as="image">等 - 主应用在调用
preloadApp前，先手动fetch子应用 HTML 并解析其<link>标签，提取出所有stylesheet、font、image资源 URL，用document.createElement('link')注入到主文档 head 中
子应用 HTML 必须内联 Critical CSS，不能只靠外部 link
外部 CSS 文件会阻塞渲染，但浏览器只有解析完 HTML、遇到 <link rel="stylesheet"> 才发起请求。如果这个请求慢（比如 CDN 回源、TTFB 高），首屏渲染就会延迟。而内联 Critical CSS（首屏必需的样式）能让浏览器一边解析 HTML 一边构建 CSSOM，无需等待网络。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 子应用构建时用工具（如
critters或mini-css-extract-plugin+ 自定义 critical css 提取脚本）生成首屏样式字符串，注入到 HTML 的<style id="critical-css">...</style>中 - 避免内联整个 CSS 文件——只保留
body > header、.skeleton、.logo等首屏可见区域的规则；剩余样式仍走外部<link>，并加media="print" onload="this.media='all'"异步加载 - 主应用接管子应用 HTML 后，检查是否存在
#critical-css，若无则告警；若有，确保它在子应用 JS 执行前已存在于 DOM 中（不要等 JS 动态插入）
预加载时机必须脱离 JS 执行流，用 requestIdleCallback 或 document.readyState
把 preloadApp 写在主应用路由守卫或组件 mounted 钩子中，等于把它绑死在 JS 主线程里。一旦主应用 JS 体积大、执行慢，预加载就被拖到白屏后期才开始，失去意义。
实操建议：
- 在主应用 HTML 的
<head>底部，立即执行一段轻量脚本：if (document.readyState === 'loading') { document.addEventListener('DOMContentLoaded', () => preloadSubApp()); } else { requestIdleCallback(() => preloadSubApp(), { timeout: 3000 }); } -
preloadSubApp()函数内只做三件事：fetch 子应用 HTML、解析并预加载其静态资源、缓存 HTML 字符串——不执行任何子应用 JS，不调用wujie.mount - 禁用子应用自身的资源预加载逻辑（如 Webpack 的
prefetch、Vite 的preload），由主应用统一调度，避免重复请求和竞争
CDN 缓存策略必须区分 HTML 与 JS/CSS
子应用 HTML 是动态内容（可能含版本 hash、环境变量），但它的静态资源（CSS/JS/字体）是强缓存对象。如果 CDN 对整个子应用域名统一配 Cache-Control: public, max-age=3600，会导致 HTML 更新后，旧 HTML 里引用的旧 CSS URL 仍被缓存，用户拿到的是不匹配的样式。
实操建议：
- 子应用部署时，HTML 文件不加 hash，路径固定为
/index.html；CSS/JS/字体全部带 contenthash，路径如/static/css/app.abc123.css - CDN 配置两条规则：
— 匹配/*.html：缓存 5 分钟，Cache-Control: public, max-age=300
— 匹配/static/**：缓存 1 年，Cache-Control: public, max-age=31536000, immutable - 主应用预加载时，从 HTML 中提取的资源 URL 必须是带 hash 的完整路径（如
https://cdn/subapp/static/css/app.abc123.css），不能省略 hash 直接拼/static/css/app.css
真正难的不是写对这几行代码，而是让子应用团队接受“HTML 不再是 JS 的附属品，而是首屏渲染的第一责任人”。静态优先不是主应用单方面优化，它要求子应用交付物从“可执行 JS 包”回归到“可渲染 HTML 文档”。任何跳过 HTML 入口、或把样式全扔进 JS 的做法，都会让这套模型失效。
