Django 文章页 Core Web Vitals 实战：用 Lighthouse 排查 LCP、CLS 与字体阻塞

先把性能问题变成可验证的问题

文章页的“打开速度慢”“图片跳动”或“点击后没反应”，通常不是同一个问题。Core Web Vitals（核心网页指标）提供了一组可量化的用户体验信号：LCP 关注主要内容何时出现，CLS 关注页面是否在加载过程中意外移动，INP 关注用户交互得到响应所需的时间。当前这三个指标分别对应加载、稳定性和交互体验；它们可以帮助定位问题，但不能单独承诺排名提升。

本文以 Django 技术博客的文章详情页为例，建立一套可复用的检查流程。你会看到如何用 Lighthouse 生成实验室报告，如何从报告中找到真正的候选元素，以及怎样修改模板和 CSS 后再做回归验证。站内的 Django 图片处理流水线 更关注上传、派生图和媒体 URL；本文继续处理图片交付到浏览器后对首屏和布局的影响。

指标阈值和浏览器实现会随标准更新。发布报告时应记录测试时间、设备模拟、网络条件和页面版本，不要把一次本地分数写成所有用户都能得到的结果。

表格中的阈值是字段数据第 75 百分位的评估标准，不是本站或任何网站的性能承诺；对应的“需要改进”上限分别约为 4 秒、0.25 和 500 毫秒。实验室报告可以提供诊断线索，但一次 Lighthouse 结果不能当成字段数据的第 75 百分位。测试时还要记录 needs-improvement 和 poor 的区间，避免只保留一个分数而丢失问题上下文。

LCP、CLS 和 INP 分别测什么

LCP：主要内容什么时候出现

Largest Contentful Paint（LCP）记录视口内最大文本块、图片或视频海报等主要内容完成绘制的时间。文章页的候选元素常见于标题、封面图片或第一段较大的文本块。根据 web.dev 的当前建议，LCP 不超过 2.5 秒属于良好，2.5 到 4 秒需要改进，超过 4 秒则较差。这个阈值是评估标准，不是一次测试必须达到的承诺。

如果封面图是 LCP 候选，常见原因包括：图片请求开始得太晚、原图过大、没有正确的尺寸变体、服务端响应慢，或者 CSS 背景图只能在样式计算后才开始请求。改进时应先确认候选元素和请求瀑布，再选择 srcset、压缩、缓存或优先级策略。

CLS：页面为什么会跳动

Cumulative Layout Shift（CLS）衡量页面生命周期内未预期的布局移动。图片没有宽高、字体切换改变了行高、异步插入的提示框没有预留空间、广告或推荐模块在正文上方突然出现，都可能让已经看到的内容发生位移。CLS 不只是“页面最后看起来是否整齐”，而是浏览过程中发生过多少次意外移动。

当前常用的判断线是 CLS 不超过 0.1 为良好，0.1 到 0.25 需要改进。修复时不要只给所有元素加固定高度；应该给可预测的媒体比例和异步区域预留真实空间，避免用错误的尺寸把内容裁切或推到不可见位置。

INP：交互是否及时得到反馈

Interaction to Next Paint（INP）关注点击、触摸或键盘操作后，浏览器何时能绘制出响应结果。它已经取代 FID 成为 Core Web Vitals 的交互指标。文章页中，目录跳转、复制链接、评论回复和分享按钮都可能触发脚本。如果事件处理器同步执行大量计算、解析很大的 JSON 或反复改动 DOM，INP 会变差。

INP 良好通常意味着不超过 200 毫秒，200 到 500 毫秒需要改进。它不是要求每个事件都在 200 毫秒内完成网络请求，而是要求用户能尽快看到明确的界面反馈；耗时任务应拆分、延后或移交给服务端。

先建立一次能复现的基线

Lighthouse 的移动端和桌面端报告

Lighthouse 是实验室测试工具。同一页面在不同网络、CPU 模拟和缓存状态下可能得到不同结果，所以基线必须固定测试条件，并至少运行三次后观察中位数。下面的命令会保存 JSON，不会把报告分数硬编码进文章或部署脚本：

mkdir -p reports

