是不是觉得可以开干了！来思考一个问题，你的页面现在的问题到底在哪？是什么东西影响了这些指标，是否有可衡量的工具？
性能监测
拿到一个有问题的项目的时候，可以从以下几个角度初探问题所在：
有没有没有用的接口仍然在调用；
有没有加入非常大的第三方包没有走CDN；
有没有并发请求阻塞资源的加载，比如一个页面调了十几个接口；
有没有非常大的业务资源因输入没有控制，导致有超常规大小的业务资源；
…
这些问题是我在大型项目开发中遇到过的，因为它有一个非常响当当的名字叫“历史遗留问题”，所以很容易成为钉子户。
浏览器是有自带一个 Performance 面板，具备可视化功能。但是你要知道什么人更加看重这个数据，同时这些数据也不利于分享，最最重要的是它无法自动的随时随地、不间断的进行监视、测量。所以通常都会有自研的 SDK 去获取 window.performance 下的数据进行二次处理后做更加深层次的可视化。有用的可视化数据会推动建立长期关注性能的团队文化。
性能优化的底层逻辑
其实深入思考一下就知道，性能优化的环节无非网络加载、渲染优化、文件优化、用户体验层面。其实什么 DNS、CDN、TCP、各级缓存、Gzip压缩、代码压缩混淆啊什么的基本上在架构层都考虑到了，一劳永逸的事情，几乎不需要你操心！用户体验上加个loading、进度条、骨架屏什么的也都是通用解决方案。
你总在思考解决方案的无非这三种情况：
在整个链路中减少中间环节：比如将串行改成并行。 尽可能的预加载、预执行、懒加载 渐进式、分片段
SSR 值不值得
SSR 是当用户第一次请求页面时，由服务器把需要的组件或页面渲染成 HTML 字符串，然后把它返回给客户端。
通常人们考虑 SSR 方案时都是奔着解决 CSR 下的 SEO 问题以及首屏加载速度过慢的问题。这里我们主要考虑性能。大家思考一下直出方案到底优化的是哪部分的时间？省去的是 **前端渲染 **以及 **ajax请求 **的时间吧！因为它把所有的计算都放到服务端了。
但是 html 会比 CSR 的文件大吧！！！同时距离服务端远的用户也是会有比较长时间的白屏的！
离线包还是 PWA
所以通常移动端又会通过离线包技术去解决 html 本身文件加载时间的问题。离线包的基本思路就是通过 web view 统一拦截 URL，将资源映射到本地离线包，更新的时候对版本资源检测、下载和维护本地缓存目录中的资源。比如腾讯的 webso 和 Alloykit 的离线包方案。离线包是对 web 端而言相对透明、侵入性非常小的方案。
PWA 是通过纯 web 的方案去加速和优化加载性能。其通过 cacheStorage 缓存静态资源。
但在传统的 http cache 方案下，我们一般不会缓存 HTML。这是因为 CSR 的 html 是一个空壳，我们一般会设置比较大的 max-age，这样在浏览器缓存过期时间内，用户看到的永远将是旧的页面。
而对于直出 HTML，配合PWA，将从后台直出的 html 文件缓存到 cacheStorage 中，在下一次请求时，优先从本地缓存中获取，同时发起网络请求更新本地 html 文件。
接着又会发现有新的问题，就是第一次启动时加载 html 资源还是费时间的。可以通过 app 端上支持预加载一个JS 脚本，拉取需要 PWA 缓存的页面，提前完成缓存！
对于前端而言，PWA 无疑会是更好的解决方案，但是 PWA 不是万能的，它有兼容性问题。比如只支持https。
另离线包方案和 PWA 方案本身是可以有一个数据 PK 的。其实很多同学都是上了PWA，但从来没想过如果尝试把它拿掉，数据是否会有变化。
SSR 的成本
现阶段我们知道的解决方案都是基于 Node 的，也就意味着要上 SSR 必须得有 Node 中间层。也即意味着你需要有能够 hold 住 node 运维及架构能力的人力，还有服务端等硬件成本。同时因为服务端渲染的差异性，也会出现客户端正常而服务端异常的情况。前后端分离可能会出现平滑发布的问题：当页面的静态资源(js、css)的发布不是与后端一起发布时，可能引起后端返回的 HTML 内容与前端的 JS、CSS内容不匹配的问题。如果没做兼容处理，可能会出现样式错乱或者 document 选择器找不到元素的问题。
所以加上SSR到底值不值得，小马过河！通常我们建议首屏渲染体验和 SEO 的优化方案有很多，不到万不得已不要用 SSR。
NSR
如果说 SSR 放到服务器端成本比较大，那有没有可能放到客户端来。借助浏览器启用一个JS-Runtime，提前将下载好的 html 模板及预取的 feed 流数据进行渲染，然后将 HTML 设置到内存级别的 MemoryCache 中，从而达到点开即看的效果。
这是一种将后台请求压力分发到各个客户端中的方案，同时因为客户端有数据预取和预加载，速度也能达到秒开。但是又有一个问题，预加载意味着你得是个算命先生！
ESI (Edge Side Include)
更重要的是如果是首跳页面，什么预加载，预执行，预渲染都旁边呆着去吧！除了服务端和客户端，我们是不是还有一个地方可以放资源，对了，就是代理端，比如 CDN。
CDN 比服务端距离用户更近，有更短的网络延时。在CDN节点上将可缓存的页面静态部分先快速返回给用户，同时在CDN节点上发起动态部分内容请求，并将动态内容在静态部分的响应流后，继续返回给用户。
首屏 TTFB 会很短，静态内容（例如页面 Header 、基本结构、骨骼图）可以很快看到。 动态内容是由 CDN 发起，相比于传统浏览器渲染，发起时间更早，且不依赖浏览器上下载和执行 js。理论上，最终 reponse 完结时间，与直接访问服务器获取完整动态页面时间一致。 在静态内容返回后，已经可以开始部分 html 的解析，以及 js, css 的下载和执行。把一些阻塞页面的操作提前进行，等完整动态内容流式返回后，可以更快地展示动态内容。 边缘节点与服务端之间的网络，相比于客户端与服务端之间的网络，更有优化空间。例如通过动态加速，以及 edge 与 server 之间的连接复用，能为动态请求减少 TCP 建连和网络传输开销。以做到最终动态内容的返回时间，比 client 直接访问 server 更快。
ESR 是需要借助 CDN 的边缘计算能力(保证了可以在CDN上做类似于service worker的操作，可对请求和响应做灵活的编程)，那如果 CDN 服务商不支持那就免谈啦！
用到什么加载什么
懒加载
一次不加载完所有的文件内容，提前做拆分只加载此刻需要用到的那部分 当需要更多内容时，再对用到的内容进行即时加载
路由级别：
require.ensure(dependencies, callback, chunkName)
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024c （备注前端）
最后
我可以将最近整理的前端面试题分享出来，其中包含HTML、CSS、JavaScript、服务端与网络、Vue、浏览器、数据结构与算法等等，还在持续整理更新中，希望大家都能找到心仪的工作。
篇幅有限，仅展示部分截图：
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
https://img-blog.csdnimg.cn/img_convert/c6265dc2681708533916a8d7910506b3.png)
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！ [外链图片转存中…(img-XOL7jPhy-1712585787096)]
文章链接
您阅读本篇文章共花了：
发表评论