官网类站点性能指标
对于官网类的站点,有两点是比较重要的 ,所以我们通常使用 react 同构渲染方案:
- 首屏渲染时间(影响用户体验)
- SEO(影响官网自然流量)
性能监控
1.我们使用 firebase 来监控,项目中接入 firebase 后会得到6个指标
通常对于官网类的站点,我们主要看 First contentful paint 这个指标,通常来说 :
- 2s以内 : 达标
- 1s - 1.5s : 优秀
- 1s以内 : 极好
2.还可以通过 Lighthouse 来查看页面性能和优化方案
性能指标
优化方案
使用方法
介绍这两种工具的使用方法
Firebase
- 通过 console.firebase.google.com/ 来新建一个 project
- 选择一个app去开始
- 生成一段 firebase 代码
- 将这段代码添加进你的代码
- 在 Performance 中可以查看性能,可以看到访问最多的 url 的一些集合和他们的FCP ,点击进去后可以查看具体页面的6个性能。对于官网类网站来说,通常我们更关注FCP
Lighthouse
1.打开开发者调试工具,选中 Lighthouse ,点击生成报告进行分析
2.我们可以看到网站的评分和各个方面的优化建议
3.分析中有各部分代码消耗的时间,我们逐步优化就可以提升评分和网站性能。比如:
● 删除没有用的javascript
● 压缩javascript
● 使用合适大小的图片,通常我们会对图片在保证质量的情况下进行压缩。目前来看 webp 格式的图片是效果最好的,但可能存在部分浏览器不支持的情况,需要在代码中进行判断后选择对应的格式
● 图片懒加载
● 预连接一些可能在网站中调用的外部网站
优化方案
介绍一些可行的站点优化方案
- 首先这类对 FCP 和 SEO 要求较高的网站肯定是不要使用客户端渲染的方式来做了,一般肯定达不到性能指标要求。推荐使用React SSR 同构渲染方式,即服务端和客户端渲染同一套代码,首屏返回通过服务端返回的方式渲染。
- 比较固定的数据请求放在服务端请求好送到客户端代码,在 constructor 中进行数据预取
- 就是一些基础的 webpack 打包过程中,对js,css等代码的压缩混淆,来缩小资源的体积
- 对不同格式的图片进行base64转码处理,防止过多发送请求请求图片资源(酌情)
- 使用 react-loadable 进行对项目进行拆分打包,按需加载
- 在 webpack 打包中加入 BundleAnalyzerPlugin 进行模块分析,对大模块进行修改优化,同时对采取的第三方组件进行分析。 ● 是否有相同功能的组件,能否使用一个满足需求 ● 组件是否比较老,较新版本的组件通常会对大小进行优化,可选择较小版本的组件 ● 组件是否有很多不用的功能,能否采用简化版的组件(EG.lottie 和 lottie-web)
- 预连接,在 helmet 中可以添加一些过程中可能会调用到的第三方域名使用 preconnect 进行预连接提升速度
- 控制服务端渲染返回的 html 大小,如果大小可以接受,可以选择将打包好的 css 代码融合在html中一起返回,避免多次请求 css 资源。
- 使用 picture 元素来控制不同大小屏幕加载不同大小的图片,不同浏览器支持不同格式图片来进行流量节省,或者使用雪碧图
- 图片懒加载,使用 lazy 属性可以满足,但 lazy 属性会根据网络状况决定加载图片的多少,通常网络状况越好,加载图片资源越多。如果想对首屏有更好的处理,可以自己实现图片懒加载方案,即图片即将出现在视口后才进行图片加载。
- 配置 cdn ,设置过期时间
- 在nginx层判断使用 HTTP2 升级网站。http/2最大的特点是使用多路复用,对同一个域的服务器只建立一次TCP连接,加载多个资源,使用二进制帧传输,同时会对http头部进行压缩。