责任编辑意在重新整理常用Web后端操控性强化的路子，可供后端开发参照。即使务求简化，局限于字数，因此仍未详细描述具体内容工作方案。
在那个操作过程中，有三个关键步骤可能将极为费时，三个是互联网服务的读取，另三个是应用领域程序内程序执行和DOM渲染。
而费时的减少会引致网页积极响应慢，雅雷，负面影响使用者新体验。
特别针对前述三种费时的情形，常用的强化路径有：
延长允诺费时；
减少异构化重画；
明显改善JS操控性。
1 延长允诺费时互联网服务是Web应用领域运转的此基础，明显改善互联网服务加载速率会明显明显改善后端操控性。
1.1 强化装箱天然资源整体准则： 减少或延后组件提及，以减少互联网损耗。
短序：
webpack
webpack-bundle-analyzer可视化分析工具
常用方法：
减小体积：减少非必要的import；压缩JS代码；配置服务器gzip等；使用WebP图片；
按需读取：可根据“路由”、“是否可见”按需读取JS代码，减少初次读取JS体积。比如可以使用import()进行代码分割，按需读取；
分开装箱：利用应用领域程序缓存机制，依据组件更新频率分层装箱。
其他方法：
雪碧图：每个HTTP/1.1允诺都是独立的TCP连接，最大6个并发，因此合并图片天然资源可以强化读取速率。HTTP/2已经不需要这么做了。
1.2 CDN加速整体准则： 通过分布式的边缘互联网节点，延长天然资源到终端使用者的访问延后。短序：
Cloudflare
AWS CloudFront
Aliyun CDN
常用方法：
加速图片、视频等大体积文件
1.3 应用领域程序缓存整体准则：
常用方法：可以通过设置HTTP Header来控制缓存策略，一般有如下几种。
强缓存
Expires：HTTP/1.0
Cache-Control：HTTP/1.1
协商缓存
ETag + If-None-Match
Last-Modified + If-Modified-Since
拿ETag举例，如果应用领域程序给的If-None-Match值与服务端给的ETag值相等，服务器就直接返回304，从而避免重复传输数据。
ETag示例：
如果几个配置同时存在，则优先级为：Cache-Control > Expires > ETag > Last-Modified。
1.4 更高版本的HTTP整体准则：使用高版本HTTP提升操控性。
短序：
HTTP/2
HTTP/2较HTTP/1.1最大的改进在于：
多路复用：单一TCP连接，多HTTP请求；
头部压缩：减少HTTP头体积；
服务端推送：主动推送CSS等静态天然资源。
其他方法：
HTTP/3
HTTP/3基于UDP，有很多方面的操控性改进，如多路复用无队头阻塞，积极响应更快。感兴趣的同学可参照Wiki。
1.5 Web Socket整体准则：解决HTTP协议无法实时通信的问题。
Web Socket是一条有状态的TCP长连接，用于实现实时通信、实时积极响应。
1.6 服务器端渲染（SSR）整体准则：第一次访问时，服务器端直接返回图形好的网页。
一般流程：
应用领域程序向 URL 发送允诺；
服务器端返回“空白”index.html；
应用领域程序不能呈现网页，需要继续下载依赖；
读取所有脚本后，组件才能被图形。
SSR流程：
应用领域程序向 URL 发送允诺；
服务器端执行JS完成首屏图形并返回；
应用领域程序直接呈现网页，然后继续下载其他依赖；
读取所有脚本后，组件将再次在客户端呈现。它将对现有View进行合并。
短序：
Node.js，用于服务器端执行代码，输出HTML给应用领域程序，支持所有主流后端框架
Next.js，用于服务器端图形React的框架
gatsby，用React生成静态网站的工具
除了可以提升网页使用者新体验，还能应用领域于SEO。
2 减少异构化重画除了互联网服务以外，另三个负面影响后端操控性的因素就是后端网页的图形绘制效率。
虽然不同的后端框架有一些差异，但整体的强化路子是一致的，这里将以React举例。
2.1 减少图形量整体准则：不图形未展示的部分。
短序：
react-window
react-loadable
JS原生，如IntersectionObserver
框架提供，如React.lazy、react-intersection-observer
常用方法：
虚拟列表：只图形可见区；
惰性读取：无限滚动；
按需读取：网页只在切换过去时才读取。
以虚拟列表举例，以下是使用react-window库，仅仅图形了可见区的数据：
整体路子：避免重复的图形。
短序：
lodash
JS或框架自带
常用方法：
防抖与节流；
对于React函数组件来说，合理使用副作用，拆分无关联的副作用；
对于React类组件来说，可以使用shouldComponentUpdate或使用PureComponent来强化图形；
利用缓存，如React.memo；
使用requestAnimationFrame替代setInterval执行动画。
3 明显改善JS操控性即使应用领域程序是单线程异步模型，长时间的运算会阻塞图形操作过程，因此明显改善复杂运算有助于明显改善后端的整体操控性。
3.1 缓存复杂计算整体路子：避免重复计算。
常用方法：
对于React函数组件来说，可以使用useMemo缓存复杂计算值。
举例如下，memoizedValue需要经过复杂计算才能得到，此时就可以使用useMemo缓存，仅仅在输入参数发生变化时才重新计算，避免计算阻塞网页渲染，从而避免网页雅雷。
const MyFunctionalComponent = () => {
const memoizedValue = useMemo(() => {
computeExpensiveValue(a, b);
}, [a, b]);
return
但useMemo自身也有操控性消耗，需要视情形使用，某些场景可以利用React的图形机制避免操控性问题。
3.2 Web Worker整体准则：多线程思想。
常用方法：
Dedicated Workers，处理与UI无关的密集型数学计算：大数据集合排序、数据压缩、音视频处理；
Service Worker，服务端推送，或者PWA中配合CacheStorage在后端控制缓存天然资源；
Shared Worker，Tab间通信。
JS语言在设计之初就是单线程异步模型，好处是可以高效处理I/O操作，但坏处是无法利用多核CPU。
Web Worker会启动系统级别的线程，可进行多线程编程，发挥多核的操控性。
3.3 Web Assembly整体准则：将复杂的计算逻辑编译为Web Assembly，避免JS类型推断操作过程中的操控性开销，可用于操控性的极限强化。
适用范围有限：
曾在网上看到，有人使用自顶向下非强化的斐波那契数列算法来举例，说Web Assembly比原生JS快一倍，实测之后似乎也没有。
在同一台机器测试，其中求第48个值的费时如下：
C（Ubuntu+GCC）：18s
JS（V8）：32s
Web Assembly（V8+EMCC）：39s
一种可能将的猜想是，斐波那契计算中没有大量的类型推断，而且V8内部有一些强化机制，使得此处JS执行速率快于Web Assembly。
简而言之，并非所有场景都适用于Web Assembly。
另一种运用场景是，把不同语言编写的代码（C/C++/Java等）编译为Web Assembly，能以接近原生的速率在Web中运转，并且与JS共存。
总结引致后端操控性问题的因素是多方面的。
如果是后端天然资源读取慢，引致网页慢，则应该考虑如何延长允诺费时。而如果是后端网页逻辑笨重，UI数据量太大，则可以试着从减少异构化重画的角度去强化。对于耗时长的复杂计算，缓存计算结果往往是见效较快的强化方式。
最后需要注意的是，在实际应用领域开发操作过程中，即使受局限于开发成本，因此需要平衡强化所花的代价与其对应产生的成效。可以有特别针对性地对操控性瓶颈进行分析和处理，同时也需要避免引入不必要的强化措施，以确保最终强化效果。
– 相关阅读 –
