HTML结构虽不直接产生Core Web Vitals分数，但精准优化可立显效果：仅preload触发LCP的资源（首屏图、关键字体、首屏CSS），必须匹配href路径、正确设置as和crossorigin；img务必声明width/height防CLS；内联CSS须≤10KB且仅含首屏必需样式。
HTML 结构本身不直接“产生” Core Web Vitals 分数，但它是 LCP、CLS、FCP 等指标的底层载体——改错地方毫无作用，改对地方效果立现。关键不是“写得漂亮”，而是让浏览器能更快解析、更早预留空间、更少重排重绘。
link rel="preload" 必须精准命中 LCP 候选资源
很多项目加了 <link rel="preload"> 却没效果，根本原因是路径错、as 值错、或 preload 了不该 preload 的东西。
- 只 preload 真正触发 LCP 的资源：首屏大图（
as="image"）、关键字体（as="font"+crossorigin）、首屏必需 CSS（as="style"） -
href必须与实际加载路径完全一致（含大小写、扩展名），否则 Chrome Network 面板里不会显示Priority: Highest - 不要 preload 轮播第二张图、折叠区域图片、
display: none的元素——它们挤占主资源带宽，反而拖慢 LCP - 字体 preload 必须带
crossorigin属性，否则多数浏览器会忽略；type="font/woff2"建议加上，避免 MIME 类型不匹配
img 的 width/height 和 decoding="async" 是 CLS 最低成本防线
CLS 多数来自图片加载后突然撑开布局，而 HTML 层面最直接、最轻量的控制点就是 <img> 标签本身。
- 必须声明
width和height属性（不是 CSS），例如<img src="hero.jpg" width="1200" height="630">；现代浏览器据此预留 intrinsic size，防止重排 - 响应式场景下，用 CSS
width: 100%+aspect-ratio更灵活，但 HTML 属性仍是 SSR 和低版本浏览器 fallback 的唯一保障 -
decoding="async"让图片解码不阻塞主线程，对长列表尤其有效；注意 Safari 目前不支持，需配合 JS 检测降级 - 避免
<div><img></div>+display: inline-block+ 无尺寸图片的组合——这是 CLS 高发模式，优先改用display: block或 flex/grid 布局
内联 CSS 不等于更快：超过 10KB 就可能拖慢 FCP
很多人把关键 CSS 全部内联进 <head>，结果 FCP 反而变差——因为 HTML 解析被大块 <style> 阻塞，渲染树构建延迟。
立即学习“前端免费学习笔记（深入）”；
- 只内联真正首屏必需的样式（比如 Hero 区块、导航栏、首屏文字排版），用 Chrome Coverage 工具精准识别，别凭感觉“全塞进去”
- 单个
<style>块建议 ≤ 10KB；超出后，HTML 解析时间增长明显，FCP 推迟风险陡增 - 内联 CSS 无法缓存，每次 HTML 更新都强制重传全部样式；外链 CSS 可复用，长期更优
- 非关键 CSS 用
<link rel="stylesheet" media="print" onload="this.media='all'">异步加载，但务必确保onload回调执行，否则样式永久不生效
真正难的不是知道该做什么，而是判断“哪个资源是 LCP 候选”“哪段 CSS 算首屏必需”“这张图到底要不要设 height”——这些依赖真实页面结构和用户流量分布，脱离上下文谈优化，90% 都是白忙活。
