企业官网建设流程全解析

先统一优化的通用思路：

先定位问题，再分析根因；根据具体场景选择当前最合适的方案；实施后量化验证；最后持续监控。

前端面试官：怎么进行站点内的图片性能优化？

面试者真正应该说出口的答案

我不会一上来就说压缩图片，而是先通过数据定位图片性能的具体瓶颈，比如图片太大、尺寸不匹配、加载时机不合理，还是传输链路有问题，然后针对根因选择当前最合适的方案，最后通过 LCP、图片加载耗时、首屏图片流量等指标验证优化效果，并持续监控防止回退。

面试官继续追问后的展开

1. 第一步不是优化，而是先确定到底哪里有问题

首先要明确性能目标。比如用户反馈：

“首页图片加载很慢。”

这句话其实还不够具体，需要继续定位：

首页图片慢 │ ├── 图片文件太大？ ├── 图片尺寸太大？ ├── 图片格式不合适？ ├── 请求发起太晚？ ├── 请求数量太多？ ├── CDN 响应慢？ ├── CDN 没命中？ ├── 网络传输慢？ ├── 图片解码成本高？ └── 加载了本来不需要加载的图片？

可以通过：

• Chrome DevTools Network
• Performance
• Lighthouse
• Web Vitals
• 真实用户监控 RUM
• CDN 日志和监控

去定位。

例如发现：

LCP：4.2s LCP 元素： Hero 图片 Hero 图片： 2.8MB 图片请求： 1.8s 实际展示尺寸： 750 × 400 图片原始尺寸： 3000 × 1600

这时候才能判断：

真正的问题不是“图片技术不好”，而是用户实际只需要 750px 左右的图片，却下载了 3000px 的大图。

2. 如果问题是图片文件太大

先看三个东西：

文件大小 图片尺寸 图片格式

例如：

3000 × 2000 2MB JPEG

但页面实际上只展示：

750 × 500

这时候可以：

压缩

降低图片质量，减少文件体积。

但不是无限压缩，而是在：

视觉质量和文件大小之间找合适的平衡。

使用合适的图片格式

常见情况下可以考虑：

照片、复杂图片 ↓ JPEG / WebP / AVIF 需要透明 ↓ PNG / WebP / AVIF 图标、Logo、矢量图 ↓ SVG

现代浏览器环境下，可以优先考虑 WebP、AVIF 等现代格式，但不能简单认为：

“AVIF 一定比 WebP 好。”

还要考虑：

• 浏览器兼容性
• 编码成本
• 图片处理链路
• 视觉质量
• 实际文件大小
• 业务改造成本

所以最终还是回到：

根据当前项目选择合适的方案，而不是追求理论上最先进的技术。

3. 如果问题是图片尺寸远大于实际展示尺寸

这是很常见的问题。

例如：

手机屏幕 ↓ 实际展示 375px 但是下载： ↓ 1920px 图片

这种情况下，即使图片压缩得很好，仍然可能存在大量无效数据。

可以使用响应式图片：

<imgsrcset="image-400.webp 400w, image-800.webp 800w, image-1600.webp 1600w"sizes="100vw"alt="">

浏览器会根据实际展示尺寸、设备像素比等条件选择合适资源。

也可以把这件事情交给 CDN 图片服务：

前端请求 ↓ CDN ↓ 根据 width / quality / format ↓ 动态处理图片 ↓ 返回合适资源

这样业务侧不需要提前准备大量尺寸的图片。

4. 如果问题是图片加载得太早

比如首页有：

50 张商品图片

结果页面刚打开：

50 张图片全部发起请求

这时候问题就不是图片大小，而是：

很多图片其实当前根本不需要加载。

可以使用懒加载。

例如：

<imgsrc="/product.webp"loading="lazy"alt="">

或者需要更精细控制时：

constobserver=newIntersectionObserver(entries=>{entries.forEach(entry=>{if(!entry.isIntersecting)return;constimg=entry.target;img.src=img.dataset.src;observer.unobserve(img);});});

核心思想：

页面加载 ↓ 只加载当前需要的图片 ↓ 用户接近图片 ↓ 提前开始加载

5. 为什么不等图片真正进入视口再加载？

因为可能已经晚了。例如：

