前端效能的超牛概述
就是希望用户尽量只下载必要的资源、尽量提早让用户看到画面，而不需要等待全部的资源都下载执行完成才能看到画面
很实战的操作啊！先给看，一些可以交给异步的为啥要影响到用户的体验对吧？真的牛！
如何减少request带来的效能问题
- 减少request次数
本地开发的时候，加载都是分开加载的，request次数自然多. 部署到production的时候，Asset Pipeline全部用 rake assets:precompile 打包到一起自然request的次数就减少了. 还同时压缩了
- 压缩request大小
部署到production的时候 有各种gem会各自分工，分头去压缩，CSS 压缩是透过 sass-rails gem，而 JavaScript 压缩是透过 uglifier gem
总结：加载一个网页平均要搞定108个request，会低效到爆炸的. 所以必须解决.从本地部署到production的过程中，打包了分散的request，还用各种gem压缩了各类request的大小. 一下子提效能了啊
P.S. 在本地跑production模式时，修改任何 Ruby 代码，都需要重启 Rails. 修改任何前端代码，都需要重新编译 Asset Pipleline. 可以在本地看到production的效果，但是很麻烦的. 而纯本地模式，平常开发时代码都是随时编译的，效能低但是开发很方便，不用一直重启rails，改前端代码也是“实时编译”，慢但是不像production要一直“手动去启动编译”. 想想也合理，都部署到production了肯定是“不经常改的”“实用版的” 怎么会需要天天改动呢. 都是按需分配特征啊
问：在production模式下，修改任何 Ruby 代码，都需要重启 Rails？
答：因为production模式的全部代码都是“编译好了”直接用的状态，有任何修改是不会“自动编译再运行”，那是本地开发时才有的状态. 因为不自动，所以必须手动重启rails才会“显示新改的代码效果”，不重启就“改了个寂寞”啥效果都看不到哈哈哈
问：为啥要在本地运行production模式？
答：因为在本地模式 测试前端代码效能不准，要切换到production模式才能测出“准确”的前端代码效能. 为啥？因为本地跟production前端代码运行方法不同导致效能区别.
总结：因为以上种种因果，导致最后“逆天改命”强行在本地里测了“production模式”下的前端代码效能后，一定要把相关的改动以及一些新生成的文档砍掉，不然开发环境全乱套了哈
BTW 看到这个教程才觉悟到，本地开发很少需要rails s是一种温柔，啧啧啧
HTTP的提速功能
原来HTTP也有提速功能 两招1.压缩 2.缓存
这两招的手法都是在 HTTP Response 的header那会标明 “此处被gzip压缩过”的gzip这样浏览器就知道此处要“解压缩”才能看到内容 或 “此处请丢去浏览器的缓存”的cache-control: public 而且缓存还会给时限
会用gzip压缩 纯文字的档案
缓存则是针对 静态文档
冷知识：原来图片的格式PNG或JPG是压缩过后的格式啊 不用gzip来压缩的
感悟：很多代码的功能为何那样设计，其实都是历史上有实用需求而带着的特点。不论什么学科，其历史果然是最给力的部分啊...学清楚后一通百通啧啧啧
关键渲染路径
为了让用户能尽快看到一部分网页，有一种一切尽在掌握中的“把握感”. 把一些重要的部分拆分出来先呈现，剩下不用第一时间就立马起作用的部分就用“异步处理”
提效的思路大概就是这样 大同小异了
然后就是各种手法可能会引发的坑，讲讲背后原理，讲讲如何避坑
图示非常直观给力 一下子看出async 和 defer的区别
网友评论