PRPL是一种性能加载策略组合，非HTML内置特性；其Push需通过<link rel="preload">等HTML标记辅助，但真正HTTP/2 Server Push依赖服务端配置，HTML仅作触发点。
prpl 标签或属性不会起任何作用。
PRPL 中的 Push 怎么在 HTML 层面配合？
Push 指的是服务器主动推送关键资源（如首屏 JS/CSS），但 HTML 本身不发起 Push —— 它只是触发点。关键在于：<link rel="preload"> 和 <link rel="preconnect"> 能辅助浏览器提前建立连接或加载资源，而真正的 HTTP/2 Server Push 需服务端配置（如 Nginx 的 http2_push 指令）。
- 不要依赖
<link rel="prefetch">做 Push：它属于低优先级后台加载，和 Push 的高优先级、零RTT 本质不同 -
<link rel="preload" as="script" href="main.js">可让浏览器在解析 HTML 时就发起请求，但无法替代 Server Push 对首字节时间（TTFB）的优化 - 如果服务端未开启 HTTP/2 或未配置 Push，HTML 里的
preload仅是“尽力而为”，且可能造成重复请求（比如同时有preload和<script src>）
Render 阶段 HTML 要承担什么责任？
Render 强调“尽快呈现可交互内容”，HTML 是首屏渲染的起点。这里容易忽略的是：HTML 必须做到“可流式解析”——即不能被阻塞，否则整个 PRPL 流程卡在第一步。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 把
<script>放在</body>前，或加defer/async属性；避免内联长脚本阻塞 parser - 关键 CSS 必须内联（
<style>），否则 CSSOM 构建延迟会阻断渲染树生成 - 骨架屏（skeleton）应由 HTML 直接输出，而非等 JS 渲染 —— 否则 Render 变成 JS-driven，失去“立即”意义
- 服务端渲染（SSR）输出的 HTML 必须包含真实首屏 DOM，不能只丢个
<div id="root"></div>
Pre-cache 和 Lazy-load 在 HTML 中怎么落地？
Pre-cache 由 Service Worker 控制，Lazy-load 则高度依赖 HTML 的语义化能力。这两步的成败，往往取决于你写的 HTML 是否“可被工具识别”。
- 图片懒加载必须用
<img loading="lazy">（原生支持），而不是仅靠 JS 库监听 scroll —— 后者在低配设备上易掉帧，且首次渲染仍会触发请求 - 动态导入的路由组件（如
import('./About.js')）最终会生成独立.jschunk，但 HTML 中需确保入口文件不提前引入这些 chunk 的 script 标签 - Service Worker 的
precacheAndRoute方法依赖构建时生成的asset-manifest.json或sw-precache配置；HTML 本身只需正确引用navigator.serviceWorker.register('sw.js') - 不要在 HTML 中手动写
<script src="chunk-xxx.js">—— 这会让 webpack 的 code splitting 失效，导致 Lazy-load 彻底退化
loading="lazy"，Lazy-load 就变成假懒加载；Service Worker 缓存策略没覆盖 HTML 文件本身，Pre-cache 就永远差一环。真正难的不是写对某一行代码，而是让 HTML、JS、服务端、构建工具全部在同一节奏上呼吸。 
