6s到1s：双端应用秒级优化之路

背景最近，我们团队开始尝试用新的方案（双端开发，上线PC端和移动端）来解决前端资源紧缺的问题同时）。但是经过测试，测试指出我们的移动端页面首屏速度太慢（6s+），体验极差。我试着在PC上打开这个页面，用了4s+。加载瀑布流如下：粗略分析，存在以下三个问题：应用页面采用了懒加载策略，详见红圈区域；入口js，包体积太大，gzip后还有1.3M，原来大小是4M+日常静态资源未启用cdn优化三部曲1.应用架构优化在应用架构中，懒加载是一种常见的优化技术，其中可以只在需要的时候加载资源，减少应用启动时间和流量消耗。然而，懒加载并不是万能的，有时过多的懒加载会降低应用程序的性能。因此，在优化应用架构时，应该根据具体情况权衡是否使用延迟加载。瀑布流结合上图分析，资源加载时间为4s+，index.html的时间对于前端来说是不可控的，完全依赖于域名的解析和响应服务器。但是js和css的部分是完全可控的。我们可以提前500ms的资源加载时间，即去掉懒加载架构方案。2.包大小优化包大小优化是优化应用程序性能的重要组成部分。包的大小直接影响应用的加载时间和用户体验。看到1.3M的gzip包大小，我们第一反应是打开webpack的analyze查看包体积分布，结果完全超乎想象（这是开发模式，其他页面入口都有注释，只有一个pageoftheperiodmenureserved)：上图也很直观的暴露了几个问题：同一个chunk，同一个依赖多次进入（图中以cook-design为首，见下图）package的大小分布极度不均匀，分块不同导入同版本依赖（懒加载策略导致）项目依赖管理，防止多版本在项目依赖管理中，尽量避免多版本依赖。多版本依赖会导致包体积变大，甚至会产生冲突和错误。在日常业务组件的开发中，可以将对基础组件（如antd）的依赖设置为peerDependencies。我们的解决方案是将业务依赖的引入方式标准化，通过解析强制执行指定版本。组件库支持treeShaking。在使用第三方组件库时，通过treeShaking，可以只加载应用中需要的组件和功能，减少包体积和加载时间。以前我们在引入antd3的时候，为了防止包太大，我们引入了babel-plugin-import来帮我们去掉无用的代码。但是antd4遵守了es-module规范，配置了sideEffect，这使得它天生支持treeShaking。我们的项目在很大程度上依赖于当地生活的厨师设计和厨师设计/图标。由于缺少treeShaking的配置，这两个组件已经全部打进去了，冗余组件和冗余组件带来的依赖在5M左右。所以我们和相关维护者交换了相关想法后，他们同意增加配置升级来支持treeShaking。我们团队自己的双端组件库cook-design-mixin也支持这种配置。经过优化应用架构，优化依赖版本，组件支持treeshaking，采用分包策略，我们的构建结果（生产模式）是这样的：Removinguselesscode优化一，我在文章开头提到，我们的项目是一个双端架构的项目，是编译时的方案，也就是说PC端和移动端是两套不同的资源。但是因为我们是在一个应用中开发，所以PC端的代码和移动端的代码是混在一起的。我们通过标准化和构建插件来解决代码混合问题。//下面是一个示例import{Decorator}from'@alife/wa-mixin-core';importDMobilefrom'./wa-mobile';importDDesktopfrom'./wa-desktop';exportdefault(props:{isShowTipStatus:boolean;showMode?:boolean;})=>{returnDecorator({Mobile:,Desktop:,});但通过代码分析，我们发现了以下两个问题：双端组件库前期编写的组件存在大量不规范的写法，导致插件无法摆脱另一端，导致pc端的代码进入到移动端（涉及太多，后续会专门做项目优化）由于业务代码是存量业务（这里指的是分发）菜品）转双端（前期已经开发上线PC端代码，移动端采用双端方案开发），出口不规范，导致暴增在包装尺寸。添加菜品分发入口后，构建结果如下，比上面单个入口多了2.3M（压缩后）：只剩下一个入口，构建结果如下：介绍页面如下结果引入了大量的cook-design和cook-design/icons，以至于我在考虑是对icon单独解包还是通过CDN导入。管理包入口后，构建包的大小有明显改善：经过gzip后，大小基本在1M左右（仍有提升空间）：3.网络请求优化网络请求优化是优化应用的另一个重要环节表现。在优化网络请求时，可以从以下几个方面考虑：使用combo减少请求数在前端应用中，通常需要加载多个JS、CSS、图片等资源文件，会产生大量的网络请求并影响应用程序性能。Combo技术可以将多个文件合并为一个文件请求，以减少网络请求次数，但这也需要服务器的支持。我们的应用模板引入了react、moment、babel-polyfill等，使用CDN作为外部依赖，但是为了减少请求量，使用了combo服务。使用http2多路复用提供请求效率http2支持多路复用，可以在一个连接上同时传输多个请求和响应，提高请求效率和传输速度。因此，在使用http2协议时，可以通过多路复用来优化网络请求。这就是为什么我们有上面划分多个数据包的策略，以最大限度地利用现代网络的带宽。等待队列优化分包依赖完成后，我们发现在加载js资源包时出现了明显的等待情况（如上图所示），而且稳定且反复出现。经过分析，我们发现脚手架提供的应用html模板有同步脚本引入。vconsole，从而阻止js资源的下载。减少DNS解析和TCP之间的握手时间。在排查等待队列问题时，我们还发现html模板中应用的一些外部依赖使用了非组cdn域名。在http1时代提倡这种方式，因为浏览器对单个域名的同时http连接有限制，所以为了增加并行请求数，会在同一个网页中使用几个CDN域名。但是http2，这就成了一个约束，使用外部cdn会带来安全隐患。以上策略全部执行后，在日常环境下，应用首屏稳定在1.5s左右。双端元件库按照规范调整后，这个数据可以快10%。开启CDN加速什么是CDN，相信大家应该都非常了解了。在我们的应用上线之后，静态资源终于得到了cdnmagic的加持。我们launchapp客户端秒开页面，体验极佳：综上所述，首屏优化是前端经久不衰的话题，方法丰富，细节也多。应用架构优化、报文量优化、网络请求优化是优化前端应用性能、提升用户体验的关键。本文由ChatGPT起草，由工作人员处理。