HTML在PageSpeed Insights中扣分主因是阻塞关键渲染路径，需删非首屏脚本、内联首屏CSS并异步加载其余CSS、压缩冗余内容、优化服务端响应头与CDN配置。
怎么让 HTML 文件在 PageSpeed Insights 里不扣分
PageSpeed Insights 扣 HTML 分，90% 不是因为 HTML 写得“错”，而是它拖慢了关键渲染路径。核心问题就两个：render-blocking 资源和冗余/低效的 HTML 结构。优化重点不是“压缩 HTML 字符”，而是让浏览器更快拿到首屏内容。
- 删掉所有非首屏必需的
<script>（尤其是没加defer或async的内联脚本） - 把
<link rel="stylesheet">拆成「首屏 CSS 内联」+「其余 CSS 异步加载」，避免阻塞解析 - 移除空格/换行/注释这类“无害但占带宽”的内容——用构建工具（如
html-minifier-terser）做，别手删 - 禁用服务端模板中动态生成的冗余属性，比如 Vue/React SSR 输出的
data-v-xxx、data-reactroot等，它们对首屏无用还增大体积
为什么 inline CSS 能提分，但千万别全量内联
PageSpeed Insights 把“消除阻塞渲染的资源”列为高优项，而 <link rel="stylesheet"> 默认会阻塞 HTML 解析和绘制。内联首屏所需 CSS（Critical CSS）能绕过这个阻塞，但全量内联反而有害。
- 内联 CSS 不会被缓存，每次 HTML 变更都会导致 CSS 重传；外链 CSS 可复用、可长期缓存
- 超过 ~14KB 的内联 CSS 会触发 Chrome 的“延迟解析”机制，实际可能更慢
- 用
critters（Webpack）或critical（CLI）自动提取 Critical CSS，别靠肉眼猜哪些样式是首屏需要的 - 对 Web Components 或 Shadow DOM 场景，内联 CSS 需额外处理作用域，容易漏规则，建议先测再上
script 标签加 defer/async 后还是被标为 render-blocking？
PageSpeed Insights 的“render-blocking resources”检测逻辑很机械：只要 <script> 出现在 <head> 或 <body> 靠前位置，且没显式声明 defer 或 async，就直接标红。但即使加了，也可能因加载顺序或执行时机被误判。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
-
defer脚本仍会阻塞DOMContentLoaded，如果它依赖的 DOM 还没解析完，就会拉长 TTI（Time to Interactive） -
async脚本不保证执行顺序，若多个 async 脚本有依赖关系（比如先载 jQuery 再载插件），必须用import()动态导入替代 - 第三方脚本（如统计、广告）默认不支持
defer，要用loadScript延迟到idle状态再加载，或用iframe沙箱隔离 - 检查 Network 面板里的
Initiator列，确认是不是某个库（比如polyfill.io）动态注入了未标记的 script
HTTP 响应头和服务器配置比 HTML 本身影响更大
很多开发者盯着 HTML 源码改，却忽略真正卡住页面的是传输层。PageSpeed Insights 的“Largest Contentful Paint”和“Time to First Byte”两项，80% 由服务端决定。
立即学习“前端免费学习笔记（深入）”；
- 确保服务器返回
Content-Encoding: gzip或br（Brotli），HTML 压缩率通常达 70%+，但 Nginx 默认不启 Brotli，需手动编译模块 - 设置
Cache-Control: public, max-age=3600给 HTML（注意：不能设太长，否则更新难生效），配合 ETag 或 Last-Modified 实现协商缓存 - 启用 HTTP/2 或 HTTP/3，让多个
<link>和<script>并发加载，避免队头阻塞 - CDN 节点若未开启
Early Hints（103 status），就无法提前推送关键资源，HTML 里写的<link rel="preload">效果大打折扣
最常被忽略的一点：PageSpeed Insights 的移动分数基于模拟的 4G + 低端设备，但你的本地开发环境跑的是千兆光纤 + M3 MacBook。不关掉 Chrome DevTools 的 Network Throttling 去验证，所有优化都只是纸面提速。
