多语言网站源码,全面的上海代理注册公司,姜堰网站开发,用jsp做网站的代码作者#xff1a;张云龙链接#xff1a;https://www.zhihu.com/question/20790576/answer/32602154来源#xff1a;知乎著作权归作者所有。商业转载请联系作者获得授权#xff0c;非商业转载请注明出处。没人邀请#xff0c;看到这个问题不错#xff0c;路过怒答。#x…作者张云龙链接https://www.zhihu.com/question/20790576/answer/32602154来源知乎著作权归作者所有。商业转载请联系作者获得授权非商业转载请注明出处。 没人邀请看到这个问题不错路过怒答。多图预警 前百度工程师曾负责百度 前端集成解决方案 的核心设计与开发工作。我现在称这个领域为【前端工程】。没错这是我最爱唠叨的问题域。 这是一个非常有趣的 非主流前端领域这个领域要探索的是如何用工程手段解决前端开发和部署优化的综合问题入行到现在一直在学习和实践中。 在我的印象中facebook是这个领域的鼻祖有兴趣、有梯子的同学可以去看看facebook的页面源代码体会一下什么叫工程化。 接下来我想从原理展开讲述多图较长希望能有耐心看完。 ---------------------------- 我是一条分割线 ---------------------------- amp;amp;lt;img srchttps://pic2.zhimg.com/07c2bdef6ccef3ada425d61e3062dd09_b.jpg data-rawwidth389 data-rawheight238 classcontent_image width389amp;amp;gt;让我们返璞归真从原始的前端开发讲起。上图是一个“可爱”的index.html页面和它的样式文件a.css用文本编辑器写代码无需编译本地预览确认OK丢到服务器等待用户访问。前端就是这么简单好好玩啊门槛好低啊分分钟学会有木有 amp;amp;lt;img srchttps://pic1.zhimg.com/d53b504bbc9f1887eddf06d90545b870_b.jpg data-rawwidth400 data-rawheight98 classcontent_image width400amp;amp;gt;然后我们访问页面看到效果再查看一下网络请求200不错太™完美了那么研发完成。。。。了么 等等这还没完呢对于大公司来说那些变态的访问量和性能指标将会让前端一点也不“好玩”。 看看那个a.css的请求吧如果每次用户访问页面都要加载是不是很影响性能很浪费带宽啊我们希望最好这样 amp;amp;lt;img srchttps://pic1.zhimg.com/6a611755a5648ca252211cec85a31ac4_b.jpg data-rawwidth401 data-rawheight98 classcontent_image width401amp;amp;gt;利用304让浏览器使用本地缓存。但这样也就够了吗不成304叫协商缓存这玩意还是要和服务器通信一次我们的优化级别是变态级所以必须彻底灭掉这个请求变成这样 amp;amp;lt;img srchttps://pic3.zhimg.com/fd74ab2bf02d79dd7af1336b4c8f180e_b.jpg data-rawwidth400 data-rawheight98 classcontent_image width400amp;amp;gt;强制浏览器使用本地缓存cache-control/expires不要和服务器通信。好了请求方面的优化已经达到变态级别那问题来了你都不让浏览器发资源请求了这缓存咋更新 很好相信有人想到了办法通过更新页面中引用的资源路径让浏览器主动放弃缓存加载新资源。好像这样 amp;amp;lt;img srchttps://pic2.zhimg.com/8a8676e933478d1a73777d84a5de55f5_b.jpg data-rawwidth304 data-rawheight110 classcontent_image width304amp;amp;gt;下次上线把链接地址改成新的版本就更新资源了不是。OK问题解决了么当然没有大公司的变态又来了思考这种情况 amp;amp;lt;img srchttps://pic1.zhimg.com/4681f7131e777dc885bf66000580ca40_b.jpg data-rawwidth579 data-rawheight310 classorigin_image zh-lightbox-thumb width579 data-originalhttps://pic1.zhimg.com/4681f7131e777dc885bf66000580ca40_r.jpgamp;amp;gt;页面引用了3个css而某次上线只改了其中的a.css如果所有链接都更新版本就会导致b.cssc.css的缓存也失效那岂不是又有浪费了 重新开启变态模式我们不难发现要解决这种问题必须让url的修改与文件内容关联也就是说只有文件内容变化才会导致相应url的变更从而实现文件级别的精确缓存控制。 什么东西与文件内容相关呢我们会很自然的联想到利用 数据摘要要算法 对文件求摘要信息摘要信息与文件内容一一对应就有了一种可以精确到单个文件粒度的缓存控制依据了。好了我们把url改成带摘要信息的 amp;amp;lt;img srchttps://pic1.zhimg.com/5276595f41d6276e21e5bc1d25741680_b.jpg data-rawwidth588 data-rawheight310 classorigin_image zh-lightbox-thumb width588 data-originalhttps://pic1.zhimg.com/5276595f41d6276e21e5bc1d25741680_r.jpgamp;amp;gt;这回再有文件修改就只更新那个文件对应的url了想到这里貌似很完美了。你觉得这就够了么大公司告诉你图样图森破 唉~~~~让我喘口气 现代互联网企业为了进一步提升网站性能会把静态资源和动态网页分集群部署静态资源会被部署到CDN节点上网页中引用的资源也会变成对应的部署路径 amp;amp;lt;img srchttps://pic2.zhimg.com/0866cb58bcf349642d57a06b162e0d91_b.jpg data-rawwidth574 data-rawheight259 classorigin_image zh-lightbox-thumb width574 data-originalhttps://pic2.zhimg.com/0866cb58bcf349642d57a06b162e0d91_r.jpgamp;amp;gt;好了当我要更新静态资源的时候同时也会更新html中的引用吧就好像这样 amp;amp;lt;img srchttps://pic1.zhimg.com/16d6d6c32e52ef1d1a835fb2ed15f864_b.jpg data-rawwidth574 data-rawheight456 classorigin_image zh-lightbox-thumb width574 data-originalhttps://pic1.zhimg.com/16d6d6c32e52ef1d1a835fb2ed15f864_r.jpgamp;amp;gt;这次发布同时改了页面结构和样式也更新了静态资源对应的url地址现在要发布代码上线亲爱的前端研发同学你来告诉我咱们是先上线页面还是先上线静态资源先部署页面再部署资源在二者部署的时间间隔内如果有用户访问页面就会在新的页面结构中加载旧的资源并且把这个旧版本的资源当做新版本缓存起来其结果就是用户访问到了一个样式错乱的页面除非手动刷新否则在资源缓存过期之前页面会一直执行错误。先部署资源再部署页面在部署时间间隔之内有旧版本资源本地缓存的用户访问网站由于请求的页面是旧版本的资源引用没有改变浏览器将直接使用本地缓存这种情况下页面展现正常但没有本地缓存或者缓存过期的用户访问网站就会出现旧版本页面加载新版本资源的情况导致页面执行错误但当页面完成部署这部分用户再次访问页面又会恢复正常了。好的上面一坨分析想说的就是先部署谁都不成都会导致部署过程中发生页面错乱的问题。所以访问量不大的项目可以让研发同学苦逼一把等到半夜偷偷上线先上静态资源再部署页面看起来问题少一些。 但是大公司超变态没有这样的“绝对低峰期”只有“相对低峰期”。So为了稳定的服务还得继续追求极致啊 这个奇葩问题起源于资源的 覆盖式发布用 待发布资源 覆盖 已发布资源就有这种问题。解决它也好办就是实现 非覆盖式发布。 amp;amp;lt;img srchttps://pic4.zhimg.com/9b3a9df114d14a14130a70abf5733837_b.jpg data-rawwidth631 data-rawheight456 classorigin_image zh-lightbox-thumb width631 data-originalhttps://pic4.zhimg.com/9b3a9df114d14a14130a70abf5733837_r.jpgamp;amp;gt;看上图用文件的摘要信息来对资源文件进行重命名把摘要信息放到资源文件发布路径中这样内容有修改的资源就变成了一个新的文件发布到线上不会覆盖已有的资源文件。上线过程中先全量部署静态资源再灰度部署页面整个问题就比较完美的解决了。 所以大公司的静态资源优化方案基本上要实现这么几个东西 配置超长时间的本地缓存 —— 节省带宽提高性能采用内容摘要作为缓存更新依据 —— 精确的缓存控制静态资源CDN部署 —— 优化网络请求更资源发布路径实现非覆盖式发布 —— 平滑升级 全套做下来就是相对比较完整的静态资源缓存控制方案了而且还要注意的是静态资源的缓存控制要求在前端所有静态资源加载的位置都要做这样的处理。是的所有什么js、css自不必说还要包括js、css文件中引用的资源路径由于涉及到摘要信息引用资源的摘要信息也会引起引用文件本身的内容改变从而形成级联的摘要变化大概示意图就是 amp;amp;lt;img srchttps://pic3.zhimg.com/edf10bb428d39d721e36760a86d2641e_b.jpg data-rawwidth709 data-rawheight371 classorigin_image zh-lightbox-thumb width709 data-originalhttps://pic3.zhimg.com/edf10bb428d39d721e36760a86d2641e_r.jpgamp;amp;gt;好了目前我们快速的学习了一下前端工程中关于静态资源缓存要面临的优化和部署问题新的问题又来了这™让工程师怎么写码啊 要解释优化与工程的结合处理思路又会扯出一堆有关模块化开发、资源加载、请求合并、前端框架等等的工程问题以上只是开了个头解决方案才是精髓但要说的太多太多有空再慢慢展开吧。或者大家可以去我的blog看其中的一些拆解fouber/blog · GitHub 总之前端性能优化绝逼是一个工程问题 以上不是我YY的可以观察 百度 或者 facebook 的页面以及静态资源源代码查看它们的资源引用路径处理以及网络请中静态资源的缓存控制部分。再次赞叹facebook的前端工程建设水平跪舔了。 建议前端工程师多多关注前端工程领域也许有人会觉得自己的产品很小不用这么变态但很有可能说不定某天你就需要做出这样的改变了。而且如果我们能把事情做得更极致为什么不去做呢 另外也不要觉得这些是运维或者后端工程师要解决的问题。如果由其他角色来解决大家总是把自己不关心的问题丢给别人那么前端工程师的开发过程将受到极大的限制这种情况甚至在某些大公司都不少见 妈妈我再也不玩前端了。。。。5555 转载于:https://www.cnblogs.com/ping8388/p/6478218.html
