关于前端速度可以从哪里挤出来

[mark9804]

简单来说就两大条：

• 网络传输时间
• 绘图时间

关于网络传输时间，简单来说又分两大条：

• 对于多个小文件，尽可能把它们合并成一个较大的文件进行传输（比如说一个 card-8 网页要加载七个文件 虽然其中有一个是我加的 ，花时间加载这些小文件就会造成后面需要用到的资源的排队，因为建立传输队列消耗的时间是众生平等的）
• 对于大文件，尽可能减小它们的大小（ *.min.js，还有各种压缩手段），减少单个队列的传输时间

我们的使用场景理论上是一个带宽足够大的环境，因此传输时间的消耗来源主要是建立连接还有排队

对于绘图时间，我比较菜，不能像米忽悠那样看什么不爽就进行一个深度优化，所以我只是尽量做到

• JS 方面，老大哥专业程序员了，对会影响性能的因素知道的比我多，我就不bb了，主要是绘图方面的东西
• 用新的布局模型（现在主要在用 flex 和 grid）代替旧的布局模型（table，float之类的）
  • 虽然理论上全部用 position: absolute 就不需要什么模型了，但是按现在的互联网环境来看这么写不是很现实，网页内容是动态的，浏览器的视窗大小也不是固定不变的（智能手表、手机、平板、带鱼屏、小米冰箱显示屏）
• 能用原生 CSS 完成的东西就不用 JS（比如生成用于纯排版目的的 div 或者 table）或者图片（比如阴影、背景、边框都可以用 CSS 各种声明画出来，比如说 card-8 的头像边框，我就拿 CSS 画了，而不是额外整一张 png ）
  

  Adachi-BOT/src/views/component/card-8/card-8.css

  Lines 102 to 111 in 4f5a397

  	background: radial-gradient(
  	circle,
  	rgba(239, 234, 227, 0.93) 60%,
  	rgba(239, 234, 227, 0.1) 60.5%,
  	rgba(239, 234, 227, 0.1) 65.5%,
  	rgba(239, 234, 227, 0) 66%,
  	rgba(239, 234, 227, 0) 68%,
  	rgba(239, 234, 227, 0.05) 68.5%,
  	rgba(239, 234, 227, 0.05) 68.8%
  	);

效果

更高级的动画基本上也可以用 CSS 来做，用原生的 `transform` 扔给 GPU 干活，JS 再快快不过 C

• 能通过不同的 class 进行样式控制就不用 JS，因为用 JS 控制容易发生重绘），一旦发生重排重绘的话开销大幅提升

其他补充文档
图解浏览器渲染过程 - 基于Webkit/Blink内核Chrome浏览器 · Issue #17 · abcrun/abcrun.github.com
浏览器的工作原理：现代网络浏览器幕后揭秘 - HTML5 Rocks
CSS Triggers
了解资源加载时序 - Chrome 开发者工具中文文档 - html中文网
前端性能优化 24 条建议（2020） - SegmentFault 思否
回流（Reflow）和重绘（Repaint） · Issue #60 · tcatche/tcatche.github.io
CSS Animation性能优化 · Issue #47 · amfe/article