前端静态资源请求和加载优化总结

如果有这样一个项目，js脚本数量100+，其中50个是各种框架或库，css数量20+，图片若干 。那么，不用说，这个页面加载起来，一定快不了。 静态资源的请求和加载速度，直接影响页面呈现，应该怎么优化呢？ 一、不请求 - cache 最好的方式就是尽量引用公共资源，同时设置缓存，不去重新请求资源 也可以运用PWA的离线缓存技术，可以帮助wep实现离线使用 从策略上说，如果业务类型允许的话，可以做某些降级。比如，弱网优先使用缓存文件。网络状况分为 WiFi、4G、3G、2G、unknown ，其中 2G和unknown 被我们认为是弱网。先保证体验，再保证更新 避免资源属性为空或者错误。当、标签的 href 无效，或 淘宝的Combo Handler和新浪微博的link标签includes属性 Combo Handler是Yahoo!开发的一个Apache模块，它实现了开发人员简单方便地通过URL来合并JavaScript和CSS文件，从而大大减少文件请求数。 淘宝CDN支持Combo Handler，用逗号分隔js/css，用两个问号来触发combo特性： - http://a.tbcdn.cn/??a.js,b.js - http://a.tbcdn.cn/subdir/??a/js,b.js 用一个问号来添加时间戳，如： - http://a.tbcdn.cn/??fp/directpromo.js?t=2012062320120712 微博2012年在head里为link标签引入了includes属性，并用自家js解析。 三、合并和拆分资源 打包有很多方式，比如使用工具webpack、rollup，可以实现打包js，打包小图片至js（内嵌base64） 生成雪碧图，甚至把项目打包为单个html文件 拆分则是把开发时使用的库，单独剥离出来，以公共资源的方式引入 还有就是要把过大的包，拆分成多个较少的包，防止单个资源耗时过大 四、压缩资源 前端打包时压缩 服务器上开启gzip压缩，HTTP传输过程中的再次压缩 客户端：通过Accept-Encoding头来声明浏览器支持的压缩方式， 服务端：通过content-Encoding来启用压缩，配置压缩的文件类型，压缩方式。 （当客户端的请求到达服务器，服务器对资源进行压缩后，返回给客户端，客户端按照相应的方式进行解析） 客户端（HTTP请求头）——accept-encoding: gzip, deflate, sdch, br 服务器（HTTP响应头）——content-encoding: gzip 图片压缩（比如tiny），使用webp等高压缩比格式 尽量保证页面的 HTML 内容在 1KB 以内，这样整个 HTML 的内容请求就可以在一个 RTT 内请求完成，最大限度地提高 HTML 载入速度。通常情况下，TCP 网络传输的最大传输单元（Maximum Transmission Unit，MTU）为 1500B 五、静态资源分域存放 从不同域名请求资源。因为大多数浏览器的并发数量都控制在6以内，同一时间针对同一域名下的请求有一定数量限制，超过限制数目的请求会被阻塞。如果资源来自于多个域下，可以增大并行请求和下载速度。 六、延迟、异步、预加载、懒加载 对于非首屏的资源，可以使用 defer 或 async 的方式引入 也可以按需加载，在逻辑中，只有执行到时才做请求 对于多屏页面，滚动时才动态载入图片 对于移动端首屏加载后可能会被使用的资源，需要在首屏完成加载后尽快进行加载

本文章由javascript技术分享原创和收集