前端性能优化到底怎么做啊!平均 LCP 已经 1.7s 了

[dashsoap97]

领导坚持要看 95 分位数据 要 2.5s 以下 现在 3.2s 怎么办啊各位大佬

[luckyrayyy]

换个网速好的地方给他演示

[zhengfan2016]

上 worker ，把所有能缓存的缓存？

[Torpedo]

如果是 lcp 的话，lcp 一般是看某个元素的加载会触发 lcp 。所以你可以看下你们的页面是哪个元素触发的。

lcp 这个指标是不太准的，毕竟自动选的某个元素。

不过这不是重点。重点是你想想你们领导让你性能优化，那你可以和领导达成一个合理的指标，而不是单纯说领导提的这个指标不合理。

[gaobh]

图片用 wabp ，先压缩到十几 K 就合格，放存储桶套 cdn 完事，这最简单。然后搞图片懒加载。不行让 cursor 鼓捣一下

[dashsoap97]

@Torpedo #3 是的..只是说已经优化无从谈起了 该压缩的都压缩了 现在就是第一个 chunk-app.js 还有 300 多 k

[PainAndLove]

试试 SSR ？

[laikick]

@dashsoap97 #5 做了代码分割了吗? 先看看里面有啥看看能不能拆出来

[ChefIsAwesome]

利用浏览器能同时下好几个资源的特点优化。
把大的 js 包拆成几个，并行下载。
放一部分 js 进 html 里。比方讲页面加载之后，要请求后端拿用户信息，要根据路由取数据，这种逻辑可以写在 html 里。获得的信息存在全局变量的 promise 里，js 加载之后再去读 resolve 的值。这样取数据和下载 js 是并行的，而不是等 js 下载完了再去请求。

[dashsoap97]

@laikick #7 每个 router 都做了 chunk split
@ChefIsAwesome #8 谢谢 可以考虑一下~

[dashsoap97]

@PainAndLove #6 不行 一方面后端不行 另一方面 这还是 vue2

[dashsoap97]

@luckyrayyy #1 不是 这个是接入了一个平台 每次用户访问的 都有记录

[xiaoming1992]

analyzer 分析一下什么东西尺寸最大，看看能不能给它们 lazy 一下，让它们在首屏渲染完成后再加载

[LASockpuppet]

真难优化，一个 h5 页面，客户端容器启动占了 4s ，前端占了 4s ，用户可交互时间直接搞到了 8s

[JeriffCheng]

这个没有必要搞的，99%的网站都过不了这一关，除非网页特别小，全是文字，没有 js

[chaoschick]

把没那么重要的第三方 js 库都移除掉，手动实现

[murmur]

300k 首屏都不满足要求，只能骨架图造假了

[gxt92]

仅供参考 https://github.com/flowforfrank/performance-checklist

[jydeng]

service-worker 先加上，然后阻塞任务治理一下，阻塞接口拆一下就差不多了。

[des]

F12 Performance 分析一下呗，说不定去掉 unload 分数就上去了

[kamilic]

这种屌要求就刻舟求剑，如果 LCP 元素稳定，直接 base64 写死，或者是首屏试图用 inline 的 <script> 标签实现（狗头

[Torpedo]

@dashsoap97 #5 如果初始 api 请求比较固定，可以考虑把初始请求单独放到 html 里请求，和 js 并行加载

[dashsoap97]

@LASockpuppet #13 我理解主要是接口啊
@chaoschick #15 已经删无可删了
@murmur #16 怎么才能再压缩呢?

[dashsoap97]

@kamilic #20 不固定的 依赖接口

[dashsoap97]

@Torpedo #21
@jydeng #18 发现有很多 空的区域 就是什么事儿也没干的情况 不知道为啥

[jydeng]

@dashsoap97 可能是在下载、解析，结合网络看一下。

[xiaofeixiang]

先分析现状，再看达成目标。
LCP 我个人不是最主要的影响因素，最重要的是白屏时间和页面可操作时间，这两个时间短的话，页面的可访问性就有保障，我自己公司的项目做过一些这方面的优化，个人浅见分享一下。
最直观的就是做 SSR 或者 SSG ，vue2 也有 pre-render 相关的处理，可行的话也可以切换到 nuxtjs2 ，基本没有什么门槛。
资源加载方面该先检查服务器配置，gzip 或者 br ，http2 这些配置必须要有， 静态资源 cdn 加速也必不可少，资源根据需求做 cdn 缓存和预热，这个非常非常重要，服务器就是力大砖飞的东西，配置越好，网络越好，体验越好，在这个的基础上，你再去做优化，不然就是屎上雕花，毕竟巧妇难为无米之炊；
工程打包方面来讲，html 也可以预先做 dns 解析和资源缓存方面的优化，打包文件拆分这个很重要，一个资源 300k 我个人觉得有点太大了，我们所有的项目最大的公共包不会超过 150k ，不过在服务器和网络条件好的情况下，这个勉强能够接受，不要把不必要的插件和代码打包到公共文件里面去！举个例子 echart 和 lodash 这种一定是页面用到的地方才加载。不能拆出去的，能走 cdn 的尽量走 cdn ，尽量降低公共包里面无用的代码，ui 库和路由一定要做好按需加载，css 包可以用 purecss 这类的插件把没用到的资源去掉，当然这个得根据项目来调整。所有的 js 和 css 包括 html 都必须压缩！
从页面的方面来讲，所有的图片统一转换成最小的格式，可以通过 cdn 自带的格式转换，也可以通过工程化配置压缩文件体积，页面图片加载尽量做好懒加载。如果是 SSR ，一定要注意 async 和 await 的使用，多个非依赖的请求尽量并行请求。不追求 SEO 的话，能异步加载的模块都走客户端渲染，做好骨架屏能很大程度上提升体验，包括资源加载渲染的时候，可以参考有些项目运行热编译的时候页面有进度条提示。首屏没用到的元素也可以考虑做懒加载，举个我最近优化的 webview 嵌入的 H5 的例子， 我们业务有一个长列表的 collapse ，如果全量渲染，在正常的手机和 pc 上的速度是很正常的，在我们产品嵌入的低性能的安卓设备上页面 loading 时间会超过 10s ，这基本是不可接受的，优化加了列表和 collapse 内容的延迟加载，页面初始只渲染列表，页面 load 完之后会逐步加载 collapse 里面的内容，不影响页面的滚动和操作，优化后基本能保证在低性能设备上的访问速度和高性能设备差距不大。具体需求具体分析，各类框架的推荐写法一定要去看，保持良好的代码编写习惯，尽量不要往项目中堆屎和脑残逻辑
这些是针对首次访问用户的，其他的还有类似 pwa 和本地缓存的东西，可以针对多次访问的用户做优化，不过我感觉做好了资源缓存，这些配置可以根据需求选择性的去做，现在性能优化的文章和分享很多，都可以根据自己的项目需求去参考

[dashsoap97]

@xiaofeixiang #26 非常感谢
@xiaofeixiang #26