npx lighthouse https://blog.zenleak.cn/post/304/ \
  --form-factor=mobile \
  --output=json \
  --output-path=./reports/post-304-mobile.json \
  --chrome-flags="--headless" \
  --quiet

npx lighthouse https://blog.zenleak.cn/post/304/ \
  --preset=desktop \
  --output=json \
  --output-path=./reports/post-304-desktop.json \
  --chrome-flags="--headless" \
  --quiet

运行前先确认 Node.js 和 Lighthouse 版本，建议使用当前版本并在报告中保存 URL、测试时间和版本信息。若某个版本不提供某个审计，应先升级工具，不要据此推断指标正常。测试页面应使用公开的最终 URL，避免把带调试参数、登录态或后台地址当成生产基线。Lighthouse 的分数是实验室结果，不能代替真实用户数据。

从 JSON 中读取关键审计

不要只盯着 Performance 总分。先读取三个指标和 Lighthouse 识别出的候选元素，再决定改哪个请求。下面的 Node.js 脚本只读取本地报告：

// read-lighthouse-metrics.mjs
import { readFile } from "node:fs/promises";

const report = JSON.parse(await readFile(process.argv[2], "utf8"));
const ids = [
  "largest-contentful-paint",
  "cumulative-layout-shift",
  "interaction-to-next-paint",
  "largest-contentful-paint-element",
];

for (const id of ids) {
  const audit = report.audits?.[id];
  if (!audit) continue;
  console.log(`${id}: ${audit.displayValue ?? "n/a"}`);
  if (audit.details?.items?.length) {
    console.log(JSON.stringify(audit.details.items.slice(0, 3), null, 2));
  }
}

运行 node read-lighthouse-metrics.mjs ./reports/post-304-mobile.json 后，重点看 LCP 元素、资源 URL、传输大小和建议的诊断项。若报告里没有某个审计，不要把“没有数据”当成“指标一定正常”；先检查 Lighthouse 版本和页面是否在测试时完成加载。

实验室数据和真实用户数据要分开

Lighthouse 使用固定的模拟环境，适合比较一次改动前后的方向。PageSpeed Insights 或 CrUX 等真实用户数据则反映实际设备、网络和交互，但只有在样本足够时才会提供 URL 级数据；新页面可能没有足够样本。两类数据不一致并不代表工具出错：实验室报告可以定位候选问题，真实用户数据可以判断问题是否在访问者中普遍存在。

站内的 SEO 进阶测量与验证 介绍了如何区分抓取、收录、展现和点击；性能报告也应该采用同样的原则，把“工具检测到的问题”和“用户确实遇到的问题”分开记录。

用 Django 模板先解决 LCP 和布局预留

给首屏图片提供真实尺寸

文章封面应使用语义化的 <img>，并输出图片固有宽高。浏览器可以在图片下载完成前预留正确比例，减少 CLS；CSS 再控制图片如何适配容器。封面是首屏主要内容时，可以使用 loading="eager" 和 fetchpriority="high"，但不要把这些属性复制到正文每一张图片上：

{% if post.featured_image %}
<div class="post-featured-image article-cover">
    <img
        src="{{ post.featured_image.url }}"
        alt="{{ post.title }}"
        width="{{ post.featured_image.width|default:'1200' }}"
        height="{{ post.featured_image.height|default:'630' }}"
        loading="eager"
        fetchpriority="high"
        decoding="async">
</div>
{% endif %}

如果图片尺寸来自用户上传，应在保存时记录宽高，并检查字段为空或异常的旧数据。不要把 MEDIA_ROOT 这样的服务器文件系统路径写进 src；模板应使用存储后端返回的公开 URL。图片上传和派生尺寸的安全边界可参考 Django 图片处理流水线。

用 srcset 交付合适的资源

只把一张 2400 像素原图缩到手机宽度，并不会减少下载量。为常见展示宽度生成派生图，然后让浏览器按照 sizes 选择资源：

<img
    src="{{ image.large_url }}"
    srcset="{{ image.small_url }} 640w, {{ image.large_url }} 1280w"
    sizes="(max-width: 768px) calc(100vw - 32px), 780px"
    width="{{ image.width }}"
    height="{{ image.height }}"
    alt="{{ image.alt_text }}"
    loading="lazy"
    decoding="async">

