前端优化

1. 背景

来自Google的数据表明，一个有10条数据0.4秒能加载完的页面，变成30条数据0.9秒加载完之后，流量和广告收入下降90%。

Google Map 首页文件大小从100KB减小到70-80KB后，流量在第一周涨了10%，接下来的三周涨了25%。

亚马逊的数据表明：加载时间增加100毫秒，销量就下降1%。

关于指标这块，简单介绍下常见指标

FCP（First Contentful Paint）：白屏时间（第一个文本绘制时间）

Speed Index：首屏时间

TTI（Time To Interactive）: 第一次可交互的时间

lighthouse score（performance）：Chrome浏览器审查工具性能评分（也可以npm install -g lighthouse，编程式调用）

2. 贴合项目，可以优化的点

1. 使用webP图片, 转换工具webP-converter / to webP

a. HTML中使用，picture标签兼容

   
   

下附例子，同一张图片，对图片进行webp压缩，正常压缩后的对比，提交小了50%左右，图片加载速度快了10倍左右（多次测试取均值）。

b. CSS中使用，需要配合JS做判断
// main.js
window.addEventListener('DOMContentLoaded', () => {    
const isSupportWebP = document.createElement('canvas').toDataURL('image/webp').indexOf('data:image/webp') === 0 
document.documentElement.classList.add(isSupportWebP ? '' : '.no-support-webp');})
// css
.support-webp .bg{    background-image: url("hehe.webp");}
.no-support-webp .bg {    background-image: url("hehe.png");}

2. 优化包的体积，按需引入

// alias配置
resolve: {  alias: {    '@ant-design/icons/lib/dist$': path.resolve(__dirname, './src/icons/antd-icon.js')  }}
// src/icons/antd-icon.js
export { default as LoadingOutline } from '@ant-design/icons/lib/outline/LoadingOutline'

3. moment按需引入locale

4. 用https 2.0
// nginx.conf
listen 443 http2;
多路复用避开了资源并发限制，但资源太多的情况，也会造成浏览器性能损失（Chrome进程间通信与资源数量相关）

5. Gzip压缩传输
Gzip压缩是一种强力压缩手段，针对文本文件时通常能减少2/3的体积。
HTTP协议中用头部字段Accept-Encoding 和 Content-Encoding对「采用何种编码格式传输正文」进行了协定，请求头的Accept-Encoding会列出客户端支持的编码格式。当响应头的Content-Encoding指定了gzip时，浏览器则会进行对应解压。
一般浏览器都支持gzip，所以Accept-Encoding也会自动带上gzip，所以我们需要让资源服务器在Content-Encoding指定gzip，并返回gzip文件

可以nginx响应压缩，也可以打包压缩，直接返回压缩后的资源。
插件的默认压缩等级是9，最高级的压缩；
图片文件不建议使用gzip压缩，效果较差

Brotli 压缩慢，但是提交更小，解压速度不影响，存在兼容性问题。

6. Prefetch、Preload
标签的rel属性的两个可选值。\ **Prefetch**，预请求，是为了提示浏览器，用户未来的浏览有可能需要加载目标资源，所以浏览器有可能通过事先获取和缓存对应资源，优化用户体验。\ **Preload**，预加载，表示用户十分有可能需要在当前浏览中加载目标资源，所以浏览器必须预先获取和缓存对应资源。

7. 白屏时的loading动画
首屏优化，在JS没解析执行前，让用户能看到Loading动画，减轻等待焦虑。通常会在index.html上写简单的CSS动画，直到Vue挂载后替换挂载节点的内容，但这种做法实测也会出现短暂的白屏，建议手动控制CSS动画关闭

8.首屏骨架加载
a. react suspense

webp

png

3. lighthouse

待补充

4. 总结

1. 衡量现实世界的经验并设定适当的目标。一个好的目标是第一次有意义的会话<1秒，速度指数值<1250，交互时间<5秒慢3g，重复访问，tti <2s。优化开始渲染时间和交互时间。

2. 准备主要模板的关键CSS，并将其包含在页面的中。（你的预算是14 kb）。对于css / js，在最大的关键文件大小预算内运行。170KB gzipped（0.8-1mb解压缩）。

3. 延迟和延迟加载尽可能多的脚本，包括您自己的脚本和第三方脚本，尤其是社交媒体按钮，视频播放器和昂贵的JavaScript。

4. 通过更快的dns-lookup，preconnect，prefetch和preload，添加资源提示来加速交付。

5. 子集Web字体并加载它们（或者只是切换到系统字体）。

6. 优化图像，并考虑使用webp的关键页面（如登陆页）。

7. 检查http缓存头和安全头是否设置正确。

8. 在服务器上启用brotli或zopfli压缩。（如果这是不可能的，不要忘记启用gzip压缩。）

9. 如果http / 2可用，则启用hpack压缩并开始监视混合内容警告。如果您正在运行lts，还可以启用ocsp装订。

10. 缓存资源，如字体，样式，JavaScript和图像-实际上，尽可能！-在service worker缓存中。

参考链接

11s到1s 首屏加载优化

lighthouse使用介绍

hiper 介绍

pwa介绍

moment优化