查看原文
其他

来公司半年了,我做了哪些优化,能让老板对我刮目相看~

作者:掘金——苏州意大利炮

https://juejin.cn/post/7233046023243907128

背景

去年7月入职了现在的公司。记录一下在公司做的前端代码优化,如果你也遇到了同样的问题,希望可以帮助到你,或者可以在评论区进行交流。

搭建私服

背景

我入职公司的时候后端已经有了私服,前端是没有私服.

前端有一个业务组件库,将使用频率高的组件写到了一个gitLab的仓库中,当需要有新功能或者bug修复,需要先build后再拖动到项目中

存在的问题

  1. 引入麻烦。当组件库有更新时只能在本地构建后才可以放入到依赖的包里
  2. 没有版本的概念。只能用最新的代码,如果出现破坏性的更改,那后果将不堪设想

改进

搭建私服。

构建工具(webpack)优化

背景

刚来公司的时候,询问老员工,前端项目怎么启动(自己进行了install后,npm run serve)后启动了,但是调用接口不成功

老员工发给了我一个nginx的安装包

这是要干啥,我去当面沟通了一下,原来是启动项目的时候本地需要启动一个nginx,用做接口转发

当时我内心是想着这个公司用了什么高级功能,webpack的devserver有啥转发实现不了吗?算了先跑起来后面在问。

后期看了下nginx的配置,只是把所有的接口进行了转发,后加了一个devserver进行了解决。

解决后别的前端开发也说了,早知道这么简单早就弄了。。。


启动时间优化

背景

一个前端项目迭代了3年多(里面的一些功能也外包了出去,代码是又乱又多),非常庞大,可以说是巨石项目,启动时间达到了120秒左右(还是在node_modules里有cache的场景,非第一次启动),用公司配置的window电脑的话需要5min

再测试一次


直接看优化后的效果图片

对你没看错,比优化前多了50秒,你可能有这个疑问(我知道你很急,但是你别急,请继续向下看)

第二次启动

第三次启动

原理

HardSourceWebpackPlugin 是 webpack 的插件,为模块提供中间缓存步骤,通俗一点为缓存了一些文件到你的node_modules。

缓存的目录是node_modules/.cache/hard-source

在解决的过程也尝试了很多webpack的插件(多线程打包、happyPack等效果都不明显),目前测试下来只有这个hard-source-webpack-plugin[2]作用最大

HardSourceWebpackPlugin文档中 列出了一些你可能会遇到的问题以及如何解决,例如热更新失效,或者某些配置不生效等。

使用方法

  1. 安装依赖

npm install hard-source-webpack-plugin -D
  1. 修改 webpack 的配置:

//webpack.config.js
var HardSourceWebpackPlugin = require('hard-source-webpack-plugin');
module.exports = {
    //...
    plugins: [
        new HardSourceWebpackPlugin()
    ]
}

打包时间优化

背景

还是上面的巨石项目,启动时间大概在2min(公司发的台式机是5min),项目用的是vuecli,打包时间竟然在20多分钟,并且jekins经常会构建失败,打包命令还需加上最大的内存的限制。


node --max_old_space_size=8192 node_modules/@vue/cli-service/bin/vue-cli-service.js build

我问了同事这个项目怎么构建这么久,你们平常上线的话是怎么来操作的?

我同事也很真诚的回答了我: 我们会几个人同时打包前端,然后开把王者荣耀,看谁打包的快,就用谁电脑上打的包。。。

这样的话还存在一个问题,假如有个人电脑的nodejs版本不同,或者某个人忘记拉取了最新的代码,会造成发布发布失败,跟个人的关联关系太大了,我们应该更加相信机器,使用jekins打包

结果

打包时间从20多min优化到5min。

优化方案

加了一个配置项,css不单独提取出去


解决过程

