# 关于焦虑感
我现在深深的焦虑感来源于，自从进了饿了么，对于一线直接面对客户的应用平台的编写变得少之又少，虽说会有技术输出等一些提升机会，但是日常工作被死死限定死在了中台的维护和搭建上，这样从某一方面来说 技术视野就被限定在了纯中台的部分，大概会想得到的改进点也就局限于各类页面生成工具上了吧
相对来说 对前端的其他方向，性能优化以及动画方面就会变得比较少了，但不管怎么说，前端毕竟是承载交互的一方，好的页面反馈和动画效果是工作中重要的一环，曾几何时在做sortableseed的时候对拖动排序的动画和按钮之后的动画也十分执着，现在大概也碰不到了吧
后台的好处在于，用户钉死了，不必考虑太多兼容性，性能方面的事，不过相对的，为了性能优化而优化就变得很少见了，我至今还记得 票牛当时的后台ng部分打包20+m呢 ，而大部分表格上的问题倒也是通过防抖，埋key，自动隐藏什么的操作解决了，其实也不太关心了
# 关于ssr，前端性能优化的看法
# 前端脱离不了的本质
无论再怎么花里胡哨的打包，加载，性能优化，输出，最后都是浏览器进行处理，所以优化到最后，其实还是对浏览器特性的一种补充，最终优化过程只有这几个方面
# 请求包相关，大小数量以及下载速度
一方面是浏览器下载线程的限制并发量，我们不能太多文件，一方面是下载用时等于前端不可用时间，这对体验影响巨大，这方面几个常用的
- cdn，打到不同域名来规避单个域名下请求限制，同时选择近的机房提高下载速度
- 懒加载，减小包大小，需要时下载
- 预加载，空闲时事先加载，靠缓存来减少时间
- ssr，服务器访问接口因为内网的关系会更快一些
- 预渲染，和ssr类似，省去本地再去请求的时间
- inline，一样，埋在html中省去请求时间
# 单线程和回流重绘
js的最大问题在于单线程，好处是省心，坏处是实际上只能单独做一件事，同时，浏览器重绘的时候，影响的区域越大，效率越低，所以说优化方案不外乎
- webworker，将一些计算和无关逻辑扔在另一个线程去做
- 操作时间分片，这个等facebook吧，简单来说就是合理统计，任何计算市场在一个requestAnimate中完成，不影响cpu计算绘图
- gpu渲染，canvas，transform这种都是gpu计算的，减少cpu压力
- 减少回流，简单来说就是尽量不要改位置。搞的话要单独加一个z-index，回流会触发周围的元素也回流和重绘，区域大了不好
- 减小重绘区域，重绘区域里的dom元素越少越好，遮盖，隐藏，只显示可视区域就行
- 代码优化，开发的时候就应该可以看出来的一条，增大数据量看看那些循环啊，连锁计算的耗时吧，这个需要想更高效的算法
- 防抖，节流，减少事件的量
# 高并发
高并发在中台比较少见，但是在前台，因为用户量的问题，会非常明显，对于前端来说，依旧是基于浏览器和服务器的特性，做到限流和提高性能
# 提高性能
这方面做的很多
- 买更好的服务器
- 升级到很好的库
- 优化算法
- 利用缓存
# 限流
减少单位时间内的处理量，让服务器喘口气
- 网关限流
- 请求端随机请求失败
- ssr等服务降级为csr，压力扔给客户端和cdn
- 提高cdn的量
# 关于ssr
其实和csr一样的都是spa应用，区别在于
- 这一次扔回去的是已经渲染好的html，减少了白屏
- 当前的应用状态通过window对象传递了下来
- 只有node环境没有dom环境了，所以生命周期不能乱用
实际上本质还是一样的，html代码和对应的vdom等数据都还是框架生成的，在浏览器解析之前都是字符串，只不过那些框架运行后的运行状态数据是直接用js传递下来的而不是本地运行后生成而已
# 关于数据
其实个人之前并没有太关心制作的网站的运营数据，那时候精力更多的放在兼容性上了，像是服务，页面访问这种，直接都是接了提醒工具 在挂了或者报警的时候看一下和重启，现在想想虽然在那个时候的量级下，除了大型活动会扩容，但是却失去了通过数据调优的好处了
将各类优化都放在反馈之后，其实也是一种非常不专业的表现
虽说，过早地优化没有意义，但是被推着优化更容易打乱节奏
这也是目前我所担心的事，大并发，优化实操的经验经历实在是太少了