srcset 的宽度描述符必须和实际文件宽度相符，sizes 应反映页面中图片可能占据的 CSS 宽度。正文图片通常适合懒加载，首屏封面则根据 LCP 候选和实际请求顺序决定。不要为了追求 Lighthouse 分数而盲目预加载所有图片。

响应式图片的 srcset、sizes 和 Bootstrap 容器关系，可以继续阅读站内的响应式图片实践；更基础的图片加载策略见HTML 图片加载优化。这些文章讨论的是资源交付细节，本文则把它们放回 LCP 和 CLS 的测量流程中。

给正文媒体和表格设边界

Markdown 转 HTML 后，图片可能出现在 <p>、figure 或 picture 内。正文媒体需要明确回到文档流，并在窄屏内缩放；表格则应该允许横向滚动，而不是把整页撑出视口：

.post-content figure,
.post-content picture {
    display: block;
    width: 100%;
    max-width: 100%;
    margin: 1.75rem 0;
}

.post-content img {
    display: block;
    width: auto;
    max-width: 100%;
    height: auto;
    margin: 0 auto;
}

.post-content table {
    display: block;
    max-width: 100%;
    overflow-x: auto;
}

封面图如果确实需要统一裁切，可以在独立容器上使用 aspect-ratio 和 object-fit: cover；正文图片不要套用封面的 16:9 规则，否则会截断图表或截图。页面出现图片与字体重叠时，先检查 float、绝对定位、图片父容器高度和重复 CSS 规则，再判断文件是否损坏。

字体加载怎样影响 LCP 和 CLS

先确认是否真的需要网络字体

技术博客正文通常可以先使用系统字体栈，避免为了少量字形引入大字体文件。若品牌标题确实需要自有字体，应先测量字体文件大小、请求开始时间、字体覆盖范围和 fallback 的行高差异。字体请求慢会延迟文字绘制；fallback 和最终字体的字宽不同，则可能让标题换行并产生 CLS。

.post-content {
    font-family:
        -apple-system, BlinkMacSystemFont, "Segoe UI",
        "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", sans-serif;
}

@font-face {
    font-family: "BlogSans";
    src: url("/static/fonts/blog-sans.woff2") format("woff2");
    font-display: swap;
}

font-display: swap 能让回退字体先显示，但不能自动消除字体切换造成的位移。如果确实有明显变化，再根据字体度量使用 size-adjust、ascent-override、descent-override 和 line-gap-override 做校准，并在目标浏览器上复测。没有证据时不要给每个字体文件加 preload，因为它可能和 LCP 图片争抢首屏带宽。

检查 CSS 和脚本是否阻塞首屏

关键 CSS 应覆盖首屏所需的布局规则，非首屏脚本可以使用 defer 或在交互需要时加载。Django 的静态文件部署、缓存和压缩策略应统一管理；不要只在模板里拼接随机参数来掩盖未更新的静态文件。可参考 Django 部署后的日志排查与性能监控 和 网站性能优化实战 建立发布后的验证记录。

<link rel="stylesheet" href="{% static 'css/style.css' %}?v={{ static_version }}">
<script src="{% static 'js/article.js' %}" defer></script>

生产环境更适合使用带内容指纹的静态文件名或由构建工具生成版本映射。版本更新后，旧缓存可以继续服务旧文件，新页面则请求新的 URL；这比依赖用户手动清缓存更可靠。

INP 与文章页脚本的回归检查

目录、分享和评论功能不需要在页面加载时完成大量工作。事件处理器先给按钮一个可见状态，再执行可拆分的任务；复制链接失败时要提供明确的回退提示，评论表单不存在时不要绑定事件：

document.addEventListener("DOMContentLoaded", () => {
  const commentForm = document.querySelector("#main-comment-form");
  const cancelReply = document.querySelector("#cancel-reply");
  if (!commentForm || !cancelReply) return;

  // 只有在表单存在时才初始化回复逻辑。
  cancelReply.addEventListener("click", () => {
    commentForm.reset();
  });
});

