8.1 首屏加载与图片字体优化

8.1 首屏加载与图片字体优化

冲刺从首屏开始。本节讲三大核心指标的口径、首屏关键路径的分析法，然后集中治理两类最典型的资产浪费——图片与字体。第 7 章的构建优化砍的是 JS 字节，本节把战场扩展到整个关键路径。

三个数字先立起来

Core Web Vitals 三指标，每个都对应真实的用户感受：

• LCP（最大内容绘制）：视口内最大元素渲染完成的时刻。内容型站点的首屏大图、大标题是 LCP 元素的常客。良好线约两秒五以内；
• INP（交互到下次绘制）：用户交互后界面响应的速度。长任务阻塞主线程是主因，良好线两百毫秒级；
• CLS（累积布局偏移）：页面加载过程中元素意外跳动的总和。图片无尺寸占位、字体替换引起的文本移位是两大推手，良好线零点一以内。

Nuxt 对三者有先天贡献：SSR 让内容直接进 HTML（LCP 的内容不用等 JS）；水合期间的长任务影响 INP（减 JS 体积即第 7 章的工作）；CLS 则主要靠资产治理——本节主角。

图 8-1：首屏关键路径与优化落点

图片：治理与例外

7.3 已给出图片模块的基本用法，这里补齐策略面。日常图片（视口外）懒加载；LCP 候选图例外——首屏主视觉就该立即加载，再懒反而拖 LCP：

<template>
  <!-- 首屏主视觉：立即加载 + 高优先级 + 尺寸占位 -->
  <NuxtImg
    src="/hero.jpg"
    width="1600" height="600"
    :preload="true"
    fetchpriority="high"
    alt="商品橱窗"
  />

  <!-- 列表缩略图：视口外懒加载，sizes 让浏览器按视口选图 -->
  <NuxtImg
    v-for="p in products"
    :src="p.cover"
    :width="400" :height="300"
    loading="lazy"
    :sizes="'sm:100vw md:50vw lg:400px'"
    :alt="p.name"
  />
</template>
​

width/height 属性不只是显示尺寸——它在图片到达前撑住占位，CLS 直接归零。忘了写这对属性是内容站 CLS 超标的第一原因。

字体：不阻塞、不跳动

字体问题的两面：外链字体阻塞文本渲染（用户盯空白）；字体到达后文本重排（布局跳动）。治理组合：

// nuxt.config.ts：字体模块统一管理
export default defineNuxtConfig({
  modules: ['@nuxtjs/fonts'],
  fonts: {
    // 声明式定义用到的字体族，模块负责自托管、预载与回退度量
    families: [
      { name: 'Inter', provider: 'google', weights: [400, 600] },
    ],
  },
})
​

/* 回退字体度量对齐：即使字体没到，文本位置也不跳 */
/* 字体模块会自动生成度量匹配的回退，手工方案则用 size-adjust 类属性 */

/* 老项目的典型错误写法（外链阻塞渲染）：
   @import url('https://fonts.example.com/css?family=...');
*/
​

中文字体的特殊账：全量中文字体数兆字节，必须子集化（按页面实际用到的字符切片）或用分包服务。中文字重从四个砍到两个，往往就是数兆的节约。

首屏关键路径分析法

工具与流程，一次真实排查的样例：

1. 打开开发者工具 Network 面板，勾选禁用缓存与 Slow 4G 节流，刷新页面；
2. 按瀑布图读三件事：HTML 何时到（网络段）、CSS 与首图何时开始请求（资产段）、有没有串行等待（前一个资源阻塞后一个）；
3. Performance 面板录一次加载，找 LCP 事件的时间戳，看它前面的长任务与网络空闲。

典型的三种病：HTML 慢（SSR 接口拖沓——回 3.2/6.2 治取数）；资产慢（原图直出、外链字体——本节治理）；串行长（CSS 里阻塞渲染的字体请求、JS 阻塞的组件——7.1 的 Lazy 与分包）。定位到段，对应章节的动作清单照做，复测看数字。

动手实验：给自己的页面量三围

理论落地成手感需要一次亲手测量。在自己的练习项目里走一遍：

第一步，打开开发者工具，切到 Performance 面板，勾选截图与内存，录一次移动端节流下的页面加载。第二步，录完后在时间轴上找 LCP 标记（通常在概览栏有菱形图标），读它的时刻与对应元素——这个元素就是你的"首屏代言人"，一切首屏优化都围绕它。第三步，往回看它之前的时间线上有什么阻塞：黄色长条（JS 执行）、绿色请求瀑布（资源串行）、还是空白（网络等待）。第四步，把三个数字记下来：LCP 时刻、最大的脚本任务时长、CLS 总值。这就是你的基线，之后每做一次 8-1 图里的优化动作，回来重测对比。

这个循环里最容易被忽略的是"归因"环节：LCP 元素是什么决定优化方向——是主图就去治图（压缩、preload、尺寸），是文字就去治渲染阻塞（字体、CSS），是接口数据就去治 TTFB（缓存、并行）。不同病因同一个症状（LCP 超标），动作完全不同。做完一轮实验，把 LCP 元素的截图贴在团队 wiki 里，"我们站的首屏代言人是谁"这个问题有了具象答案，优化讨论就不会跑偏。

弱网专项：4G 以下的体面

城市里的开发者永远低估弱网的恶劣程度。电梯、地铁、拥挤会场，真实用户常在 2-4 Mbps 且高延迟的网络里打开你的页面。弱网专项三件事：其一，关键 CSS 内联进 HTML（首屏样式不额外请求，弱网下省一个往返就是省几百毫秒）；其二，图片降级体验（blurhash 类的模糊占位，让"图还没到"这件事优雅一点）；其三，接口超时与重试策略（弱网超时是常态而非异常，4.3 的错误面板配上自动重试，用户体验天差地别）。测试时用节流面板自定义一个"恶劣档"（延迟四百毫秒、下行一点六 Mbps），在这个档位下还能完成核心流程的站点，才算对弱网用户尽了基本礼节。

⚠️ 常见坑：把 LCP 图设成懒加载。主视觉图被 lazy 后要等 JS 执行完才开始下载，LCP 直接翻倍。懒加载只给视口外的图，首屏主视觉要 preload 加高优先级。

💡 关键直觉：CLS 的本质是"浏览器以为的布局"和"资产到达后的布局"不一致——一切给资产提前声明尺寸与位置的手段（宽高属性、字体度量对齐、骨架屏）都是在给浏览器"剧透"，剧透越充分，跳动越少。

本节要点回顾

• 三指标口径：LCP 首屏大元素、INP 交互响应、CLS 布局稳定；Nuxt 的 SSR 先天利好 LCP；
• 图片三动作：压缩转码、宽高占位、视口外懒加载——LCP 候选图例外要 preload；
• 字体三动作：自托管同域、字重与字符子集化（中文尤其）、回退度量对齐防跳动；
• 关键路径三段论：网络段（CDN/缓存）、生成段（SSR 取数）、资产段（图片字体），分段归因再动手；
• 测量纪律：禁用缓存加节流再读瀑布图，不测量的优化是玄学。