Speculation Rules脚本必须用<script type="speculationrules">声明，放<head>中，内容为无注释、无尾逗号、小写字段的纯JSON；eagerness三档对应明确用户信号，where需精确匹配避免副作用。
Speculation Rules 不是“加了就快”，而是“配错就崩”——尤其在 prerender 场景下，页面 JS 会真执行，fetch 会真发，localStorage 会真写。
怎么写 speculationrules 脚本才合法
必须用 <script type="speculationrules">，不能是 text/json 或普通 script。浏览器只认这个 MIME 类型，其他写法直接忽略，连报错都不会抛。
- 放在
<head>里最稳妥；放<body>底部可能因 DOM 尚未解析完而漏掉部分链接 - 内容必须是纯 JSON，不能带注释、不能有 trailing comma、不能用单引号
- 一个页面只允许一个
speculationrules脚本；多个会以最后一个为准，前面的被丢弃 - JSON 根对象只能是对象，不能是数组；字段名如
prerender、prefetch必须小写
eagerness 三档到底触发什么行为
不是“越 eager 越好”，而是每档对应明确的用户信号，且不可微调：
-
eagerness: "eager"：链接元素进入视口（IntersectionObserver触发）即启动，不等悬停。适合轮播图下方固定跳转链接这类高确定性路径 -
eagerness: "moderate"：鼠标悬停或键盘focus后约 200ms 启动（含去抖），是唯一兼顾防误触和响应速度的档位，90% 的导航链接该用它 -
eagerness: "conservative"：仅在mousedown事件那一刻启动，不是 click 完成后。适合“提交订单”这种高代价页，但副作用（如提前调用支付 SDK）也会提前发生
注意：eagerness 在低内存设备上可能被 Chrome 自动降级，无法强制维持。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
where 匹配规则怎么写才不翻车
where 是过滤链接的条件，写错会导致全站链接被预渲染，内存暴涨甚至页面卡死：
-
href_matches: "/*"看似方便，实则危险——它匹配所有同源链接，包括页脚的“隐私政策”“关于我们”，这些页面 JS 可能含埋点、上报、第三方初始化，全部白跑一遍 - 推荐用精确前缀：
href_matches: "/product/"或href_matches: "/checkout/*"，避免通配符泛滥 - 组合条件要用
and/not对象，比如排除登录页：{"and": [{"href_matches":"/account/"}, {"not": {"href_matches":"*login*"}}]} - 跨域链接即使匹配也静默忽略，不会报错，但也不会生效
为什么 prerender 后页面逻辑乱了
因为 prerender 阶段目标页的 JS 是真实执行的，不是模拟环境：
- API 请求会发出，但响应可能被丢弃（除非页面真正激活）；重复下单、重复埋点就从这儿来
- 检查
document.prerendering布尔值，只在false时执行敏感操作（如fetch('/api/submit-order')） - 登录态必须透传：如果目标页依赖 Cookie 或
Authorizationheader，确保服务端允许预渲染请求携带这些凭据（否则预渲染会卡在 401） - 不要在 prerender 页面里写
localStorage.setItem('seen_tour', 'true')这类副作用，用户没点进去就已生效
真正难的从来不是语法，而是判断哪一页的 JS 能安全地提前跑——这得靠你对业务逻辑副作用的诚实评估，而不是靠 eagerness 滑杆拉满。
