前端优化

什么是 Web Vitals？

Web Vitals（网页核心体验指标）是 Google 提出的一组 衡量网页用户体验质量 的核心指标。主要包含以下三项核心指标，分别反映 加载速度、交互响应、视觉稳定性：

1. LCP（Largest Contentful Paint，最大内容绘制）: 衡量页面主要内容（例如：首屏大图、主标题、文章封面等）何时可见，反映 加载速度。
2. FID（First Input Delay，首次输入延迟）: 测量用户第一次与页面交互（如点击按钮、打开菜单）到浏览器实际响应该交互之间的响应延迟，反映 交互响应。
3. CLS（Cumulative Layout Shift，累积布局偏移）: 衡量页面加载过程中元素是否发生意外位移（常见原因图片未设尺寸、异步插入广告、字体闪烁等），反映 视觉稳定性。

CAUTION

注意：从 Chrome 119 起，FID 已被 INP（Interaction to Next Paint，交互至下一次绘制） 逐步取代，作为新的交互性指标。INP 测量网页生命周期内所有用户交互（点击、触摸、键盘输入）的响应时间，即从交互触发到浏览器绘制下一帧之间的完整耗时。相较于 FID，INP 更全面，因为前者只关注首次交互，而后者关注长期交互。

此外，Google 还推荐关注其他辅助指标，如：

• FP （First Paint，首次绘制）: 页面从白屏到第一个像素变化的时间
• FCP（First Contentful Paint，首次内容绘制）: 第一个文本或图片渲染出来的时间
• TTFB（Time to First Byte）：反映服务器响应速度

针对不同的场景，可以重点关注不同的指标。例如 TTFB & FCP 常用来定位 LCP 慢是后端慢还是前端慢。

优化 Web Vitals 不仅能提升用户体验，还能提高网站在 Google 搜索中的排名。开发者可通过 Chrome DevTools、PageSpeed Insights、Lighthouse、Google Search Console 等工具检测和持续监控这些指标。

什么是页面布局优化？

通过对网页中元素的结构、排列方式、视觉层次和交互设计进行合理调整，提升用户体验、内容可读性、响应式适配能力以及页面性能的过程。它不仅关注“看起来是否美观”，更强调“用户能否高效获取信息、顺畅操作”。

页面布局优化的主要目标有哪些？

• 提升用户体验（UX），让用户快速找到关键内容
• 增强可读性和可访问性，降低认知负担
• 实现响应式设计，适配手机、平板、桌面等不同设备
• 减少布局偏移（CLS），提升加载稳定性
• 支持 SEO 优化，帮助搜索引擎理解页面结构
• 提高转化率，比如引导用户完成注册、购买等操作

常见的页面布局优化方法有哪些？

• 使用清晰的视觉层次（如标题大、正文小，重点内容加粗或高亮）；
• 合理使用留白，避免元素过于拥挤；
• 采用网格系统或弹性布局（如 CSS Grid、Flexbox）实现整齐对齐；
• 遵循响应式设计原则，确保多设备兼容；
• 为图片、iframe 等元素预设尺寸，防止加载时发生布局偏移；
• 将核心内容放在首屏可见区域（Above the Fold）；
• 使用语义化 HTML 标签，提升可访问性和 SEO。

什么是 CLS？它和页面布局有什么关系？

CLS（Cumulative Layout Shift，累积布局偏移）是衡量页面加载过程中元素意外移动程度的指标，属于 Google 核心 Web 指标之一。

如果页面中的图片、广告或按钮在加载后突然“跳动”，就会导致 CLS 值升高，影响用户体验甚至 SEO 排名。

因此，良好的页面布局必须尽量避免这种偏移，比如为图片设置宽高、预留占位空间等。

如何评估一个前端应用的性能瓶颈？如何进行优化？

Lighthouse…

如何定位和优化首屏渲染性能瓶颈？

