首屏作为直面用户的第一屏其重要性不言而喻如何加快加载的速度是非常重要的一课。
本文讲解的是笔者对自己搭建的个人博客网站的速度优化的经历。
效果体验地址 http://biaochenxuying.cn
1. 用户期待的速度体验
2018 年 8 月百度搜索资源平台发布的《百度移动搜索落地页体验白皮书 4.0 》中提到页面的首屏内容应在 1.5 秒内加载完成。
也许有人有疑惑为什么是 1.5 秒内哪些方式可加快加载速度以下将为您解答这些疑问
移动互联网时代用户对于网页的打开速度要求越来越高。百度用户体验部研究表明页面放弃率和页面的打开时间关系如下图所示
根据百度用户体验部的研究结果来看普通用户期望且能够接受的页面加载时间在 3 秒以内。若页面的加载时间过慢用户就会失去耐心而选择离开这对用户和站长来说都是一大损失。
百度搜索资源平台有 “闪电算法” 的支持为了能够保障用户体验给予优秀站点更多面向用户的机会“闪电算法”在 2017 年 10 月初上线。
闪电算法 的具体内容如下
移动网页首屏在 2 秒之内完成打开的在移动搜索下将获得提升页面评价优待获得流量倾斜同时在移动搜索页面首屏加载非常慢3 秒及以上的网页将会被打压。
2. 分析问题
未优化之前首屏时间居然大概要 7 - 10 秒简直不要太闹心。
开始分析问题先来看下 network
主要问题
- 第一个文章列表接口用了 4.42 秒
- 其他的后端接口速度也不快
- 另外 js css 等静态的文件也很大请求的时间也很长
我还用了 Lighthouse 来测试和分析我的网站。
Lighthouse 是一个开源的自动化工具用于改进网络应用的质量。 你可以将其作为一个 Chrome 扩展程序运行或从命令行运行。 为 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 创建的项目很多配置已经是很好了的笔者只修改了两处地方。
-
- 打包配置修改了 webpack.config.js 的这一行代码
// 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;
生产环境下打包去掉 SourceMap静态文件就很小了从 13M 变成了 3M 。
-
- 还修改了图片打包大小的限制这样子小于 40K 的图片都会变成 base64 的图片格式。
{
test: [/\.bmp$/, /\.gif$/, /\.jpe?g$/, /\.png$/,/\.jpg$/,/\.svg$/],
loader: require.resolve('url-loader'),
options: {
limit: 40000, // 把默认的 10000 修改为 40000
name: 'static/media/[name].[hash:8].[ext]',
},
}
2.1.2 去掉没用的文件
比如之前可能觉得会有用的文件后面发现用不到了注释或者删除比如 reducers 里面的 home 模块。
import { combineReducers } from 'redux'
import { connectRouter } from 'connected-react-router'
// import { home } from './module/home'
import { user } from './module/user'
import { articles } from './module/articles'
const rootReducer = (history) => combineReducers({
// home,
user,
articles,
router: connectRouter(history)
})
2.1.3 图片处理
-
把一些静态文件再用 photoshop 换一种格式或者压缩了一下 比如 logo 图片原本 111k压缩后是 23K。
-
首页的文章列表图片修改为懒加载的方式加载。
之前因为不想为了个懒加载功能而引用一个插件所以想自己实现看了网上关于图片懒加载的一些代码再结合本项目实现了一个图片懒加载功能加入了 事件的节流throttle与防抖debounce。
代码如下
// fn 是事件回调, delay 是时间间隔的阈值
function throttle(fn, delay) {
// last 为上一次触发回调的时间, timer 是定时器
let last = 0,
timer = null;
// 将throttle处理结果当作函数返回
return function() {
// 保留调用时的 this 上下文
let context = this;
// 保留调用时传入的参数
let args = arguments;
// 记录本次触发回调的时间
let now = +new Date();
// 判断上次触发的时间和本次触发的时间差是否小于时间间隔的阈值
if (now - last < delay) {
// 如果时间间隔小于我们设定的时间间隔阈值则为本次触发操作设立一个新的定时器
clearTimeout(timer);
timer = setTimeout(function() {
last = now;
fn.apply(context, args);
}, delay);
} else {
// 如果时间间隔超出了我们设定的时间间隔阈值那就不等了无论如何要反馈给用户一次响应
last = now;
fn.apply(context, args);
}
};
}
// 获取可视区域的高度
const viewHeight = window.innerHeight || document.documentElement.clientHeight;
// 用新的 throttle 包装 scroll 的回调
const lazyload = throttle(() => {
// 获取所有的图片标签
const imgs = document.querySelectorAll('#list .wrap-img img');
// num 用于统计当前显示到了哪一张图片避免每次都从第一张图片开始检查是否露出
let num = 0;
for (let i = num; i < imgs.length; i++) {
// 用可视区域高度减去元素顶部距离可视区域顶部的高度
let distance = viewHeight - imgs[i].getBoundingClientRect().top;
// 如果可视区域高度大于等于元素顶部距离可视区域顶部的高度说明元素露出
if (distance >= 100) {
// 给元素写入真实的 src展示图片
let hasLaySrc = imgs[i].getAttribute('data-has-lazy-src');
if (hasLaySrc === 'false') {
imgs[i].src = imgs[i].getAttribute('data-src');
imgs[i].setAttribute('data-has-lazy-src', true); //
}
// 前 i 张图片已经加载完毕下次从第 i+1 张开始检查是否露出
num = i + 1;
}
}
}, 1000);
注意给元素写入真实的 src 了之后把 data-has-lazy-src 设置为 true 是为了避免回滚的时候再设置真实的 src 时浏览器会再请求这个图片一次白白浪费服务器带宽。
具体细节请看文件 文章列表
2.2 后端优化
后端用到的技术是 node、express 和 mongodb。
后端主要问题是接口速度很慢特别是文章列表的接口已经是分页请求数据了为什么还那么慢呢
所以查看了接口返回内容之后发现返回了很多列表不展示的字段内容特别是文章内容都返回了而文章内容是很大的占用了很多资源与带宽从而使接口消耗的时间加长。
从上图可以看出文章列表接口只要返回文章的 标题、描述、封面、查看数评论数、点赞数和时间即可。
所以把不需要给前端展示的字段注释掉或者删除。
// 待返回的字段
let fields = {
title: 1,
// author: 1,
// keyword: 1,
// content: 1,
desc: 1,
img_url: 1,
tags: 1,
category: 1,
// state: 1,
// type: 1,
// origin: 1,
// comments: 1,
// like_User_id: 1,
meta: 1,
create_time: 1,
// update_time: 1,
};
同样对其他的接口都做了这个处理。
后端做了处理之后所有的接口速度都加快了特别是文章列表接口只用了 0.04 - 0.05 秒左右相比之前的 4.3 秒速度提高了 100 倍简直不要太爽 效果如下
此刻心情如下
2.3 服务器优化
你以为前后端都优化一下本文就完了 小兄弟你太天真了重头戏在后头
笔者服务器用了 nginx 代理。
做的优化如下
- 隐藏 nginx 版本号
一般来说软件的漏洞都和版本相关所以我们要隐藏或消除 web 服务对访问用户显示的各种敏感信息。
如何查看 nginx 版本号 直接看 network 的接口或者静态文件请求的 Response Headers 即可。
没有设置之前可以看到版本号比如我网站的版本号如下
Server: nginx/1.6.2
设置之后直接显示 nginx 了没有了版本号如下
Server: nginx
- 开启 gzip 压缩
nginx 对于处理静态文件的效率要远高于 Web 框架因为可以使用 gzip 压缩协议减小静态文件的体积加快静态文件的加载速度、开启缓存和超时时间减少请求静态文件次数。
笔者开启 gzip 压缩之后请求的静态文件大小大约减少了 2 / 3 呢。
gzip on;
#该指令用于开启或关闭gzip模块(on/off)
gzip_buffers 16 8k;
#设置系统获取几个单位的缓存用于存储gzip的压缩结果数据流。16 8k代表以8k为单位安装原始数据大小以8k为单位的16倍申请内存
gzip_comp_level 6;
#gzip压缩比数值范围是1-91压缩比最小但处理速度最快9压缩比最大但处理速度最慢
gzip_http_version 1.1;
#识别http的协议版本
gzip_min_length 256;
#设置允许压缩的页面最小字节数页面字节数从header头得content-length中进行获取。默认值是0不管页面多大都压缩。这里我设置了为256
gzip_proxied any;
#这里设置无论header头是怎么样都是无条件启用压缩
gzip_vary on;
#在http header中添加Vary: Accept-Encoding ,给代理服务器用的
gzip_types
text/xml application/xml application/atom+xml application/rss+xml application/xhtml+xml image/svg+xml
text/javascript application/javascript application/x-javascript
text/x-json application/json application/x-web-app-manifest+json
text/css text/plain text/x-component
font/opentype font/ttf application/x-font-ttf application/vnd.ms-fontobject
image/x-icon;
#进行压缩的文件类型,这里特别添加了对字体的文件类型
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
#禁用IE 6 gzip
把上面的内容加在 nginx 的配置文件 ngixn.conf 里面的 http 模块里面即可。
是否设置成功看文件请求的 Content-Encoding 是不是 gzip 即可。
- 设置 expires设置缓存
server {
listen 80;
server_name localhost;
location / {
root /home/blog/blog-react/build/;
index index.html;
try_files $uri $uri/ @router;
autoindex on;
expires 7d; # 缓存 7 天
}
}
我重新刷新请求的时候是 2019 年 3 月 16 号是否设置成功看如下几个字段就知道了
- Staus Code 里面的 form memory cache 看出文件是直接从本地浏览器本地请求到的没有请求服务器。
- Cache-Control 的 max-age= 604800 看出过期时间为 7 天。
- Express 是 2019 年 3 月 23 号过期也是 7 天过期。
注意上面最上面的用红色圈中的 Disable cache 是否是打上了勾打了勾表示浏览器每次的请求都是请求服务器无论本地的文件是否过期。所以要把这个勾去掉才能看到缓存的效果。
终极大招服务端渲染 SSR也是笔者接下来的方向。
3.1 测试场景
一切优化测试的结果脱离了实际的场景都是在耍流氓而且不同时间的网速对测试结果的影响也是很大的。
所以笔者的测试场景如下
- a. 笔者的服务器是阿里的配置是入门级的学生套餐配置如下
- b. 测试网络为 10 M 光纤宽带。
3.2 优化结果
优化之后的首屏速度是 2.07 秒。
最后加了缓存的结果为 0.388 秒。
再来看下 Lighthouse 的测试结果
比起优化之前各项指标都提升了很大的空间。
4. 最后
优化之路漫漫永无止境天下武功唯快不破。
本次优化的前端与后端项目都已经开源在 github 上了欢迎围观。
github 博客地址https://github.com/biaochenxuying/blog
如果您觉得这篇文章不错或者对你有所帮助请给个赞或者星呗你的点赞就是我继续创作的最大动力。