Core Web Vitals 由浏览器根据真实用户行为计算，HTML 仅是影响因素之一；<link rel="preload"> 可加速 LCP 关键资源加载，width/height 和 decoding="async" 有助于防控 CLS，而过度内联 CSS 反可能延迟 FCP。
Core Web Vitals 不是 HTML 能“做”出来的，而是浏览器根据用户真实加载、渲染、交互行为计算出的性能指标；HTML 本身只是影响它们的底层载体之一——改错地方，毫无作用；改对地方，效果立现。
为什么 <link rel="preload"> 对 LCP 很关键
LCP（最大内容绘制）通常由首屏大图、标题或 Hero 区块中的 <img>、<h1> 或 <div> 触发。若关键资源（如主图、字体、关键 CSS）加载被阻塞，LCP 就会严重延迟。
-
<link rel="preload" href="hero.jpg" as="image">必须放在<head>中，且as值要准确（image/font/style），否则浏览器不会提前抓取 - 不要 preload 非首屏图片（比如轮播第二张），会挤占带宽，反而拖慢 LCP
- preload 字体时，必须加
crossorigin属性：<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>，否则可能被忽略 - Chrome DevTools 的 “Network” 选项卡里，preloaded 资源应显示为 “Priority: Highest”，否则检查路径或 MIME 类型是否匹配
<img> 的 width/height 和 decoding="async" 怎么防 CLS
CLS（累积布局偏移）主要来自无尺寸声明的图片、广告、嵌入内容在加载后突然撑开页面。HTML 层面最直接的控制点就是 <img> 和 <iframe>。
- 始终设置
width和height属性（不是 CSS），例如：<img src="logo.png" width="120" height="40">，现代浏览器据此预留空间，避免重排 - 响应式场景下用
aspect-ratioCSS 配合width: 100%更灵活，但 HTML 属性仍是 fallback 和 SSR 友好保障 -
decoding="async"让图片解码不阻塞主线程，尤其对长列表中的图片能降低布局抖动概率；但注意 Safari 目前不支持该属性 - 避免在
<div>内部用display: inline-block+ 图片未设高宽的组合——这是 CLS 高发模式
内联关键 CSS 为什么有时让 FCP 更差
FCP（首次内容绘制）受阻于渲染树构建速度。内联 CSS 看似快，但实际可能触发反效果：
立即学习“前端免费学习笔记（深入）”；
- 过大的
<style>块（> 10KB）会显著延长 HTML 解析时间，反而推迟 FCP；建议只内联首屏必需的、 - 内联 CSS 无法被缓存，每次 HTML 更新都会强制重新下载全部样式；而外链 CSS 可复用，长期更优
- 若使用
<link rel="stylesheet" media="print" onload="this.media='all'">异步加载非关键 CSS，记得补上onload回调，否则样式可能永久不生效 - 用 Chrome 的 “Coverage” 工具（More Tools → Coverage）可精准识别哪些 CSS 规则真正用于首屏，避免盲目内联
HTML 层优化的边界很清晰：它不决定 JavaScript 执行时机，也不压缩图片体积，更不解决服务器 TTFB；但它决定了资源加载优先级、布局稳定性基础和渲染流水线起点。漏掉 width/height、乱用 preload、硬塞 15KB 内联 CSS——这些细节比写多少个 <meta> 都管用。
