项目优化 | leon‘s Blog

type

status

date

slug

summary

📝 前端项目性能优化

来到了一家公司，接手一个新的项目，我是先开始分析这个项目有哪些优点，首先我从俩个角度出发去找，一个是我先访问了线上地址，用performance简单观察他的加载是否存在优化空间,然后采用工具详细的性能分析。注：以下围绕我现在开发的react项目为例，其实不同框架切入的思想和角度都差不多。

性能分析

PageSpeed Insights

https://pagespeed.web.dev/analysis/https-www-tutoreva-com/fjt5p22vkr?hl=zh-cn&form_factor=desktop

用的是这个PageSpeed工具，发现LCP长达七秒，FCP也不尽人意，然后就开始围绕让LCP优化到3秒之内做工作。大概就是几方面，优化服务器响应，优化资源加载，预渲染，加载。观察过一些优秀的网站，首屏很快，都是用了next做服务端预渲染，因为我们拿到是一个开发完的成熟项目，拿next重构当然是不可能的。先展开几个常见的如下：

CDN

所以第一步就是让静态资源上CDN了，上家公司也对这个颇有感触，当初公司要做多语言，就产生了比较大的语言包文件，包括项目文件，给海外的客户用的时候cdn带来的便利就很明显。

附：常见性能分析工具

Google Lighthouse：使用Google Lighthouse分析页面性能，找出LCP时间长的原因。

WebPageTest：使用WebPageTest进行详细的性能分析，找出瓶颈。

浏览器开发者工具：使用浏览器开发者工具（如Chrome DevTools）分析网络请求、渲染性能和内存使用。

优化资源加载

图片

减少图片大小: 常见的，webpack里添加loader来压缩图片image-webpack-loader 但是实践下来总感觉用loader压缩是很有限的，有的只是把大一点转化成base64来存储，减少了图片的请求，还是得用tiny来压缩一下，有钱的公司也会选择直接调用api

减少图片请求：这个可能以前会考虑雪碧图这种方式，但现在应该很少有人提了吧，现在常见就是把icon整合到一个文件里存储，比如前面提到的loader，比如我们现在用的@iconify是从figma上直接拿到文件转化成json，然后配置调用

利用CDN：就是把大一点的图片上传到CDN上

图片懒加载：即用一些工具实现滚动到图片的位置的时候才加载图片，原生自带的有 loading="lazy"，当然还是建议用工具类似于react-lazy-load-image-component这样的，它会判断可视区域快到内容的时候预加载

字体

国内项目：像国内项目，纯中文，作为开发一般不建议项目上传自己定义的特殊字体，可以让那个UI给一套字体显示规则，用用户自己系统的字体。

国外项目：像我们主做美区，是纯英文，就把之前UI给的多个权重的字体，整理成一个wttf文件，用自带权重去做，能减少一部分压力

还是建议让UI出一套字体规范去匹系统字体。

js文件

项目拆分：SplitChunksPlugin

懒加载：React.lazy 和 Suspense 实现懒加载的同时它本身也是一种项目拆分,routerV6的lazy，也可以，我们有的项目也尝试router的lazy其实也不错

css文件

很多时候如果项目不大，我们会忽略css文件，后面会专门整理一期css相关方案。

这里提一下就是我们尝试过减少css文件大小的方式就是用tailwind这种变量式写法，但是由于目前组件社区不是很完善，还是相对开发上受限的。当然也有人会觉得css文件是小了，但是都写到tsx文件里了，还是不太一样的，这里不过多赘述。

预渲染

其实在加载的时候，如果服务端能渲染好静态资源，到客户端继续加载是会快很多，那么对于不是next项目，老的react项目想做预渲染怎么做，这里有个react有个特性是hydrate，也有开源社区做过一些预渲染的plugin和npm包，比如prerender-spa-plugin，但是由于我的项目是想做预渲染来提升seo排名，用这些插件有很多问题没法解决，我就自己写了一个脚本来跑了一个预渲染页面上传上去，缺点就是没法注水，得运维配合服务转发。

前端项目文件优化

上面提到的是对于整个产品，用户看到的层面的优化，也捎带提提项目源文件的优化，从而提升开发效率

后面会专门用一篇文章去总结提升开发效率，先就再研究这个项目的时候发现的一些问题做总结

编译

esbuild-loader

webpack对比过vite，就知道vite编译快的原因一大部分就是esbuild，所以想要优化比较老的webpack的编译速度，就是采用esbuild-loader

缓存

由于项目庞大，之前打包时间就很长，打包时间的大部分都在npm install和各种loader的执行上，如果不用每次打包都从0开始执行的话会快很多。首先可以在loader之前加上cache-loader，这样这个loader执行过一次后的数据会缓存在node_modules/.cache目录下，下次再打包就会利用缓存。

Webpack 缓存

🤗 总结归纳

其实谈性能优化，无非就是看这个项目从输入网址到你看到这个项目上发生了什么这条连路上发生了什么，从而依次优化，这也就是为什么很多公司喜欢考这个八股文。我是围绕我经历过的项目去做的描述，当然还有很多没遇到的或者不常见后续扩展。也放一些网上比较容易搜到的偏原理性的文章放在下面供日后回过头来再总结