TienChin 项目也是一个前后端分离项目,前后端分离项目如果做成 SPA(单页面)的形式,就必然面临一个首屏加载的问题,因为默认情况下首页文件比较大,可能超过 1 MB,进而带来首页加载很慢的问题。所以我们要通过优化,来提高首页的加载速度。
问题的解决,一般来说有这样几种思路:
这些加载方式中,UI 组件按需加载和 gzip 是两种比较常用的方案,另外两种优化方式则要结合具体的项目,看看是否具备相关条件。
所以,本文松哥就先来和大家聊一聊 UI 组件懒加载和 gzip。
不做任何优化,我们一般是在 main.js 中按照如下方式来引入 ElementUI 的:
import ElementUI from'element-ui';
import'element-ui/lib/theme-chalk/index.css';
vue.use(ElementUI,{size:'small'});
css 这个不用说,肯定得引入。但是按照上面这种引入方式,除了 css,其他组件全部都引入到项目中了,最新版的 ElementUI 中的组件已经接近 60 个了,但是我们项目中用的组件可能没有这么多,这些最终没用上的组件就会造成资源浪费。
在不做任何优化的情况下,我们通过如下命令对项目生成 report.html 用来帮助我们分析包内容:
vue-cli-service build --report
该命令执行的日志如下(截取了关键部分):
warning
entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (244 KiB). This can impact web performance.
Entrypoints:
app (1.17 MiB)
css/chunk-vendors.9948ce82.css
js/chunk-vendors.11959501.js
css/app.4e8a7623.css
js/app.ce6f575c.js
File Size Gzipped
dist/js/chunk-vendors.11959501.js 840.77 KiB 227.94 KiB
dist/js/app.ce6f575c.js 99.08 KiB 30.95 KiB
dist/js/chunk-64435448.d0a0516e.js 26.52 KiB 5.87 KiB
dist/js/chunk-0c17a57a.d553638c.js 23.79 KiB 5.49 KiB
dist/js/chunk-a3fdbb9c.ddc4c008.js 13.30 KiB 3.45 KiB
dist/js/chunk-54277bc7.2882c4cd.js 10.40 KiB 2.95 KiB
dist/js/chunk-4e552d82.c64f4d10.js 1.78 KiB 0.63 KiB
dist/js/chunk-18458ebc.32fb57c9.js 1.54 KiB 0.62 KiB
dist/js/chunk-2d0d03c8.3a093d55.js 0.52 KiB 0.36 KiB
dist/js/chunk-2d237c54.0b312051.js 0.43 KiB 0.33 KiB
dist/css/chunk-vendors.9948ce82.css 258.19 KiB 41.36 KiB
dist/css/app.4e8a7623.css 3.46 KiB 1.09 KiB
dist/css/chunk-0c17a57a.9fe19f94.css 0.86 KiB 0.35 KiB
dist/css/chunk-64435448.3755e146.css 0.30 KiB 0.15 KiB
从这段日志中我们可以看到,项目入口文件的大小超出了官方建议的 244KB,而这可能会影响网页的表现。
此时我们把打包后的文件拷贝到 Spring Boot 的 resources/static 目录下,启动后端项目,来看下浏览器的加载情况:
可以看到,最大的 chunk-vendors.11959501.js 文件加载用了 369ms。
同时大家注意到,此时在前端 dist 目录下还有一个文件叫做 report.html,这是生成的打包报告,我们在浏览器打开这个页面,如下:
在这个 html 页面中,通过可视化页面向我们展示了到底是谁把 js 文件撑大的,从图中我们可以看到,chunk-vendors.11959501.js 文件之所以比较大,是因为它里边的 element-ui.commons.js 这个文件比较大。
实际上,每个模块都可以去想办法优化,但是枪打出头鸟,因为 element-ui.commons.js 实在太大了,我们就先把它给优化了。
优化办法其实很简单,ElementUI 官网也给出了办法,首先我们加载安装 babel-plugin-component:
npm install babel-plugin-component -D
然后修改 babel.config.js 文件,如下:
module.exports = {
presets: [
'@vue/app',
['@babel/preset-env', {
modules: false
}]
],
plugins: [
[
"component",
{
"libraryName": "element-ui",
"styleLibraryName": "theme-chalk"
}
]
]
}
配置完成后,再去修改 main.js 文件,将我们需要用到的组件一个一个引入进来:
import {
Button,
Input,
Table,
TableColumn,
Dialog,
Card,
Container,
Icon,
Select,
Form,
Tag,
Tree,
Pagination,
Badge,
Loading,
Message,
MessageBox,
Menu,
Tabs,
TabPane,
Breadcrumb,
BreadcrumbItem,
Dropdown,
Steps,
Tooltip,
Popover,
Collapse,
FormItem,
Checkbox,
Header,
DropdownMenu,
DropdownItem,
Aside,
Main,
MenuItem,
Submenu,
Option,
Col,
Row,
Upload,
Radio,
DatePicker,
RadioGroup,
CollapseItem,
Switch
} from'element-ui';
import'element-ui/lib/theme-chalk/index.css';
Vue.prototype.$ELEMENT = {size: 'small', zIndex: 3000};
Vue.use(Switch);
Vue.use(CollapseItem);
Vue.use(Radio);
Vue.use(RadioGroup);
Vue.use(DatePicker);
Vue.use(Upload);
Vue.use(Row);
Vue.use(Col);
Vue.use(Option);
Vue.use(Submenu);
Vue.use(MenuItem);
Vue.use(Header);
Vue.use(DropdownMenu);
Vue.use(DropdownItem);
Vue.use(Aside);
Vue.use(Main);
Vue.use(Checkbox);
Vue.use(FormItem);
Vue.use(Collapse);
Vue.use(Popover);
Vue.use(Menu);
Vue.use(Tabs);
Vue.use(TabPane);
Vue.use(Breadcrumb);
Vue.use(BreadcrumbItem);
Vue.use(Dropdown);
Vue.use(Steps);
Vue.use(Tooltip);
Vue.use(Tree);
Vue.use(Pagination);
Vue.use(Badge);
Vue.use(Loading);
Vue.use(Button);
Vue.use(Input);
Vue.use(Table);
Vue.use(TableColumn);
Vue.use(Dialog);
Vue.use(Card);
Vue.use(Container);
Vue.use(Icon);
Vue.use(Select);
Vue.use(Form);
Vue.use(Tag);
Vue.prototype.$alert = MessageBox.alert
Vue.prototype.$confirm = MessageBox.confirm
这里的代码倒是不难,有两个需要注意的地方:
配置完成后,我们再次执行 vue-cli-service build --report ,查看打包结果:
entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (244 KiB). This can impact web performance.
Entrypoints:
app (1.03 MiB)
css/chunk-vendors.26d2c5b9.css
js/chunk-vendors.e2a11728.js
css/app.4e8a7623.css
js/app.c5dd78e5.js
File Size Gzipped
dist/js/chunk-vendors.e2a11728.js 683.05 KiB 177.91 KiB
dist/js/app.c5dd78e5.js 101.70 KiB 31.90 KiB
dist/js/chunk-64435448.d0a0516e.js 26.52 KiB 5.87 KiB
dist/js/chunk-0c17a57a.d553638c.js 23.79 KiB 5.49 KiB
dist/js/chunk-33b8cd94.7bbae1a0.js 13.30 KiB 3.46 KiB
dist/js/chunk-df7e035a.414b548f.js 10.40 KiB 2.95 KiB
dist/js/chunk-4e552d82.c64f4d10.js 1.78 KiB 0.63 KiB
dist/js/chunk-18458ebc.32fb57c9.js 1.54 KiB 0.62 KiB
dist/js/chunk-2d0d03c8.3a093d55.js 0.52 KiB 0.36 KiB
dist/js/chunk-2d237c54.0b312051.js 0.43 KiB 0.33 KiB
dist/css/chunk-vendors.26d2c5b9.css 262.71 KiB 42.11 KiB
dist/css/app.4e8a7623.css 3.46 KiB 1.09 KiB
dist/css/chunk-0c17a57a.9fe19f94.css 0.86 KiB 0.35 KiB
dist/css/chunk-64435448.3755e146.css 0.30 KiB 0.15 KiB
和前面的日志比较后发现,将 ElementUI 按需引入后,还是有效果的,只是效果不太明显。这个时候我们再来打开 report.html 页面来看下:
可以看到,规模庞大的 element-ui.commons.js 已经不见了,取而代之的是一众小喽啰。相关文件大小也减少了 150kb 左右。
这感觉效果有限。
所以,在前面代码的基础上,我们来通过 gzip 继续压缩。
通过 gzip 来压缩,我们有两种思路。这两种思路和前后端分离的两种不同部署方式有关。
前端编译打包后拷贝到后端,直接部署后端项目即可
前后端分离部署,前端通过 Nginx 来部署(推荐)
如果使用第一种方式,前端可以不用做额外工作,还是之前编译后的文件。我们在后端 application.yml 中添加如下配置,开启 gzip 压缩:
server:
compression:
enabled:true
配置完成后,重启后端项目,访问项目首页,如下,可以看到文件基本上都被压缩了:
点开一个请求,可以看到 gzip 已经生效了:
Nginx 中配置前端的 gzip 压缩,有两种思路:
动态压缩 Vue 还是使用普通的打包编译后的文件,将前端编译打包后的文件拷贝到 Nginx 的 html 目录下,然后访问 nginx:http://192.168.91.129
确保 nginx 运行成功后,接下来对 nginx 进行配置:
gzip on; # 开启 gzip
gzip_min_length 2k;# 超过 2kb 进行压缩
gzip_disable msie6; # ie6 不适用 gzip
gzip_types text/css application/javascript text/javascript image/jpeg image/png image/gif; # 需要处理的文件
配置完成后,重启 Nginx:
./nginx -s reload
启动成功后,再去访问前端页面,就可以看到压缩效果了。
上面的动态压缩有一个问题,就是每次请求响应的时候都要压缩,其实都是相同的文件,总是压缩有点浪费资源。
我们可以提前将文件压缩好,就保存在服务端,需要用的时候直接返回,就会方便很多。
这需要我们首先在前端安装压缩插件:
npm install compression-webpack-plugin -D
安装成功之后,接下来在 vue.config.js 中进行配置:
const CompressionPlugin = require("compression-webpack-plugin")
module.exports = {
devServer: {
host: 'localhost',
port: 8080,
proxy: proxyObj
},
configureWebpack: config => {
if (process.env.NODE_ENV === 'production') {
return {
plugins: [
new CompressionPlugin({
test: /\.js$|\.html$|\.css/,
threshold: 1024,
deleteOriginalAssets: false
})
]
}
}
}
}
配置完成后,再次执行打包命令 vue-cli-service build。这次打包完成后,我们可以在 js 目录下看到 .gz 文件,如下:
接下来将文件上传到 Nginx 服务器,然后对 Nginx 重新进行编译打包。想让 Nginx 返回已经压缩好的文件,需要用到 Nginx 中的 http_gzip_static_module 模块,这个模块可以发送以 .gz 作为文件扩展名的预压缩文件,所以我们要对 Nginx 重新进行编译打包:
./configure --with-http_gzip_static_module
make
make install
然后在 Nginx 配置文件中开启 gzip_static,如下:
gzip_static on;
注意,开启了 gzip_static 后,gzip_types 就失效了,所以也没必要配置这个属性了。
配置完成后,重启 Nginx,再去访问,查看浏览器日志,就会发现 gzip 已经生效了。
「注意:」
静态压缩返回的 gzip 压缩文件都是提前准备好的,没有 .gz 格式的文件就会自动返回原文件。这是一种和动态压缩不同的响应策略。动态压缩是根据 Nginx 中的配置,超过配置的大小就会自动进行压缩。
好了,这一波操作下来,首屏加载速度提高了 5 倍左右。
来源: 江南一点雨
在程序开发中,经常会使用到for循环的,但是很多人写的for循环效率都是比较低的,下面就举例说明,并总结优化for循环的方法,来提高我们程序的执行效率。
网站的加载速度不仅影响着用户体验,也会影响搜索引擎的排名,在百度推出“闪电算法”以来,将网站首屏打开速度被列入优化排名行列,作为前端开发的我们需要如果来优化网站的打开速度呢?下面就整理挖掘出很多细节上可以提升性能的东西分享给大家
DocumentFragments是DOM节点。它们不是主DOM树的一部分。通常的用例是创建文档片段,将元素附加到文档片段,然后将文档片段附加到DOM树。在DOM树中,文档片段被其所有的子元素所代替。因为文档片段存在于内存中,并不在DOM树中
对于代码裡面的 if else,我们可以使用逻辑判断式,或更好的三元判断式来优化代码。除了可以降低维护项目的成本之外,还可以提升代码可读性。就让我们从最简单的 if else 例子开始吧。
小程序从发布到现在也已经有将近两年的时间,越来越来多的公司开始重视小程序生态带来的流量,今年也由于小程序平台对外能力的越来越多的开放以及小程序平台的自身优化,越来越多的开发者也自主的投入到小程序的开发当中
无论你正在将 GIF 动图转换为 MP4 视频,还是手头已经有一大堆 MP4 视频,你都可以优化文件结构,以使得这些视频更快地加载和播放。通过重组 atoms 将 moov 放到文件开头,浏览器可以避免发送额外的 HTTP range request 请求来搜寻和定位 moovatom
要优化 Web 服务器的性能,我们先来看看 Web 服务器在 web 页面处理上的步骤:Web 浏览器向一个特定的服务器发出 Web 页面请求; Web 服务器接收到 web 页面请求后,寻找所请求的 web 页面,并将所请求的 Web 页面传送给 Web 浏览器; 显示出来
浏览器下载完页面所有的资源后,就要开始构建DOM树,于此同时还会构建渲染树(Render Tree)。(其实在构建渲染树之前,和DOM树同期会构建Style Tree。DOM树与Style Tree合并为渲染树)
写篇文章的目的,是以开放小程序代码的层面的优化。包括:条件判断将wx:if换成了hidden 、页面跳转请销毁之前使用的资源、列表的局部更新、小程序中多张图片懒加载方案、Input状态下隐藏input,应预留出键盘收起的时间
生活在信息爆炸的今天,我们每天不得不面对和过滤海量的信息--无疑是焦躁和浮动的,这就意味着用户对你站点投入的时间可能是及其吝啬的(当然有一些刚需站点除外)。如何给用户提供迅速的响应就显得十分重要了
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!