为了定位性能问题，可以用 Lighthouse 跑个分，它会指出问题，并给出一些优化意见。也可以用 Chrome 的 Performance 面板 录个火焰图，看看主线程里哪些任务耗时特别长。比如发现某个 JavaScript 执行块占用了 500ms 以上，可能就需要拆分代码或者做懒加载。另外用 Network 面板 检查资源加载顺序，如果首屏需要的 CSS 或 JS 被不必要的大文件阻塞了，可能需要做代码分割或者内联关键资源。

优化的话，常见的策略有几个方向：比如 资源压缩，用 WebP 代替 JPEG，用 Tree Shaking 减少 JavaScript 体积；预加载 关键资源，比如用 <link rel="preload"> 提前加载字体或关键 JS；服务端渲染（SSR） 能提前让首屏内容更快到达用户端，不过得注意服务器压力；还有 懒加载 非首屏的图片或组件，比如用户下滑时再加载评论区的内容。

有时候问题可能出在第三方脚本上，比如统计代码或广告 SDK，这时候可以用 异步加载 或者 延迟初始化，避免它们阻塞主线程。另外，CSS 方面如果发现大量重排重绘，可能需要减少复杂选择器，或者用 transform 代替直接修改宽高。

浏览器环境下，相较于 Native 环境，卡顿的原因是什么？如何优化？

总体上说，相较于直接运行在操作系统（或者广义上来说，甚至没有操作系统的裸机）上的原生应用，浏览器环境下的应用对 硬件资源的利用率 更低。此外，浏览器环境存在的诸多限制，也会对性能产生影响。这些对性能的影响，最终以卡顿的形式表现出来。

具体而言：

JavaScript 执行性能限制

• 解释执行：JavaScript 是解释型语言，而 Native 代码往往是编译型语言编写的，执行效率上前者低于后者
• 单线程模型：主线程需要处理 UI 渲染、事件响应和 JavaScript 执行，容易阻塞
• 垃圾回收：GC 过程会暂停 JavaScript 执行，造成卡顿

渲染管线开销

• DOM 操作成本：频繁的 DOM 查询、修改会触发重排(reflow)和重绘(repaint)
• CSS 计算：复杂的 CSS 选择器和样式计算消耗性能
• 合成层处理：图层合成、GPU 加速的开销

网络延迟影响

• 资源加载：CSS、JS、图片等资源的网络加载时间
• API 请求：异步数据获取的延迟
• 缓存策略：不当的缓存配置导致重复加载

浏览器架构限制

• 沙箱机制：安全限制带来的性能开销
• 进程间通信：多进程架构的 IPC 成本
• 内存管理：浏览器的内存分配和管理机制

兼容性处理

• Polyfill 开销：为了兼容性添加的代码增加执行成本
• 浏览器差异：不同浏览器引擎的性能差异
• 标准实现：Web 标准的抽象层带来额外开销

资源竞争

• CPU 竞争：与其他标签页、扩展程序竞争 CPU 资源
• 内存限制：浏览器对单个页面的内存使用限制
• GPU 资源：多个页面共享 GPU 资源

优化建议：

• 使用 Web Workers 处理计算密集型任务
• 优化 DOM 操作，减少重排重绘
• 合理使用缓存和预加载策略
• 采用虚拟滚动等技术优化大数据渲染
• 使用性能分析工具定位瓶颈

介绍一下浏览器的 Performace 界面

Performance 面板是浏览器用来分析网页性能的核心工具，主要做三件事：

1. 找卡顿：看哪里动画掉帧、操作响应慢。
2. 看加载：分析页面从打开到完全显示哪里慢。
3. 查瓶颈：找到耗时的代码和耗资源的渲染操作。

简单使用三步：

