HTML性能优化不直接计分但影响FCP、LCP、CLS等核心指标；改img的loading="lazy"和decoding="async"可减少主线程阻塞、避免布局偏移，需配width/height；preload须慎用，仅限字体、关键CSS、hero图等高优且无法自动发现的资源，并严格指定as和crossorigin；关键CSS应精准内联首屏必需规则，避免全量或含@import/@font-face，超14KB时分段异步加载；优化本质是理解浏览器渲染流水线，而非盲目压缩或加属性。
HTML 性能本身不直接参与 Lighthouse 或其他工具的「评分优化」计算，但它是影响核心指标（如 FCP、LCP、CLS）的底层载体——改 HTML 写法，是在改渲染路径和资源加载逻辑，不是在调某个“性能开关”。
为什么改 <img> 的 loading 和 decoding 属性能提分
浏览器默认同步解码、同步加载所有 <img>，会阻塞主线程并拖慢 LCP。加属性是告诉浏览器：“这张图不用马上处理”。
-
loading="lazy"：仅对非视口内图片启用延迟加载（注意：Safari 15.4+ 才完全支持，旧版需降级用 IntersectionObserver） -
decoding="async"：让图片解码脱离主线程，避免卡顿（Chrome 60+ 支持，对大图效果明显） - 必须同时指定
width和height，否则可能引发CLS（布局偏移）
<link rel="preload"> 不是越多越好，关键看资源类型和时机
滥用 preload 会抢占带宽、挤占关键资源请求，反而拉低 FCP。它只适合极少数高优先级、且无法被 HTML 解析器自动发现的资源。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 适用场景：
font（WOFF2 格式）、critical CSS（内联不够时）、hero 图片（<img>在 JS 渲染后才插入的情况） - 禁用场景：普通 JS/CSS 文件（HTML 中已有
<script>/<link>，浏览器会自动预加载） - 必须加
as属性（如as="font"），否则浏览器无法正确设置请求优先级和 CORS 模式 - 不要对跨域字体漏加
crossorigin，否则会触发两次请求（一次无凭据，一次有凭据）
内联关键 CSS 时，别把整个 style.css 塞进 <head>
内联目标不是“把样式放进来”，而是“只放首屏渲染必需的那部分规则”。全量内联反而增大 HTML 体积，延长 TTFB 和解析时间，损害 FCP。
立即学习“前端免费学习笔记（深入）”；
- 用工具提取（如
PurifyCSS、critters、或构建时配合playwright抓取首屏 DOM 计算关键 CSS） - 避免内联含
@import、@font-face（后者应改用preload）、或大量媒体查询（非首屏断点规则会白占字节） - 如果关键 CSS > 14KB，考虑拆成两段：最核心的（如排版、颜色）内联，次关键的用
<link rel="stylesheet" media="print" onload="this.media='all'">异步升权
真正卡住 HTML 性能的，往往不是语法错误，而是对浏览器渲染流水线的理解偏差——比如以为 defer 脚本能解决一切阻塞，却忽略了它不影响 HTML 解析；或者以为压缩 HTML 字节数就是优化，却没意识到空白符删减对现代 gzip/brotli 几乎无收益。动手前，先看 Network 面板的 Waterfall 和 Rendering 面板的帧率曲线，比盲目改标签有效得多。
