前端性能优化，主要分两个大方向：资源加载优化 和 代码优化。
资源加载优化
资源加载优化，大致又分为三种：
资源压缩；
延迟加载；
减少 HTTP 请求。在 HTTP/1 时代，请求效率不高，需要排队，会造成堵塞，减少 HTTP 请求还是非常有效的。但已广泛普及的 HTTP/2 后使用了多路复用，可以充分利用带宽，不用考虑这个。甚至说拆成更多的资源，有利于做更细粒度的缓存。
下面我们看看具体都有哪些方法。
使用 HTTP/2
HTTP/2 的主要改进就在于提高加载资源的速度。
它使用了头部压缩，通过特有的 HPACK 算法，让请求头做了极致的压缩。
此外使用了多路复用，让请求产生流的特性，可以同时发送多个请求，充分利用带宽；
懒加载
一些暂时不用到的资源先不急着加载，在用到的时候再加载，目的是减少请求。
懒加载有很多种，有图片懒加载，滚动到图片位置，才开始加载图片（知乎使用了这个，另外 NextJS 框架的 Image 组件也支持懒加载）。
还有 JS 模块的懒加载，像 ES6 的动态 import，这个在 Webpack 有支持。
还有组件的懒加载：
{visible && }
开启 gzip
我们可以开启 Web Server 的 gzip 压缩，对资源进行内容压缩再传输。
此外还有压缩率更好的 br 可以选择。
《前端性能优化：启用 gzip》
图片使用 WebP
WebP 是 Google 推出的拥有极其优秀压缩比的图片格式。
我们可以判断客户端是否支持 WebP，如果支持则使用 WebP 来替代 jpg，减少图片大小。
空闲时加载之后可能需要访问的资源
加载当前页面资源的时候，调低某个暂时不用到的资源的下载优先级，在空闲的时候再加载，并将其缓存起来。
当用户从当前页面跳转到另一个页面，如果该页面用到了该资源，就可以直接使用缓存了。
关于资源加载管理的讲解，可以看我的这篇文章：
《管理好资源的加载，你需要了解的 preload、prefetch、preconnect 以及 DNS-prefetch》
base64 内联
一些比较小的资源，比如一个不大的图标图片，可以考虑转换成 base64 格式，内嵌到 HTML 中。这样做的目的是减少 HTTP 请求数量。
下面是 webpack 的 url-loader 配置，将小于 8192 字节的图片转换为 base64。
{
test: /.(png|jpg|gif)$/i,
use: [
{
loader: 'url-loader',
options: {
limit: 8192,
},
},
],
},
看看大佬都是怎么回答这个问题的
看看大佬都是怎么回答这个问题的