图片进入视口 ↓ 开始请求 ↓ DNS TCP / TLS HTTP 下载 解码 绘制 ↓ 用户才看到图片

用户就可能看到：

空白 ↓ 突然出现图片

所以实际项目通常会设置一定的预加载距离。例如：

预加载区域 ┌──────────────────────┐ │ 提前开始加载图片 │ ├──────────────────────┤ │ │ │ 当前视口 │ │ │ └──────────────────────┘

IntersectionObserver可以通过rootMargin实现类似效果。

例如：

constobserver=newIntersectionObserver(callback,{rootMargin:'500px'});

意思可以理解为：

图片还没真正进入视口，但已经接近视口了，就提前加载。

具体阈值不是固定答案，需要根据：

• 图片大小
• 用户滚动速度
• 网络环境
• CDN 延迟
• 页面结构

实际测试。

6. 但是不是所有图片都应该懒加载？

不是。这是图片优化里很容易被继续追问的问题。例如首屏 Hero 图片：

页面最重要的图片 ↓ 可能就是 LCP 元素

如果把它：

loading="lazy"

反而可能让 LCP 变慢。所以应该区分：

关键图片 ↓ 优先加载 非关键图片 ↓ 延迟加载

对于关键图片，可以考虑：

<imgsrc="/hero.webp"fetchpriority="high"alt="">

必要时还可以使用 preload。所以真正的原则不是：

“全部图片懒加载。”

而是：

根据图片对当前页面体验的重要程度决定加载优先级。

7. 如果问题是首屏关键图片加载得太晚

这时候就要关注：

资源什么时候开始请求

而不是继续压缩图片。例如：

HTML ↓ 发现 CSS ↓ 发现 JS ↓ 执行 JS ↓ 最后才发现 Hero 图片 ↓ 图片开始下载

那图片请求就可能太晚。可以根据实际情况使用：

<linkrel="preload"as="image"href="/hero.webp"/>

或者：

<imgsrc="/hero.webp"fetchpriority="high"alt=""/>

但这里同样不能滥用。

因为：

preload 和 high priority 都是在抢有限的网络资源。

如果页面同时给大量资源设置高优先级，反而可能互相竞争。所以还是要根据实际瓶颈选择。

8. 如果问题是图片请求数量太多

这时候不能简单地说：

“把图片合并。”

要看图片是什么。

例如：

大量小图标

历史上可以使用 Sprite：

icon1 icon2 icon3 icon4 ↓ 一张 Sprite

减少请求数量。

但现代 HTTP/2、HTTP/3 下，请求数量本身已经不像 HTTP/1.1 时代那么敏感，所以不能简单认为：

“请求越少越好。”

而且把大量图片合成一张大图，也可能造成：

• 下载无用区域
• 缓存粒度变差
• 图片更新导致整个资源失效

所以是否合并，需要结合实际请求量、资源大小、协议和缓存情况判断。

对于现代项目，图标更常见的方案还包括：

SVG SVG Sprite Icon Font

具体选择还是看业务。

9. 如果问题是图片传输速度慢

这时候就要看传输链路。

例如：

用户 ↓ CDN ↓ 源站 ↓ 图片服务

可以重点检查：

• CDN 是否接入
• CDN 节点距离用户是否合理
• CDN 命中率
• 缓存策略
• 源站响应速度
• 图片是否每次都回源
• 图片是否需要实时处理

典型链路：

用户请求图片 ↓ CDN │ ┌──┴──┐ │ │ 命中 未命中 │ │ ↓ ↓ 返回 源站 ↓ 图片 ↓ CDN缓存 ↓ 用户

CDN 的核心价值不是“把图片压缩了”，而主要是：

让用户从距离更近的边缘节点获取资源，并利用缓存减少回源。

10. CDN 图片处理也可以工程化

大型站点通常不会要求开发人员手工生成：

image-400.jpg image-800.jpg image-1200.jpg image-1600.jpg

而是：

原图 ↓ 对象存储 ↓ CDN / 图片处理服务 ↓ 动态裁剪 ↓ 动态压缩 ↓ 动态格式转换 ↓ 返回

例如：

/product/123.jpg

根据参数生成：

/product/123.jpg?w=400 /product/123.jpg?w=800 /product/123.jpg?w=1200

甚至根据浏览器能力选择：