不要在滚动事件中反复读取布局后立即写入样式，也不要把整篇文章重新渲染来切换目录状态。复杂统计和非首屏组件应延后初始化，并在开发者工具的 Performance 面板中确认长任务来源。

用 Playwright 做一条轻量回归检查

性能优化需要防止回归。先安装 Playwright 及 Chromium 浏览器：pip install playwright、playwright install chromium。下面的脚本不生成虚假的 Core Web Vitals 分数，只检查文章图片是否能解码、是否有尺寸、是否横向溢出；真正的 LCP、CLS 和 INP 仍应由 Lighthouse 或真实用户数据评估：

from playwright.sync_api import sync_playwright


URL = "https://blog.zenleak.cn/post/304/"

with sync_playwright() as playwright:
    browser = playwright.chromium.launch()
    page = browser.new_page(viewport={"width": 390, "height": 844})
    page.goto(URL, wait_until="domcontentloaded")
    page.locator("article").wait_for()

    problems = page.locator("article img").evaluate_all(
        """images => images.map(image => ({
            src: image.currentSrc || image.src,
            complete: image.complete,
            naturalWidth: image.naturalWidth,
            width: image.getAttribute('width'),
            height: image.getAttribute('height'),
            overflow: image.getBoundingClientRect().right > window.innerWidth + 1,
        })).filter(item => !item.complete || !item.naturalWidth || item.overflow)"""
    )
    assert not problems, problems
    assert page.locator("body").evaluate(
        "body => body.scrollWidth <= window.innerWidth + 1"
    )
    browser.close()

如果页面包含需要登录才能看到的评论或后台组件，应分别测试匿名和登录状态。截图发现的遮挡问题要结合元素矩形和滚动位置判断：固定的回到顶部按钮、悬浮提示和底部 Cookie 条都可能盖住正文，但它们和图片自身的尺寸问题不是同一类故障。

发布前后的检查顺序

可以把检查拆成四个阶段，减少“改了一个 CSS 就重新猜分数”的来回过程：

1. 发布前：确认标题、摘要、canonical、图片 alt、width/height 和站内链接；可使用 Django SEO 发布前检查 的流程。
2. 实验室基线：固定 URL、视口、测试次数和 Lighthouse 版本，保存移动端和桌面端 JSON。
3. 修复与回归：先处理 LCP 候选和阻塞请求，再处理图片/字体造成的 CLS，最后检查交互长任务；用 Playwright 抽查窄屏和桌面布局。
4. 上线观察：记录部署时间和版本，观察服务器日志、真实用户指标和搜索平台变化。访问分析可以参考 Django 访问分析后台设计；性能工具接收报告不等于搜索引擎已经收录或排名提升。

常见问题

Lighthouse 分数高，为什么用户仍然说慢？

实验室测试的设备和网络是模拟的，用户可能使用更慢的手机、拥挤的移动网络、不同地区的 CDN 节点或已经过期的缓存。先对比真实用户分位数，再检查页面是否存在只在登录态、特定地区或特定交互后出现的内容。

封面图应该一直使用 loading="lazy" 吗？

不应该一概而论。首屏封面可能是 LCP 候选，懒加载会推迟请求；文章末尾的延伸阅读图片则通常适合懒加载。用 Lighthouse 的 LCP 元素和 Network 请求顺序确认，而不是根据图片类型猜测。

调整 Core Web Vitals 会保证收录或排名吗？

不会。性能是页面体验和可访问性的一部分，收录还涉及可抓取性、内容质量、重复页面、内部链接和搜索引擎自己的系统。性能改动应和内容、结构化数据及搜索数据分开记录，避免把相关变化误判成因果关系。

结语

高质量的性能优化不是把一个分数刷到更高，而是能回答三个问题：哪个元素或任务造成了问题，修复后哪个信号发生了变化，真实访问者是否也受益。Django 文章页可以从正确的图片尺寸、稳定的媒体容器、克制的字体加载和可回归的脚本开始，再结合 Lighthouse 与真实用户数据持续验证。

参考资料：

• Web Vitals 指标概览
• Largest Contentful Paint
• Cumulative Layout Shift
• Interaction to Next Paint
• Chrome Lighthouse 文档
• PageSpeed Insights
• Django 静态文件部署