内联关键css必须紧贴之后，否则浏览器解析到时会暂停html构建、等待cssom就绪，导致fcp延迟；错一位（如插在后）实测白屏多300ms。
head里写错位置会直接拖慢FCP
内联关键CSS必须紧贴<meta charset>之后，否则浏览器解析到<link rel="stylesheet">时会暂停HTML构建，等CSSOM就绪才继续——这一步卡住，FCP就延后。实测错一位（比如插在<title></title>后面），白屏多300ms。
常见错误现象：<link rel="stylesheet" href="main.css">放在<script></script>标签之后，或混在一堆<meta>中间；DevTools的Performance面板里能看到“Parse HTML”长时间阻塞在style请求上。
- 正确顺序：
<meta charset>→<style></style>（关键内联）→<link rel="stylesheet">（非关键外链）→ 其他 - 同步
<script></script>没加defer或async，一样中断解析，FCP延迟比CSS更剧烈 - 如果用了
<link rel="preload" as="style">，必须确保href和后续<link rel="stylesheet">完全一致（含查询参数），否则缓存不复用，等于白加
preload资源没配as属性或配错，等于没写
as不是可选字段，它决定浏览器是否启用对应资源类型的优化策略。写错就降级为普通fetch，Priority变成Medium甚至Low，FCP/LCP都得不到收益。
典型错误：给字体写as="font"但漏掉crossorigin，控制台静默失败或报Failed to decode downloaded font；给图片写as="image"但页面里实际加载的是/hero.webp，而preload指向/hero.jpg，路径不一致导致两次请求。
-
as="font"、as="script"、as="style"（跨域CSS）必须带crossorigin（可为空值：crossorigin=""） -
as="image"和as="video"通常不需要crossorigin，除非托管在跨域且响应头没设Access-Control-Allow-Origin: * - 验证是否生效：Network面板筛选该资源，看
Initiator列是不是preload，Priority是不是Highest或High
首屏图片加loading="lazy"反而拉长LCP
首屏图本该立即加载，加loading="lazy"会让浏览器按启发式策略推迟请求——哪怕它就在视口里。实测LCP延迟200–600ms，尤其在弱网下更明显。
真正该用loading="lazy"的只有非首屏内容：长图文流里的后续段落图、<details></details>折叠区内的图、分页列表第二页起的缩略图。首屏图要么不写loading（默认eager），要么显式写loading="eager"。
- 如果已用
<link rel="preload" as="image">预加载同一张图，fetchpriority="high"自动生效，loading属性可省略 - 用了
srcset时，preload的href必须匹配设备实际请求的尺寸URL，否则缓存不复用 - 背景图（
background-image）浏览器无法自动发现，必须靠<link rel="preload" as="image">显式声明，才能让它参与LCP计算
preload加太多或加错对象，FCP反而变慢
preload不是加速器，是带宽调度指令。加在非关键资源上（比如懒加载轮播图、非首屏视频），会抢占初始TCP连接和带宽，导致HTML、关键CSS下载延迟，FCP被拖慢。
最容易被忽略的是：以为加了preload就等于页面变快，结果监控里FCP没动、LCP也没提——其实是带宽被自己占满了。
- 只对两类资源做
preload有FCP收益：as="image"（首屏LCP候选图）、as="font"（内联CSS中@font-face直接引用且用于首屏文本的字体） - 不要给所有图片加
fetchpriority="high"，浏览器会把它们全归入High队列，稀释真正关键资源的调度权重 - 多个
as="script"预加载但后续没执行（比如条件未满足），浪费连接数，HTTP/2多路复用优势被稀释
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
