优化Vue前端项目,让你的应用再快一些
By: Date: 2022年9月23日 Categories: 程序 标签:,

项目功能基本开发完毕,在上线试运行的时候,前后端的性能问题就会不断的暴露出来。应用后端的接口响应慢导致超时,页面无法加载,或页面渲染慢,卡顿等影响用户体验。这类问题是需要我们引起足够重视的。否则尽全力开发出来的应用因为一些细小的问题而使得客户的评价大打折扣。这次针对应用前端的优化,简单来聊聊我们应该从哪些方面入手。

我们的项目前端采用Vue2+ElementUI进行开发,使用vue-cli3做脚手架,基于此引入各种第三方插件等,整个系统采用前后端分离部署,所以我们来看看需要注意的有哪些地方。

一. vue前端项目优化

  • 1. 关闭SourceMap:当我们的项目build之后,是会生成一堆的map文件的,因为项目打包后,文件经过了压缩加密,在运行时出错时难以定位,而原本生成出来的map则未进行压缩加密,近乎于源码,可以帮助我们准确的定位问题出在了哪里。那这样敏感的文件,在上线时,我们当然要关闭生成SourceMap,减少输出文件大小,同时还能提高打包速度。

设置vue.config.js中的productionSourceMap如下:

module.exports = {
    //...
    productionSourceMap: process.env.NODE_ENV != "production"
    //...
}
  • 2. 避免请求不存在的资源:增加 favicon.ico 文件,该文件不存在时,会收到错误的响应。
    <link rel="icon" href="<%= BASE_URL %>favicon.ico">
    这样的链接虽然不会对我们的系统造成影响,但看到开发者工具中出现了404的错误,就会浑身不自在,所以我们也顺手将服务器上不存在,但是却被前端引用了的代码干掉。
  • 3. 调整页面中数据加载顺序,如:原来是先加载查询条件中的下拉框选项数据,后加载列表。可以改为先去加载页面中可见的数据,有限渲染,之后再去加载次要的数据,如下拉框等一些优先级较低的数据。这样的调整其实是很有必要的,并且也是很容易被人们忽略的。我们常常是从上往下写,这样可能会将一些隐藏的,甚至不需要直接看到的数据优先请求下来,却忽略了真正能给用户带来实际价值的重要的数据,这就有些主次不分了。
  • 4. 优化页面加载逻辑顺序,串行改为并行,同步请求改为异步调用,例如:原来是先加载查询方案,拿到后端响应后的数据,在前端将查询方案中的默认查询条件作为查询参数,再去查询列表数据,这样同步的加载,实际上是很影响页面的显示速度。
  • 5. 修改方案当然可以改为并行去加载数据,查询列表数据时,只需要知道当前的查询方案编号即可,在后台自己组装查询参数。但是同时区别对待是否是第一次加载,因为查询方案在页面上用户可能做过变更但并未保存该方案。当然了实际情况需要自己来评估,优化的目的,是为了将串行的请求改造成并行的请求,最大化的去除整体等待响应的时间。
  • 6. 移除项目中的console,大量的打印或对于大的复杂对象的控制台输出会对浏览器的性能及内存造成影响。 我们可以使用babel-plugin-transform-remove-console插件,并通过插件的配置来去除线上环境的console.的操作,并且可以仅开发及测试环境可见。这样我们build出来的文件就不会再包含console了。
  • 7. 改造部分大数据量的页面,异步去加载分页中的总条数,和页数。
    当我们后端获取数据的接口需要从海量的数据中筛选出需要的数据并返回前端的时候,同时查询结果以及行数会使得接口响应变慢,使得页面加载的时间变长。因此我们采用两个接口分别去获取列表数据以及总行数来减少等待的时间。
  • 8. 检查我们的代码,删除无用的逻辑判断,未使用的变量定义,优化耗时较多的逻辑处理,如:request.js中被定义了却未被使用的变量,通用组件中datagrid中没有使用的变量赋值,大量的forEach处理等。通常这些无用的代码不会使得我们的应用变的更快,但它能够让我们的应用变的更加简洁。
  • 9. 服务器端开启http压缩响应内容,通常采用gzip算法压缩传输的html,Javascript以及样式表Css文件等代码,用于提高静态文件的传输数据量,变向的提高传输速度。缺点是会增加一些服务器的开销,因此使用过程中需要根据实际情况权衡。
  • 10. Vue预渲染,可以在构建的时候生成一些简单的,针对特定路由的静态HTML页面,当访问这些路由时,实际响应的是我们已经生成的Html页面,也能提高我们的加载速度。这种方法也适合于需要做SEO(搜索引擎优化)的应用。
  • 11. 针对应用中效率较低的组件进行替换,比如ElementUI的Table组件在大数据量展示的情况下,会有卡顿等性能问题。我们的应用通常需要默认展示1000行的数据,并且列数在80列左右。表格中包含左右列冻结,支持全选等。在这样的场景下ElementUI表格的渲染就会很慢,在勾选全选时卡顿尤为严重。因此我们可以选择其他的表格组件进行替换,如停更的pl-table,后来被融合进了umy-ui之中。它的虚拟表格可以很好的支持大数据量展示,他的实现逻辑只会渲染可见区域的dom元素,在滚动条展示区域以外的元素是不会创建在dom树中,这样就减少了dom树的大小,大大提高了渲染效率。因此当我们使用它替换原来的表格组件时,性能得到了很大的提升,卡顿的问题已经不会再出现。

以上是我们在优化前端项目时所采用的或者能够想到的一些优化的方向,有一些其实我并没有使用,如http压缩,预渲染等,但这些也确实是在某些场景下是可以考虑优化的点。当然了,综上其核心不变的都是考虑页面是否可以静态化,是否可以异步加载,请求是否可以并行,是否可以减少页面文件大小,传输的速度能否再提高等。配合上面前端的优化,我们后端也或多或少需要做一些改造,我们也简单的列出一些为配合前端所做的优化的点。

二. 与前端相关的后端接口优化

  • 1. 前端将列表数据和总条数做了拆分,那么后端也需要优化BaseController类中的分页方法,将数据的查询 和 数据总条数的查询,分离成两个接口,查分页数据时不返回总条数。这样虽然增加了请求次数,但却可以将两个串行的查询变成两并行的查询请求同时执行。
  • 2. 查找并检查应用后端响应慢的接口,优化接口代码的处理逻辑,避免for循环中大量的数据库查询,还可以采用相同的内容增加缓存等方式加快响应。
  • 3. 针对接口查询数据库慢的问题,根据查询条件添加适当的索引,根据索引查询库表当然会极大的提高接口的性能。
  • 4. 查询数据库表时可以按需查询,仅查询需要的列,这样可以减少结果集的大小,提高查询速度以及响应速度。

当然了,后端的优化我们主要以降低接口的响应时间为优化方向,使得后端的接口能够快速的响应前端的请求,来减少前端等待的时间。很多时候优化的点还要依据系统的实际情况来定,但优化的方式都基本相似。后面再来总结,我们大数据量下复杂的业务系统后端是如何优化的,今天就先到这。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注