// Source maps are resource heavy and can cause out of memory issue for large source files.
const shouldUseSourceMap = process.env.GENERATE_SOURCEMAP !== 'false';
// 把上面的代码修改为:
const shouldUseSourceMap = process.env.NODE_ENV === 'production' ? false : true;
首屏作为直面用户的第一屏,其重要性不言而喻,如何加快加载的速度是非常重要的一课。
本文讲解的是:笔者对自己搭建的个人博客网站的速度优化的经历。
效果体验地址: http://biaochenxuying.cn
1. 用户期待的速度体验
2018 年 8 月,百度搜索资源平台发布的《百度移动搜索落地页体验白皮书 4.0 》中提到:页面的首屏内容应在 1.5 秒内加载完成。
也许有人有疑惑:为什么是 1.5 秒内?哪些方式可加快加载速度?以下将为您解答这些疑问!
移动互联网时代,用户对于网页的打开速度要求越来越高。百度用户体验部研究表明,页面放弃率和页面的打开时间关系如下图所示:
根据百度用户体验部的研究结果来看,普通用户期望且能够接受的页面加载时间在 3 秒以内。若页面的加载时间过慢,用户就会失去耐心而选择离开,这对用户和站长来说都是一大损失。
百度搜索资源平台有 “闪电算法” 的支持,为了能够保障用户体验,给予优秀站点更多面向用户的机会,“闪电算法”在 2017 年 10 月初上线。
闪电算法 的具体内容如下:
移动网页首屏在 2 秒之内完成打开的,在移动搜索下将获得提升页面评价优待,获得流量倾斜;同时,在移动搜索页面首屏加载非常慢(3 秒及以上)的网页将会被打压。
2. 分析问题
未优化之前,首屏时间居然大概要 7 - 10 秒,简直不要太闹心。
开始分析问题,先来看下 network :
主要问题:
我还用了 Lighthouse 来测试和分析我的网站。
未优化之前:
上栏内容分别是页面性能、PWA(渐进式 Web 应用)、可访问性(无障碍)、最佳实践、SEO 五项指标的跑分。
下栏是每一个指标的细化性能评估。
再看下 Lighthouse 对性能问题给出了可行的建议、以及每一项优化操作预期会帮我们节省的时间:
从上面可以看出,主要问题:
知道问题所在就已经成功了一半了,接下来便开始优化之路。
2. 优化之路
网页速度优化的方法实在太多,本文只说本次优化用到的方法。
2.1 前端优化
本项目前端部分是用了 react 和 antd,但是 webpack 用的还是 3.8.X 。
2.1.1 webpack 打包优化
因为 webpack4 对打包做了很多优化,比如 Tree-Shaking ,所以我用最新的 react-create-app 重构了一次项目,把项目升级了一遍,所有的依赖包都是目前最新的稳定版了,webpack 也升级到了 4.28.3 。
用最新 react-create-app 创建的项目,很多配置已经是很好了的,笔者只修改了两处地方。
生产环境下,打包去掉 SourceMap,静态文件就很小了,从 13M 变成了 3M 。
2.1.2 去掉没用的文件
比如之前可能觉得会有用的文件,后面发现用不到了,注释或者删除,比如 reducers 里面的 home 模块。
2.1.3 图片处理
把一些静态文件再用 photoshop 换一种格式或者压缩了一下, 比如 logo 图片,原本 111k,压缩后是 23K。
首页的文章列表图片,修改为懒加载的方式加载。
之前因为不想为了个懒加载功能而引用一个插件,所以想自己实现,看了网上关于图片懒加载的一些代码,再结合本项目,实现了一个图片懒加载功能,加入了 事件的节流(throttle)与防抖(debounce)。
代码如下:
具体细节请看文件 文章列表
2.2 后端优化
后端用到的技术是 node、express 和 mongodb。
后端主要问题是接口速度很慢,特别是文章列表的接口,已经是分页请求数据了,为什么还那么慢呢 ?
所以查看了接口返回内容之后,发现返回了很多列表不展示的字段内容,特别是文章内容都返回了,而文章内容是很大的,占用了很多资源与带宽,从而使接口消耗的时间加长。
从上图可以看出文章列表接口只要返回文章的 标题、描述、封面、查看数,评论数、点赞数和时间即可。
所以把不需要给前端展示的字段注释掉或者删除。
同样对其他的接口都做了这个处理。
后端做了处理之后,所有的接口速度都加快了,特别是文章列表接口,只用了 0.04 - 0.05 秒左右,相比之前的 4.3 秒,速度提高了 100 倍,简直不要太爽, 效果如下:
此刻心情如下:
2.3 服务器优化
你以为前后端都优化一下,本文就完了 ?小兄弟,你太天真了,重头戏在后头 !
笔者服务器用了 nginx 代理。
做的优化如下:
一般来说,软件的漏洞都和版本相关,所以我们要隐藏或消除 web 服务对访问用户显示的各种敏感信息。
如何查看 nginx 版本号? 直接看 network 的接口或者静态文件请求的 Response Headers 即可。
没有设置之前,可以看到版本号,比如我网站的版本号如下:
设置之后,直接显示 nginx 了,没有了版本号,如下:
nginx 对于处理静态文件的效率要远高于 Web 框架,因为可以使用 gzip 压缩协议,减小静态文件的体积加快静态文件的加载速度、开启缓存和超时时间减少请求静态文件次数。
笔者开启 gzip 压缩之后,请求的静态文件大小大约减少了 2 / 3 呢。
把上面的内容加在 nginx 的配置文件 ngixn.conf 里面的 http 模块里面即可。
是否设置成功,看文件请求的 Content-Encoding 是不是 gzip 即可。
我重新刷新请求的时候是 2019 年 3 月 16 号,是否设置成功看如下几个字段就知道了:
3 4. 优化结果
3.1 测试场景
一切优化测试的结果脱离了实际的场景都是在耍流氓,而且不同时间的网速对测试结果的影响也是很大的。
所以笔者的测试场景如下:
3.2 优化结果
优化之后的首屏速度是 2.07 秒。
最后加了缓存的结果为 0.388 秒。
再来看下 Lighthouse 的测试结果:
比起优化之前,各项指标都提升了很大的空间。
4. 最后
本次优化的前端与后端项目,都已经开源在 github 上了,欢迎围观。
前端:https://github.com/biaochenxuying/blog-react
后端:https://github.com/biaochenxuying/blog-node
github 博客地址:https://github.com/biaochenxuying/blog