1. 录制：点“录制”按钮，然后操作页面（如滚动、点击）。
2. 停止：操作完点“停止”。
3. 分析：主要看两个地方：
   • CPU/FPS 图表：找 CPU 占用高或帧率（FPS）掉下去的时间段。
   • 主线程火焰图 (Main)：在刚才的时间段里，找又长又粗的横条。这些就是导致卡顿的“元凶”，点开能看到具体是哪个函数或操作耗时。

核心就一点：在主线程火焰图里找到并分析那些“长任务”。

如何优化首屏加载性能？

1. 压缩资源： JS/CSS 最小化，启用 Gzip/Brotli。
2. 优化图片： 使用 WebP/AVIF，调整尺寸，懒加载非首屏图片。
3. 代码分割： 按路由/组件拆分代码，懒加载。
4. 缓存策略： 为静态资源设置长期缓存。
5. 关键 CSS： 内联首屏所需 CSS。
6. 脚本策略： 使用 defer/async 避免 JS 阻塞。
7. 预加载： 使用 preload 提前加载关键字体、图片等。
8. 预连接： 对重要第三方源使用 preconnect/dns-prefetch。
9. Web 字体： 使用 font-display: swap，考虑子集化。
10. 考虑 SSR： 如果对 FCP 要求极高，评估引入 SSR。
11. 使用 CDN： 加速静态资源分发。
12. 分析监控： 定期用 Lighthouse 检测，线上监控 Core Web Vitals。

如何理解 CDN？实现原理是什么？

CDN（Content Delivery Network 或 Content Distribution Network），即 内容分发网络。它不是一个单独的服务器，而是由遍布全球的无数个缓存节点（边缘服务器）组成的网络系统。其核心目的是：将源站的内容（如网页、图片、视频等）缓存到离用户更近的节点上，使用户能够以更快的速度和更稳定的方式获取所需内容。

CDN 的优势：

• 加速网站访问，降低延迟：物理距离是网络延迟的主要原因。CDN 让用户无需千里迢迢访问源站，而是“就近取材”，极大缩短了数据传输时间。
• 减轻源站服务器压力：绝大部分用户请求都由边缘节点处理，只有必要请求（如缓存过期、动态内容）才会回源，避免了源站被海量流量冲垮。
• 应对高并发和流量峰值：CDN 网络具有强大的带宽和负载均衡能力，能轻松应对“双十一”、热门新闻发布、病毒视频传播等瞬间的高流量冲击。
• 提高网站的可用性和稳定性：即使某个 CDN 节点或甚至源站出现故障，其他健康节点仍然可以继续为用户提供服务（比如返回已缓存的旧内容），增强了业务的鲁棒性。
• 增强安全性：CDN 可以作为一道屏障，帮助抵御 DDoS 攻击（通过其庞大的带宽和分布式结构吸收并稀释攻击流量）、隐藏源站 IP、并提供 WAF（Web 应用防火墙）等功能。

CDN 的工作主要依赖于 智能调度 和 缓存机制。

当用户访问一个接入了 CDN 的网站（例如 www.example.com/image.jpg）时，并不是直接请求源站，而是通过一套精密的调度系统被引导到最佳的 CDN 节点。这个过程对用户完全透明，主要通过 DNS 解析来实现。

用户请求到达 CDN 节点后，节点如何响应用户请求，具体流程如下：

1. 缓存命中（Cache Hit）：CDN 节点检查自己是否已经缓存了用户请求的 image.jpg 这个文件，并且缓存没有过期。如果是：节点直接将该文件返回给用户。速度极快，这就是使用 CDN 的效果。
2. 缓存未命中/过期（Cache Miss）：如果节点没有这个文件，或者文件已经过期（根据源站设置的缓存规则），节点会做一件事：回源（Pull）。
3. 回源获取：CDN 节点会向网站的源站服务器发起请求，获取最新的 image.jpg 文件。
4. 缓存并返回：节点从源站拿到文件后，会在自己的本地存储一份（根据缓存规则设置有效期），然后将文件返回给用户。下一次再有用户来请求同一个文件，就可以直接提供了。