网页无法访问公司内网,排名优化公司哪里有,广州网站建设代理,今傲网站做的怎么样本文可能涉及的内容--项目介绍整个项目大概有60个页面#xff0c;用到的组件大概150#xff0c;package里面的依赖大概有70个#xff0c;应该勉强算得上是一个中型的React的项目了。下面给大家看看我们现在build一次项目的结果--打包时间约150s#xff0c;打包完之后的资源…本文可能涉及的内容--项目介绍整个项目大概有60个页面用到的组件大概150package里面的依赖大概有70个应该勉强算得上是一个中型的React的项目了。下面给大家看看我们现在build一次项目的结果--打包时间约150s打包完之后的资源gzip之后约1.2m尽管之前分离了一些公用依赖但是index包的体积达到了600还是令人难以接受的。需要解决的问题 思考过的方案开始优化之前最重要的就是搞清楚我们到底要优化什么。确定了优化的目标才能着手思考优化方案进而实施优化方案。结合对项目的bundle分析以及自身对项目的了解我们初步可以定出以下几点优化方向--① 体积瘦身首先我们需要足够了解我们的项目才能着手进行瘦身。在这里有一个很给力的工具可以推荐给大家webpack-bundle-analyzer盗用一下github上的图如图所示我们可以很清晰的看到每个js文件里的module组成还可以看到每个module的大小以及module的组成成分这对我们分析代码冗余以及优化方向都能够提供很大的帮助。具体食用方式也很简单--这样一来我们就对项目有了一个比较具体的认识大到项目的依赖一览小到某个页面的组件引用都能在分析报告中找到。接下来就可以开始我们的瘦身之旅了。打团先找大哥当我们第一次看到bundle的分析报告时总能找到一些出乎意料的“大个子”如果是必不可缺的依赖则没办法但如果是一些可以被取代的依赖就有别的说法了。这里刚好可以看看之前我对create-react-app中moment.js依赖的处理如果处理顺利的话可以很直观的看到bundle大小的变化。总结来说如果有小的并且满足需求的依赖可以替换请不要迟疑但如果没有可满足的依赖可以尝试自己造一个轮子当然后者需要结合自身状况考虑。分散站位相信大家在开发网站的时候都用到了不少依赖但是这些依赖在输出之后是和业务代码打包在一起的这个明显不符合我们的预期。面对这些基本不会变更的依赖我们更倾向它们能够主动抱团并且远离我们的业务代码。这时候就该使用webpack的CommonsChunkPlugin貌似在wp4中已经被别的插件替代了在此我们先不讨论wp4它可以帮助我们将一些指定的module打包进指定的bundle里。具体使用方案可以参考wp官网中的相关介绍有一个坑点就是--倘若希望负责集合依赖bundle的文件名在打包时不变则需要生成manifest。不要将页面都放到一个篮子里一-- 页面分离我们可以将一些低频页面彻底拉出项目拿我们的项目来说一共60个页面用户大多都是只会访问其中的几个或十几个页面不可能将所有的页面都访问一遍。这样一来就必然会有一些页面的访问频率相比之下会十分低下该怎么处理这些页面呢这里有几种方案脱离框架重写相关页面并重新部署Copy项目代码在其他地方重新跑一次并部署原项目就可以删除不需要的页面上一方案的简化版复刻项目环境跑一个新的纯净项目并部署将原项目低频页面“剪切”到新的项目中以上三种方案个人觉得各有优劣第一个方案很简单适用场景就是类似QA的静态页可以将其脱离项目写成静态页部署在其他的地方但是不好的地方就是可能没法复用原项目组件。方案二呢则是时间至上的方案可以做到快速迁移但是不好的地方在于迁移出去的页面其实还是塞在一个篮子里只不过换了个新的篮子罢了。方案三则是质量至上的方案以时间作为成本换来一个新的“低频页面项目”。具体要使用哪种方案我觉得也是根据当前项目状况而定不追求最完美追求最合适。② 首屏加载首屏加载大概是优化的永恒话题所有的优化都避不开这一个话题因为只有它能最直观的让“大家”都感受到我们这次优化的成果。对于用户来说认为网页首屏很快的标准其实很单一就是一打开页面看了多久的白屏。所以我们需要做的就是弱化用户对白屏的感知围绕这一点个人认为首屏加载这一优化可以有两个方向一个是速度另一个是体验。引入加载占位其实这个就是前段时间很火的“骨架屏”我们可以在页面真正被渲染出来之前先给用户看到一个“假的”页面,等到某个时间节点例如数据已经准备完毕...就将真正的内容替换上去。这里有一个我写的很不走心的例子:)在这个优惠券列表页面我的处理方案是初始化页面的时候就渲染3个列表项骨架等待接口数据返回就将真实内容替换上去。在我们的首屏其实也是类似的我们可以根据首屏的展示结构做一个匹配的骨架组件然后按需求进行展示即可这样可以有效减少用户看到白屏的时间。下面是我这个骨架的代码优化的空间很大不过由于优先级不是很高所以就没有进行迭代了。大概结构就是这样样式方面很粗暴因为每一项都是独立的一个组件直接可以用absolute定位堆砌一个简洁的占位列表项。里面那个类似进度条的效果则是通过css3的animation实现的我们可以将每个block的背景色变成渐变的然后通过background-positon的变化来达到图中的效果。图片懒加载这应该是个老生常谈的优化方向了原理大概是将视图之外的图片都用同一个占位图进行占位将其真正的图链接存在data-*中通过监听滚动来判断图片是否进入视图中来控制img标签src的值。具体的实现很多地方都能搜到大家可以根据自身情况按需选择。不要将页面都放到一个篮子里二-- 懒加载其实在整个优化过程中我的重心是放在这个地方的其他的都是半路上想到的...让我们回想一下上面我们讲过将低频页面分离那么必然就有会那么几个访问量十分高的页面那么对于这几个页面应该怎么办呢因为访问频率高所以我们可以认为这些页面与我们的核心业务是强相关的所以将其分离就显得不那么划算了很可能会出现维护多套代码的窘况。但是这样高频页面才是优化的重点区域呀应该怎么办呢面对这样页面我们还是可以使用懒加载大法页面懒加载 || 组件懒加载 || 依赖懒加载。想要在js层面实现各类懒加载我们都需要借助webpack中的特性Code Splitting它可以将我们本来打包在一起的js分解成一块一块并能达到按需加载并使用的效果。页面懒加载因为我们使用了react-router所以我们可以使用react-router的getComponent轻松达到页面懒加载这一需求。如下图所示将mainpage这样引入route的话在打包的时候会将其分离成一个独立的js。组件懒加载 依赖懒加载组件和依赖的懒加载也是十分简单的如下图这样写就能达到懒加载的效果但如果我们使用了babel则需要修改一下babel的配置让它能够顺利解析动态import()的语法。③ 打包提速我们通常的优化都是为了用户而优化但其实为了我们自身能够良好的开发体验也应该为开发人员优化优化开发体验打包优化则成了不二之选。使用DLL为打包保驾护航由于时间原因在公司的项目中并没有尝试使用DLL但是看到网上有不少同学都推荐介绍了它所以我选择在此提及一下~有关于webpack DLL的文档将webpack版本从2.0 -- 4.x由于项目是在差不多一年多以前正式启动的所以接手的时候是webpack1.x在刚接手的时候为了懒加载硬是升级到了2.x。但是到现在发现2.x好像也不够用了毕竟已经落下了两个大版本了更新之后的新特性、新功能或是新优化都应该成为我将项目迁移至新版本的动力。wp4具体的配置细节在掘金上就见到过挺多同学介绍的这里我想介绍一下我是怎么将旧项目迁移到wp4的在开始进行版本迁移之前我设想了两个方案一个是在原有项目上直接升级并修改配置第二个方案是新建webpack4项目搭建好之后将业务代码迁移过来。经过对成功率以及时间成本的评估我最后选择的是第二个方案。那么这个新建的项目应该完善到什么程度才能进行迁移呢我个人是经过以下几个步骤--搭建项目骨架这回的项目和之前的都不太一样了我们没有借助大神们的脚手架来搭建项目骨架了我们需要自己从零开始一点一点的摸索webpack的用法以及新旧版本的差异。关于一些基础的知识以及配置十分推荐查阅webpack官网的文档以及一些之前参考过的文章webpack4-用之初体验、webpack 4.0.0-beta.0 新特性介绍。相信大家看完这些之后都会对wp的配置有基本的认知紧接下来就是建目录、装依赖巴拉巴拉。最终我们会得到一个这样的目录结构--写个Hello World!我们应该如何判断将项目代码迁入新项目的时机呢很简单当这个新项目可以正常的调试或打包一个相应框架的Hello World即可。拿我们的项目来说搭建完项目目录以及一些基础配置之后接下来就是完全模拟原有项目的技术栈在新的项目中写几个简单的demo页。当然这些demo页并不是随便写的是带有目的性的按我这次的经历来说我写了这么几个文件index.js、App.js、Hello.js、Global.scss、router.js。剥开非核心依赖我们最核心的依赖其实就是react react-router sass只要webpack能够正确的解析es6和sass我们就能很大程度的还原旧项目的环境。babel中与jsx相关的配置在package里仔细研读package上面的demo完成之后我们新项目就初具雏形了接下来我们就需要将旧项目package.json迁移到新项目中这里需要注意的几点是① scripts中的指令要注意我们要看里面的每条指令分别有什么作用然后再思考应该怎么在新项目中写一个功能一样的指令。② dependencies devDependencies旧项目的依赖也应该无缝迁移过来不过我们可以趁这个机会把没有用到的依赖剔除出去。③ babel || autoprefixer等辅助工具的配置也应该与旧项目保持一致。迁移项目修修补补上述步骤都跑通之后就能删掉原有的demo将旧项目的所有业务代码都迁移过来。接下来就看着报错一个一个修复即可。这里遇到这么几个坑困扰了我许久。页面很顺利的迁移过来了依赖补全之后也顺利的跑起来了。但是在dev环境下切换页面老是会404。相信大家看到这里就懂了我用了history模式的路由在devServer中应该要加上这样一行配置devServer {historyApiFallback: true
}
复制代码好啦404消灭之后又有新的状况了静态资源老是引用不到这是为啥其实这是因为我们在output的时候没有设置publicPath引起的在dev的webpack.config中我的output是这样配置的output: {path: path.resolve(dist),publicPath: /
},
// ...
devServer {contentBase: ./dist,port: 9000,historyApiFallback: true
}
复制代码这个问题解决之后我们的开发环境算是还原的差不多了。接下来就该踩踩打包的坑了我遇到的第一个问题就是打包完成之后文件夹里面只有打包输出index.html咋不见了...这说好的不太一样。后面发现是少了copy-webpack-pluginconst CopyWebpackPlugin require(copy-webpack-plugin)
const config {// ...plugins: [new CopyWebpackPlugin([{from: public, to: }])]
}
复制代码加上这个依赖之后我们public文件夹的内容就会乖乖的在dist里面出现。但紧接着又出现新的问题了第二次打包的时候怎么dist没有被清空呢和上面一样年轻的我少用了一个插件clean-webpack-pluginconst CleanWebpackPlugin require(clean-webpack-plugin)
const CopyWebpackPlugin require(copy-webpack-plugin)
let cleanOptions {root: path.join(__dirname, ..),verbose: true,dry: false
}
const config {// ...plugins: [new CleanWebpackPlugin([dist], cleanOptions),new CopyWebpackPlugin([{from: public, to: }])]
}
复制代码完成上述配置后每次打包webpack都会清空dist文件夹并且在打包完成之后将public中的内容复制到dist。好了看来应该可以了但是在本地开了个服务器跑页面的时候发现各种静态资源404。这又是什么玩意实话说在这里踩坑时间是最多的但是解决方案又是令人窒息的简单...都怪自己没有好好看文档const CleanWebpackPlugin require(clean-webpack-plugin)
const CopyWebpackPlugin require(copy-webpack-plugin)
let cleanOptions {root: path.join(__dirname, ..),verbose: true,dry: false
}
const config {output: {filename: static/js/[name].[chunkhash:8].js,chunkFilename: static/js/[name].[chunkhash:8].chunk.js,publicPath: http://localhost:5000/ // !!!这里一定要使用绝对路径不然就会被坑到}// ...plugins: [new CleanWebpackPlugin([dist], cleanOptions),new CopyWebpackPlugin([{from: public, to: }])]
}
复制代码总结好了不知道有多少同学会看到这里先谢谢大家看我在这唠叨一堆~各类优化的方案在网上看了好多好多但是好像大家都只讲方案没有涉及实践等到自己真正去玩的时候才发现其实优化没有想象中那么简单要兼顾原有的又要尽量使用更新更好的很多时候都会在夹缝中取舍。对了好像忘记放懒加载优化后的图了还是wp2打包的效果可能没有想象中那么理想吧但也算往前踏出很不容易的一步了:)其实能够优化的还有很多很多请求方面、业务方面甚至是代码写法...都是可以优化的但是这些怎么能一蹴而就呢还是得走一步看一步选择最适合自家项目的优化方案才是最佳方案~