虽然相对于之前只加了一行代码,但是为了找出真正的原因花费了大半天的时间。

  1. 先找出插件和loader的耗时,查看耗时在哪里 speed-measure-webpack-plugin 插件可以测量各个插件和loader所花费的时间。

    测试后并没有发现有用的数据

  2. 思考问什么开发环境启动时5min,打包怎么就成了20多min。(想想打包的时候默认的sourceMap和eslint都是没开启的,按照道理来说应该是更快的。怎么反而更慢),

  3. 项目使用的是vuecli(3.5.3),是不是vuecli对webpack里的默认值做了一些更改,然后对照着配置一个一个找,查看哪些是生产开启,开发没开启的

  4. 找了半天没发现可以的对象,一度想把vuecli升级到5,但是担心一系列的组件依赖都要升级,项目的稳定性不够好,还是继续寻找。

  5. 终于找到了怀疑的对象,测试后发现构建的时间确实会缩短


猜想,项目是巨石应用,里面的代码太多了,所以在拆分css形成单独的文件的时候消耗太久了,开发环境这个参数默认是关闭的,所以启动时间在5min,打包的时候这个参数开启,造成了大量的文件写入,所以慢。

代码优化

图标库的优化

下载体验优化

背景

项目中有一个功能是学习课程的,需要有一个下载的功能,现在的流程是后端返回是一个文件流形式,前端将文件流转成链接,然后下载。

600M视频,需要1-2min左右的加载时间,目前是在下载的时候添加了loading,造成用户在这2min不能操作,很影响用户体验

Q:为什么不能直接使用window.location.href?

A:视频的课程存储的是ID,后端单独有一个服务是文件服务,需要网关的鉴权,目前的鉴权是放在request的header中。

目标

期望可以跟在软件的官网上下载文件一样,调用浏览器的默认下载,如下图,不会影响用户的操作。


解决

查看一些资料后location.href 或者window.open可以实现这种效果,但是token怎么来解决。

想到了把token可以存在cookie中,当用户发起请求的时候回默认带上,后端可以将下载的接口就行扩展,支持从cookie中获取。

jekins优化

优化前


优化后


背景

  1. 组内人员反应jekins的前端项目每次打包的时候,nodejs把服务器的内存占满了,导致打包排队,看是否能降低内存
  2. 每次都要进行install,能否跟本地一样,只更新新装的包
  3. 还有一个很大的原因打包脚本是后端帮忙写的,后端不懂前端的打包,前端不懂打包脚本,造成了中间信息的断层

改进

我自己也不懂jekins啊,只能自己去学习,上家公司是有专业的运维团队在管理,有点尴尬

查看官方文档和打包的脚本再加上自己的脸皮厚,一直再问后端,慢慢理解。找到了原因每次打包都要进行deleteDir() 查看官方的解释清空工作空间,猜测是不是这个导致的


将这个脚本删除后,发现每次都很快。每次将工作空间清除后,当再次执行脚本的时候,都要从0开始install,导致了磁盘的读写,这样解决了占用cpu和每次从零安装的

这个时候要考虑两个场景

  1. 引入了新的依赖后,是否会安装成功
  2. 依赖进行了升级,是否可以升级成功

测试下来没发现什么问题

打包流水线优化

之前是将npm install 和npm run build 统一放在了流水线Protal Npm Build。不方便统计是安装包慢还是npm run build 慢。

改进

将npm install 和npm run build 分开,同时将.npmrc(.npmrc里指定仓库为私服仓库)提交到仓库(这样install的时候会优先从私服安装)

打包产物可以下载

组内的成员想在发布生产的时候,直接从测试环境下载压缩包更新到生产环境

查看官方文档, 在success的时候将压缩包上传到服务器


archiveArtifacts artifacts: 'dist/*.tar.gz', fingerprint: true


推荐阅读  点击标题可跳转

1、vue3 table 性能优化,减少 85% 渲染耗时

2、CSS 的 will-change,为什么有时候能优化几十倍的性能?

3、前端文件流、切片下载和上传:优化文件传输效率与用户体验

继续滑动看下一个
大前端技术之路
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存