Vue 编码基础
2.1.1. 组件规范
2.1.2. 模板中使用简单的表达式
2.1.3 指令都使用缩写形式
2.1.4 标签顺序保持一致
2.1.5 必须为 v-for 设置键值 key
2.1.6 v-show 与 v-if 选择
2.1.7 script 标签内部结构顺序
2.1.8 Vue Router 规范
Vue 项目目录规范
2.2.1 基础
2.2.2 使用 Vue-cli 脚手架
2.2.3 目录说明
2.2.4注释说明
2.2.5 其他
开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
在开始介绍网络传输性能优化这项工作之前，我们需要了解浏览器处理用户请求的过程，那么就必须奉上这幅神图了：这是navigation timing监测指标图，从图中我们可以看出，浏览器在得到用户请求之后，经历了下面这些阶段：重定向→拉取缓存→DNS查询→建立TCP链接→发起请求→接收响应→处理HTML元素→元素加载完成。不着急，我们对其中的细节一步步展开讨论：
1.1.浏览器缓存
我们都知道，浏览器在向服务器发起请求前，会先查询本地是否有相同的文件，如果有，就会直接拉取本地缓存，这和我们在后台部属的Redis和Memcache类似，都是起到了中间缓冲的作用，我们先看看浏览器处理缓存的策略：因为网上的图片太笼统了，而且我翻过很多讲缓存的文章，很少有将状态码还有什么时候将缓存存放在内存（memory）中什么时候缓存在硬盘中（disk）系统地整理出来，所以我自己绘制了一张浏览器缓存机制流程图，结合这张图再更深入地说明浏览器的缓存机制。
这里我们可以使用chrome devtools里的network面板查看网络传输的相关信息：
（这里需要特别注意，在我们进行缓存调试时，需要去除network面板顶部的Disable cache 勾选项，否则浏览器将始终不会从缓存中拉取数据）浏览器默认的缓存是放在内存内的，但我们知道，内存里的缓存会因为进程的结束或者说浏览器的关闭而被清除，而存在硬盘里的缓存才能够被长期保留下去。很多时候，我们在network面板中各请求的size项里，会看到两种不同的状态：from memory cache 和 from disk cache，前者指缓存来自内存，后者指缓存来自硬盘。而控制缓存存放位置的，不是别人，就是我们在服务器上设置的Etag字段。在浏览器接收到服务器响应后，会检测响应头部（Header），如果有Etag字段，那么浏览器就会将本次缓存写入硬盘中。
之所以拉取缓存会出现200、304两种不同的状态码，取决于浏览器是否有向服务器发起验证请求。只有向服务器发起验证请求并确认缓存未被更新，才会返回304状态码。
这里我以nginx为例，谈谈如何配置缓存:
首先，我们先进入nginx的配置文档
$ vim nginxPath/conf/nginx.conf
在配置文档内插入如下两项：
etag on; //开启etag验证
expires 7d; //设置缓存过期时间为7天
打开我们的网站，在chrome devtools的network面板中观察我们的请求资源，如果在响应头部看见Etag和Expires字段，就说明我们的缓存配置成功了。
【！****！！特别注意！！！】 在我们配置缓存时一定要切记，浏览器在处理用户请求时，如果命中强缓存，浏览器会直接拉取本地缓存，不会与服务器发生任何通信，也就是说，如果我们在服务器端更新了文件，并不会被浏览器得知，就无法替换失效的缓存。所以我们在构建阶段，需要为我们的静态资源添加md5 hash后缀，避免资源更新而引起的前后端文件无法同步的问题。
1.2.资源打包压缩
我们之前所作的浏览器缓存工作，只有在用户第二次访问我们的页面才能起到效果，如果要在用户首次打开页面就实现优良的性能，必须对资源进行优化。我们常将网络性能优化措施归结为三大方面：减少请求数、减小请求资源体积、提升网络传输速率。现在，让我们逐个击破：
结合前端工程化思想，我们在对上线文件进行自动化打包编译时，通常都需要打包工具的协助，这里我推荐webpack，我通常都使用Gulp和Grunt来编译node，Parcel太新，而且webpack也一直在自身的特性上向Parcel靠拢。
在对webpack进行上线配置时，我们要特别注意以下几点：
①JS压缩：（这点应该算是耳熟能详了，就不多介绍了）
optimization: {
minimizer: [
new UglifyJsPlugin({
cache: true,
parallel: true,
sourceMap: true// set to true if you want JS source maps
}),
…Plugins
]
}
②HTML压缩：
new HtmlWebpackPlugin({
template: __dirname + ‘/views/index.html’, // new 一个这个插件的实例，并传入相关的参数
filename: ‘…/index.html’,
minify: {
removeComments: true,
collapseWhitespace: true,
removeRedundantAttributes: true,
useShortDoctype: true,
removeEmptyAttributes: true,
removeStyleLinkTypeAttributes: true,
keepClosingSlash: true,
minifyJS: true,
minifyCSS: true,
minifyURLs: true,
},
chunksSortMode: ‘dependency’
})
我们在使用html-webpack-plugin 自动化注入JS、CSS打包HTML文件时，很少会为其添加配置项，这里我给出样例，大家直接复制就行。据悉，在Webpack5中，html-webpack-plugin 的功能会像 common-chunk-plugin 那样，被集成到webpack内部，这样我们就不需要再install额外的插件了。
PS：这里有一个技巧，在我们书写HTML元素的src 或 href 属性时，可以省略协议部分，这样也能简单起到节省资源的目的。（虽然其目的本身是为了统一站内的所有协议）
③提取公共资源：
splitChunks: {
cacheGroups: {
vendor: { // 抽离第三方插件
test: /node_modules/, // 指定是node_modules下的第三方包
chunks: ‘initial’,
name: ‘common/vendor’, // 打包后的文件名，任意命名
priority: 10// 设置优先级，防止和自定义的公共代码提取时被覆盖，不进行打包
},
utils: { // 抽离自定义公共代码
test: /.js$/,
chunks: ‘initial’,
name: ‘common/utils’,
minSize: 0// 只要超出0字节就生成一个新包
}
}
}
④提取css并压缩：
在使用webpack的过程中，我们通常会以模块的形式引入css文件（webpack的思想不就是万物皆模块嘛），但是在上线的时候，我们还需要将这些css提取出来，并且压缩，这些看似复杂的过程只需要简单的几行配置就行：
（PS:我们需要用到mini-css-extract-plugin ，所以还得大家自行npm install）
const MiniCssExtractPlugin = require(‘mini-css-extract-plugin’)
module: {
rules: […, {
test: /.css$/,
exclude: /node_modules/,
use: [
_mode === ‘development’ ? ‘style-loader’ : MiniCssExtractPlugin.loader, {
loader: ‘css-loader’,
options: {
importLoaders: 1
}
}, {
loader: ‘postcss-loader’,
options: {
ident: ‘postcss’
}
}
]
}]
}
我这里配置预处理器postcss，但是我把相关配置提取到了单独的文件postcss.config.js里了，其中cssnano是一款很不错的CSS优化插件。
⑤将webpack开发环境修改为生产环境：
在使用webpack打包项目时，它常常会引入一些调试代码，以作相关调试，我们在上线时不需要这部分内容，通过配置剔除：
devtool: ‘false’
如果你能按照上述六点将webpack上线配置完整配置出来，基本能将文件资源体积压缩到极致了，如有疏漏，还希望大家能加以补充。
最后，我们还应该在服务器上开启Gzip传输压缩，它能将我们的文本类文件体积压缩至原先的四分之一，效果立竿见影，还是切换到我们的nginx配置文档，添加如下两项配置项目：
gzip on;
gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php application/vnd.ms-fontobject font/ttf font/opentype font/x-woff image/svg+xml;
【！****！！特别注意！！！】 不要对图片文件进行Gzip压缩！不要对图片文件进行Gzip压缩！不要对图片文件进行Gzip压缩！我只会告诉你效果适得其反，至于具体原因，还得考虑服务器压缩过程中的CPU占用还有压缩率等指标，对图片进行压缩不但会占用后台大量资源，压缩效果其实并不可观，可以说是“弊大于利”，所以请在gzip_types 把图片的相关项去掉。针对图片的相关处理，我们接下来会更加具体地介绍。
1.3.图片资源优化
刚刚我们介绍了资源打包压缩，只是停留在了代码层面，而在我们实际开发中，真正占用了大量网络传输资源的，并不是这些文件，而是图片，如果你对图片进行了优化工作，你能立刻看见明显的效果。
1.3.1.不要在HTML里缩放图像
很多开发者可能会有这样的错觉（其实我曾经也是这样），我们会为了方便在一个200✖200的图片容器内直接使用一张400✖400的图片，我们甚至认为这样能让用户觉得图片更加清晰，其实不然，在普通的显示器上，用户并不会感到缩放后的大图更加清晰，但这一切却导致网页加速速度下降，同时照成带宽浪费，你可能不知道，一张200KB的图片和2M的图片的传输时间会是200m和12s的差距（亲身经历，深受其害(┬＿┬)）。所以，当你需要用多大的图片时，就在服务器上准备好多大的图片，尽量固定图片尺寸。
1.3.2.使用雪碧图（CSS Sprite）
雪碧图的概念大家一定在生活中经常听见，其实雪碧图是减小请求数的显著运用。而且很奇妙的是，多张图片聘在一块后，总体积会比之前所有图片的体积之和小（你可以亲自试试）。这里给大家推荐一个自动化生成雪碧图的工具：https://www.toptal.com/developers/css/sprite-generator （图片来自官网首页）
只要你添加相关资源文件，他就会自动帮你生成雪碧图以及对应的CSS样式。
其实我们在工程中还有更为自动的方法，便是一款雪碧图生成插件webpack-spritesmith。首先，先简单介绍一下使用插件生成雪碧图的思路：
首先，我们会把我们所需要的小图标放置在一个文件夹内以便于管理：
（这里的@2x图片是为了适配视网膜二倍屏的图片资源，webpack-spritesmith内有专门为适配多倍屏提供的配置项，稍候将会讲到）
然后，我们需要插件去读取这个文件夹内的所有图片资源文件，以文件夹名称为图片名称生成一张雪碧图到指定位置，并且输出能够正确使用这些雪碧图的CSS文件。
如今，webpack-spritesmith这款插件能实现我们想要的一切，先奉上配置内容：具体可参照webpack-spritesmith官方文档
执行webpack之后，就会在开发目录里生成上面两张图的结果，我们可以看看common.css里面的内容：
我们可以看到，所有我们之前放在common文件夹里的图片资源都自动地生成了相应的样式，这些都不需要我们手动处理，``webpack-spritesmith`这款插件就已经帮我们完成了！
1.3.3.使用字体图标（iconfont）
不论是压缩后的图片，还是雪碧图，终归还是图片，只要是图片，就还是会占用大量网络传输资源。但是字体图标的出现，却让前端开发者看到了另外一个神奇的世界。
我最喜欢用的是阿里矢量图标库（网址：www.iconfont.cn/），里面有大量的矢量图…
图片能做的很多事情，矢量图都能作，而且它只是往HTML里插入字符和CSS样式而已，和图片请求比起来资源占用完全不在一个数量级，如果你的项目里有小图标，就是用矢量图吧。
但如果我们做的是公司或者团队的项目，需要使用到许多自定义的字体图标，可爱的设计小姐姐们只是丢给你了几份.svg图片，你又该如何去做呢？
其实也很简单，阿里矢量图标库就提供了上传本地SVG资源的功能，这里另外推荐一个网站——icomoon。icomoon这个网站也为我们提供了将SVG图片自动转化成CSS样式的功能。（图片来自icomoon首页）
我们可以点击Import Icons按钮导入我们本地的SVG资源，然后选中他们，接下来生成CSS的事情，就交给icomoon吧，具体的操作，就和阿里矢量图标库类同了。
1.3.4.使用WebP
WebP格式，是谷歌公司开发的一种旨在加快图片加载速度的图片格式。图片压缩体积大约只有JPEG的2/3，并能节省大量的服务器带宽资源和数据空间。Facebook、Ebay等知名网站已经开始测试并使用WebP格式。
我们可以使用官网提供的Linux命令行工具对项目中的图片进行WebP编码，也可以使用我们的线上服务，这里我推荐叉拍云（网址：www.upyun.com/webp）。但是在实际…
1.4.网络传输性能检测工具——Page Speed
除了network版块，其实chrome还为我们准备好了一款监测网络传输性能的插件——Page Speed，咱们的文章封面，就是用的Page Speed的官方宣传图（因为我觉得这张图再合适不过了）。我们只需要通过下面步骤安装，就可以在chrome devtools里找到它了：chrome菜单→更多工具→拓展程序→chrome网上应用商店→搜索pagespeed后安转即可。
（PS：使用chrome应用商店需要翻墙，怎么翻墙我就不便多说了）
这就是Page Speed的功能界面：
我们只需要打开待测试的网页，然后点击Page Speed里的 Start analyzing按钮，它就会自动帮我们测试网络传输性能了，这是我的网站测试结果：
Page Speed最人性化的地方，便是它会对测试网站的性能瓶颈提出完整的建议，我们可以根据它的提示进行优化工作。这里我的网站已经优化到最好指标了(•́⌄•́๑)૭✧，Page Speed Score表示你的性能测试得分，100/100表示已经没有需要优化的地方。
优化完毕后再使用chorme devtools的network版块测量一下我们网页的白屏时间还有首屏时间，是不是得到了很大的提升？
1.5.使用CDN
Last but not least，
再好的性能优化实例，也必须在CDN的支撑下才能到达极致。
如果我们在Linux下使用命令$ traceroute targetIp 或者在Windows下使用批处理 > tracert targetIp，都可以定位用户与目标计算机之间经过的所有路由器，不言而喻，用户和服务器之间距离越远，经过的路由器越多，延迟也就越高。使用CDN的目的之一便是解决这一问题，当然不仅仅如此，CDN还可以分担IDC压力。
当然，凭着我们单个人的资金实力（除非你是王思聪）是必定搭建不起来CDN的，不过我们可以使用各大企业提供的服务，诸如腾讯云等，配置也十分简单，这里就请大家自行去推敲啦。
2.页面渲染性能优化
2.1.浏览器渲染过程（Webkit）
其实大家应该对浏览器将的HTML渲染机制比较熟悉了，基本流程同上图所述，大家在入门的时候，你的导师或者前辈可能会告诉你，在渲染方面我们要减少重排和重绘，因为他们会影响浏览器性能。不过你一定不知道其中原理是什么，对吧。今天我们就结合《Webkit技术内幕》（这本书我还是很推荐大家买来看看，好歹作为一名前端工程师，你得知道我们天天接触的浏览器内核是怎样工作的）的相关知识，给大家普及普及那些深层次的概念。
PS：这里提到了Webkit内核，我顺带提一下浏览器内部的渲染引擎、解释器等组件的关系，因为经常有师弟或者一些前端爱好者向我问这方面的知识，分不清他们的关系，我就拿一张图来说明：（如果你对着不感兴趣，可以直接跳过）
浏览器的解释器，是包括在渲染引擎内的，我们常说的Chrome（现在使用的是Blink引擎）和Safari使用的Webkit引擎，Firefox使用的Gecko引擎，指的就是渲染引擎。而在渲染引擎内，还包括着我们的HTML解释器（渲染时用于构造DOM树）、CSS解释器（渲染时用于合成CSS规则）还有我们的JS解释器。
2.2.DOM渲染层与GPU硬件加速
如果我告诉你，一个页面是有许多许多层级组成的，他们就像千层面那样，你能想象出这个页面实际的样子吗？这里为了便于大家想象，我附上一张之前Firefox的3D View插件的页面Layers层级图：
对，你没看错，页面的真实样子就是这样，是由多个DOM元素渲染层（Layers）组成的，实际上一个页面在构建完render tree之后，是经历了这样的流程才最终呈现在我们面前的：
①浏览器会先获取DOM树并依据样式将其分割成多个独立的渲染层
②CPU将每个层绘制进绘图中
③将位图作为纹理上传至GPU（显卡）绘制
④GPU将所有的渲染层缓存（如果下次上传的渲染层没有发生变化，GPU就不需要对其进行重绘）并复合多个渲染层最终形成我们的图像
从上面的步骤我们可以知道，布局是由CPU处理的，而绘制则是由GPU完成的。
总结
-
框架原理真的深入某一部分具体的代码和实现方式时，要多注意到细节，不要只能写出一个框架。
-
算法方面很薄弱的，最好多刷一刷，不然影响你的工资和成功率😯
-
在投递简历之前，最好通过各种渠道找到公司内部的人，先提前了解业务，也可以帮助后期优秀 offer 的决策。
-
要勇于说不，对于某些 offer 待遇不满意、业务不喜欢，应该相信自己，不要因为当下没有更好的 offer 而投降，一份工作短则一年长则 N 年，为了幸福生活要慎重选择！！！
喜欢这篇文章文章的小伙伴们点赞+转发支持，你们的支持是我最大的动力！
3210
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