AVIF ↓ WebP ↓ JPEG

这样可以把图片优化从：

人工操作

变成：

工程化处理。

11. 图片缓存也要考虑

如果用户访问同一张图片：

第一次： 请求 CDN 第二次： 浏览器缓存

就没必要再次下载。所以需要合理利用：

Cache-Control ETag Last-Modified CDN Cache

对于带内容哈希的静态图片，例如：

avatar.a83f92.webp

可以设置较长缓存时间。因为文件内容发生变化时：

avatar.a83f92.webp ↓ avatar.b72c31.webp

URL 发生变化，天然可以解决缓存更新问题。

12. 还要关注图片的解码和渲染成本

图片性能不只是：

下载速度

还包括：

下载 ↓ 解码 ↓ 布局 ↓ 绘制

例如：

4000 × 4000

即使经过压缩：

文件只有 300KB

也不代表浏览器处理它的成本就一定低。

因为：

文件大小和图片解码后的像素规模不是一回事。

所以如果实际只需要：

400 × 400

最好不要让浏览器下载并解码：

4000 × 4000

这也是为什么响应式图片和图片尺寸控制非常重要。

13. 如果是超长图片列表怎么办？

这时候就要区分两个问题。

图片懒加载

解决：

图片什么时候下载。

虚拟滚动

解决：

页面同时保留多少 DOM。

例如：

10,000 个商品 ↓ 虚拟滚动 ↓ DOM 只保留几十个

同时：

当前附近的商品 ↓ 图片懒加载

两者可以结合：

10,000 条数据 ↓ ┌──────┴──────┐ ↓ ↓ 虚拟滚动 图片懒加载 ↓ ↓ 控制 DOM 数量 控制图片下载

所以两者不是替代关系。一句话：

懒加载解决“什么时候加载”，虚拟滚动解决“同时渲染多少”。

14. 图片格式降级怎么做？

如果需要兼容不同浏览器，可以使用<picture>：

<picture><sourcesrcset="/image.avif"type="image/avif"/><sourcesrcset="/image.webp"type="image/webp"/><imgsrc="/image.jpg"alt=""/></picture>

可以理解为：

支持 AVIF ↓ AVIF 否则支持 WebP ↓ WebP 否则 ↓ JPEG

所以面试里最好不要简单说：

“WebP 自动降级。”

更准确的是：

通过<picture>、srcset或 CDN 等方式，根据浏览器能力选择合适的图片格式和资源。

15. 最后一定要量化优化结果

这一步非常重要。不能说：

“优化以后感觉快了很多。”

应该拿数据证明。例如：

优化前 优化后 LCP 4.2s 2.3s 首屏图片流量 3.5MB 1.1MB 图片平均大小 1.2MB 380KB 图片请求耗时 1.8s 700ms

然后再看真实用户数据：

P50 P75 P95

尤其是核心 Web Vitals 这类指标，最好结合真实用户监控，而不是只看自己电脑上的 Lighthouse。

16. 还要考虑优化成本和副作用

这里才是真正体现工程经验的地方。比如：

“我们把所有图片都改成 AVIF。”

可能理论上图片更小，但：

• 图片处理链路需要改造
• 编码成本增加
• 兼容策略需要调整
• 现有 CDN 能不能处理？
• 实际收益到底有多少？

如果最终：

AVIF： 投入 10 人日 LCP 提升 50ms WebP + CDN： 投入 1 人日 LCP 提升 400ms

那当前项目显然应该优先：

WebP + CDN。

所以这里的“最优方案”不是：

性能指标理论上的最优。

而是：

结合当前业务目标、收益、开发成本、技术约束和风险之后，当前最合适的方案。

17. 最终形成一个完整的性能优化闭环

性能目标 ↓ 采集数据 ↓ 定位痛点 ↓ 分析根因 ↓ 评估可选方案 ↓ 选择当前最合适的方案 ↓ 实施 ↓ 数据验证 ↓ 上线监控 ↓ 防止性能回退 │ └────→ 再次分析

所以我认为这道题真正考的并不是：

“你知道多少图片优化手段？”

而是：

你能不能从真实的性能问题出发，定位瓶颈、分析根因、选择方案，并用数据证明方案有效。

这才真正体现出性能优化的工程思维。