资讯文章文章 · ARTICLE

链接多的页面怎么提速：导航站 Core Web Vitals 优化清单

2026-10-22 约 2,337 字预计阅读 6 分钟 yiyunkj

导航站是天生「重图片、重链接」的页面：几十个 favicon、一堆截图、上百个 <a> 标签。这类页面的性能通常很难看，LCP 三四秒是常态。

而移动端的 LCP 超过 2.5 秒，排名是实打实会吃亏的。这篇文章讲怎么把这类页面拉进合格线，按收益从高到低排。

一、先测出真实的瓶颈

不要凭感觉优化。先拿三个数据：

LCP 元素是什么——在 Lighthouse 报告里点开「最大内容绘制」，它会告诉你具体是哪个元素。导航站通常是首屏的某个图标或标题图。
CLS 来自哪里——导航站的 CLS 问题多数来自图片没有预设宽高，加载完把内容顶下去。
INP 卡在哪——通常是首屏同时加载几十个图标，主线程被占满。

测的时候用移动端模拟 + 4G 节流，不要用桌面端直连。桌面端的分数没有参考价值。

二、图标：最大的问题源

一个分类页 60 个条目，60 个 favicon。如果每个都是原始 PNG，一个 5-20KB，总共 300KB-1MB，而且全部阻塞首屏渲染。

做法一：统一转成小尺寸 WebP 或 SVG

favicon 显示尺寸通常 16-32px，导出 48px 或 64px 的 WebP 就够（2 倍屏适配）
单个控制在 2KB 以内
纯色/几何型 logo 优先用 SVG，通常 1KB 以下

做法二：按需加载，不要一次全加载

首屏只加载可见区域的图标，其余用 loading="lazy"。注意：LCP 元素所在的那张图不能 lazy，否则会拖慢 LCP。

做法三：本地托管，不要直连对方域名

直接引用 https://其他站.com/favicon.ico 有三个问题：DNS 查询多、对方可能很慢、对方可能挂掉。全部下载到自己服务器，统一处理尺寸和格式。这也是死链治理的一部分。

三、图片：预设宽高，消灭 CLS

导航站的截图和 banner 是 CLS 的主要来源。

<img src="cover.webp" width="320" height="180"
     alt="描述" loading="lazy" decoding="async">

三个属性都要有：

width / height：让浏览器提前算出占位空间，图片加载完不会顶动内容
loading="lazy"：非首屏图片延迟加载
decoding="async"：不阻塞渲染

另外，CSS 里要用 max-width: 100%; height: auto; 配合，否则预设宽高在响应式布局下会变形。

格式与压缩

类型	建议
截图/照片	WebP，质量 75-80
图标/logo	SVG 优先，其次 WebP 64px
渐变/纯色背景	CSS 实现，不要用图
装饰性图片	能删就删

四、链接列表：别让 DOM 拖慢渲染

一个分类页 200 个链接、每个链接里还有图标和两行文字，DOM 节点轻松过 3000。移动端渲染这个量会明显卡。

分页而不是无限滚动

无限滚动对 SEO 不友好（内容不在 DOM 里就抓不到），对性能也不友好（越滚越卡）。一页 30-50 条，用真实的分页链接。

减少嵌套层级

一个条目用三层 div 能表达的，不要用六层。列表类页面每个多余的包裹层都会乘以条目数。

<!-- 不好：5 层 -->
<div class="item"><div class="inner"><div class="wrap"><div class="left">...</div></div></div></div>

<!-- 好：2 层 -->
<li class="item"><a href="..."><img><span>名称</span></a></li>

五、CSS 与 JS：能省的全省

CSS

首屏关键 CSS 内联，其余异步加载
去掉未使用的样式（很多主题塞了整套 UI 框架，实际用了不到 10%）
不要用 @import，它会串行阻塞
字体：中文字体文件极大，用 font-display: swap，或者干脆用系统字体

JS

统计代码、客服悬浮窗、广告脚本，全部加 defer 或 async
广告位如果是同步脚本，它会成为 LCP 杀手。改成异步插入，并预留固定高度避免 CLS
首屏不需要的交互（搜索建议、下拉菜单）延迟到 DOMContentLoaded 之后初始化

六、服务器与传输层

项目	目标	做法
TTFB	< 800ms	页面静态化或加缓存，别每次请求都查库
压缩	开启	Brotli 优先，其次 gzip
HTTP 版本	HTTP/2 或 3	导航站请求数多，多路复用收益明显
CDN	有则用	静态资源（图标、图片、CSS、JS）全部走 CDN
缓存头	长缓存	带 hash 的静态资源设 1 年，HTML 设短缓存

TTFB 这一项经常被忽略，但它是 LCP 的前置。服务器响应 1.5 秒，后面优化得再好，LCP 也进不了 2.5 秒。目录站页面结构简单，非常适合静态化——生成一次，缓存住，TTFB 通常能压到 100ms 以内。

七、一个按收益排序的优化清单

图标本地化 + WebP + 首屏按需加载（收益最大，通常能砍掉 60% 的首屏字节）
页面静态化 / 加缓存（TTFB 从秒级到百毫秒级）
所有图片预设宽高（CLS 直接归零）
广告与统计脚本异步化（LCP 明显改善）
列表分页 + 精简 DOM（INP 改善）
启用 Brotli + HTTP/2 + CDN（整体提速 20%-40%）
去掉未使用的 CSS/JS（收尾，锦上添花）

按这个顺序做，一般两三天能让一个原本 LCP 4 秒的导航站进到 2.5 秒以内。反过来，如果先去折腾「代码分割」「预渲染」这些，收益小得多。

八、优化完要验证什么

Lighthouse 移动端分数（看趋势，不必执着 100 分）
Search Console 的「核心网页指标」报告，需要 28 天数据才能反映，别看当天
实际手机上打开，用秒表感觉一下首屏出现的时间
确认没有因为 loading="lazy" 导致 LCP 元素反而变慢（这是最常见的反向优化）

最后一句：性能优化对导航站的性价比，比大多数站都高。因为这类页面结构简单、优化手段明确、收益可测量。花两天做的效果，可能比写十篇文章带来的排名提升更稳定。