看了别人的文章,更改删除了部分内容,以适应自己的学习需要,非常感谢撒网要见鱼的分享。
----------------------------------------------------------------------------------------------------------------------------
2018.8.2 第二次看,把自己以前看过的博客都整理进来,加深记忆的同时,还可以进一步了解各个知识点,前端知识其实就是一张谱图,以后会着手画的。在这个过程中,更加意识到分享的重要性。(若某些连接失效,可自行搜索相关知识点,加深学习)
-----------------------------------------------------------------------------------------------------------------------------
主干流程:
一、从浏览器接收URL到开启网络请求线程(这一部分可以展开浏览器的机制以及进程与线程之间的关系,JS的运行机制)
1、多进程的浏览器:(浏览器是多进程的)
- 1、有一个主控进程(负责协调、主控,只有一个),
- 2、第三方插件进程(每种类型的插件对应一个进程,仅当使用该插件时才创建),
- 3、GPU进程(最多一个,用于3D绘制),
- 4、浏览器渲染进程(内核,默认每一个tab页面都会新开一个进程,互不影响,控制页面渲染,脚本执行,事件处理等,某些情况下多个空白tab会合并一个进程)
五大主流浏览器的内核(主要指浏览器渲染引擎)详情可点击:主流浏览器内核介绍
每个tab页面可以看作是浏览器内核进程,然后这个进程是多线程的,它有几大类子线程:
- GUI线程
- JS引擎线程(是内核进程中的一个子线程,所以常说JS引擎是单线程的)
- 事件触发线程
- 定时器线程
- 网络请求线程
进程与线程的关系请点击:从浏览器多进程到JS单线程
2、解析URL
输入URL后,就会进行解析(URL的本质就是统一资源定位符)
URL一般包括几大部分:
- protocol,协议头,譬如有http,ftp等
- host ,主机域名或IP地址
- port ,端口号
- path ,目录路径
- query ,即查询参数
- fragment ,即#键后面的hash值,一般用来定位到某个位置
每次网络请求时都需要开辟单独的线程进行,如果URL解析到http协议,就会新建一个网络线程去处理资源下载。
二、开启网络线程到发出一个完整的http请求(这一部分涉及到dns查询,tcp/ip请求,五层因特网协议栈等知识)
1、DNS查询得到IP
如果输入的是域名,需要进行dns解析成IP(dns解析很耗时,因此如果解析域名过多,会让首屏加载变得过慢,可以考虑dns-prefetch优化),大致流程:
- 如果浏览器有缓存,直接使用浏览器缓存,否则使用本机缓存,再没有的话就是用host;
- 如果本地没有,就像dns域名服务器查询(当然,中间可能还会经过路由,CDN调度器,也有缓存等),查询到对应的IP。
- CDN调度器的了解: 一张图说明CDN分布原理
2、TCP/IP请求
http的本质就是tcp/ip请求,详细了解TCP的三次握手和四次挥手规则。
tcp将http长报文划分为短报文,通过三次握手与服务器建立连接,进行可靠传输。三次握手的步骤(抽象派):
- 客户端:hello,你是server吗?
- 服务端:hello,我是server,你是client吗
- 客户端:yes,我是client
建立连接成功后,接下来就是正式传输数据。然后,待到断开连接时,因为是全双工的,所以需要进行四次挥手。四次挥手的步骤(抽象派): - 主动方:我已经关闭了向你那边的主动通道了,只能被动接收了;
- 被动方:收到通道关闭的信息;
- 被动方:那我也告诉你,我这边向你的主动通道也关闭了;
- 主动方:最后接收数据,之后双方无法通信
tcp/ip的并发限制:浏览器对同一域名下并发的tcp连接是有限制的(2-10个不等)。
tcp/ip链接还涉及很多知识点, TCP协议 TCP/IP详解学习笔记。
常用的6大请求方式有:Get、Post、Put、Delete、Option5、Head
网络基础(可以看看其中关于HTTP的分解和UDP协议的部分说明)
3、五层因特网协议栈
从客户端发出http请求到服务器接收,中间会经过一系列的流程(服务器的接收就是反过来的步骤):
- 在应用层发送http请求;(应用层:dns,http,dns解析成ip并发送http请求)
- 到传输层通过三次握手建立tcp/IP连接;(传输层:tcp,udp)
- 到网络层的IP寻址;(网络层:IP,ARP)
- 到数据链路层的封装成帧;(数据链路层:ppp)
- 到物理层的利用物理介质传输;
完整的OSI七层框架,多了会话层和表示层: 物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。 - 表示层:主要处理两个通信系统中交换信息的表示方式,包括数据格式转换,数据加密与解密等
- 当我们在谈论前端加密时,我们在谈论什么?
- 会话层:它具体管理不同用户和进程之间的对话,如控制登录和注销过程。
- OSI七层模型详解(里面的图形详解画得非常好)
三、从服务器接收到的请求到对应后台接收到的请求(这一部分可能涉及到负载均衡,安全拦截以及后台内部的处理等等)
服务端在接收到请求时,内部会进行很多的处理:
1、负载均衡
对于大型的项目,由于并发访问量很大,所以往往一台服务器是吃不消的,一般会有若干台服务器组成一个集群,然后配合反向代理实现负载均衡。
简单地说,用户发起的请求都指向调度服务器(反向代理服务器,譬如安装了nginx控制负载均衡),然后调度服务器根据实际的调度算法,分配不同的请求给对应集群中的服务器执行,然后调度器等待实际服务器的http响应,并将它反馈给用户。
详细了解: 浅谈服务器集群、负载均衡、分布式
2、后台的处理
一般后台都是部署到容器中的,所以一般为:
- 先是容器接受到请求(如Tomcat容器)
- 然后对应容器中的后台程序接收到请求(如Java程序)
- 然后后台统一处理,处理完后响应响应结果
概括下:
- 一般的后端有统一验证,如安全拦截、跨域验证;
- 如上一步不符合规则,则直接返回相应的http报文(如拒绝请求等);
- 验证通过后,进入实际的后台代码,此时是程序接收到请求,然后执行(譬如查询数据,大量计算等等);
- 程序执行完毕后,返回一个http响应包(一般这一步也会经过多层封装);
- 然后就是讲这个包从后端发送到前端,完成交互。
四、后台和前台的http交互(这一部分包括http头部、响应码、报文结构、cookie等知识、可以提下静态资源的cookie优化,以及编码解码,如gzip压缩等)
1、http报文结构
前后端交互时,http报文作为信息的载体。报文一本包括了:通用头部、请求/响应头部、请求/响应体。
- http常用的状态码
- 面试必考之http状态码有哪些(http状态码过多,放此篇博客主要是说明着重记那些自己能体会的状态码,然后回答问题时捡自己擅长的答)
- http状态吗307,303,302的区别
2、cookie以及优化
cookie是浏览器的一种本地存储方式,cookie由浏览器保存的一下几块信息构成:
- 名称(一个唯一确定cookie的名称)
- 值(储存在cookie中的字符串,必须被URL编码,详细点就是,使用 encodeURIComponent 编码,decodeURIComponent解码)
- 域(domain,cookie对哪个域是有效的,所有向该域发送的请求中都会包含这个cookie信息)
- 路径(path,对于指定域中的那个路径,应该向服务器发送cookie)
- 失效时间(expires,表示cookie何时应该被删除的时间戳,如设置为以前的时间,则cookie会被立刻删除)
- 安全标志(secure,制定后,cookie只有在使用ssl连接的时候才发送到服务器)
例如,在服务器响应头部中:Set-Cookie: name=value; expires=Mon, xxx GMT; domain=.xxx.com; path=/; secure
尤其要注意,域、路径、失效时间和secure标志都是服务器给浏览器的指示,以指定何时应该发送cookie。这些参数并不会作为发送到服务器的cookie信息的一部分,只有名值对儿才会被发送。
一般用来帮助客户端和服务端通信,常用来进行身份校验,结合服务端的session使用。cookie常用场景如下(简述):
- 在登录页面,用户登录了
- 此时,服务端会生成一个session,session中有用户的信息(如用户名、密码等)
- 然后会有一个sessionid(相当于是服务器端的这个session对应的key)
- 然后服务端在登录页面中写入cookie,值就是:jssessionid = xxx
- 然后浏览器本地就有了这个cookie,以后访问同域名下的页面时,自动带上cookie,自动检验,在有效时间内无需二次登录。
一般来说,cookie是不允许存放敏感信息的(千万不要明文存储用户名、密码),因为非常不安全,如果一定要强行存储,首先,一定要在cookie中设置httponly(这样就无法通过js操作了),另外可以考虑RSA等非对称加密算法(因为实际上,浏览器本地是非常容易被攻克的,并不安全)。
另外,由于在同域名的资源请求时,浏览器会默认带上本地的cookie,正对这种情况,在某些场景中是需要优化的,例如页面中需要请求多个静态资源时,每次请求都带上cookie是很浪费的,因为静态资源不需要cookie验证,这时候可以采用域名拆分的方法,将静态资源分组,分别放到不同的子域名下,而子域名请求时,是不会带上父级域名cookie的,这样就避免了浪费。
现在客户端与服务器端更常用的验证方式是Token: cookie、session、Token对比
多种存储方式的对比(cookie、localStorage、sessionStorage):区别对比
- HTML5 sessionStorage会话存储
- HTML5 localStorage本地存储
- localstorage跨域解决方案(当存储的localStorage超限(一般为5MB)时,解决方案:引用其他域名下的localStorage,采用postMessage进行跨域读取)
3、长连接与短连接
首先看tcp/ip层面的含义:
长连接:一个tcp/ip连接上可以连续发送多个数据包,在tcp连接保持期间,如果没有数据包发送,需要双方发检测包以维持此连接,一般需要自己做在线维持(类似于心跳包)。
短连接:通信双方有数据交互时,就建立一个tcp连接,数据发送完成后,就断开此连接。
然后在http层面:http1.0中默认使用的短连接;http1.1中默认使用长连接(在服务器中可配置连接的持续时间)。
(了解一下轮询、webSocket这些概念)几种web服务器端推送技术的简单介绍
4、http2.0
http2.0不是https,它相当于是http的下一代规范。特性简述:
- 多路复用(一个tcp/ip连接可以请求多个资源)
- 首部压缩(http头部压缩,减少体积)
- 二进制分帧(在应用层与传送层之间增加了一个二进制分帧层,改进传输性能,实现低延迟和高吞吐量)
- 服务器端推送(服务端可以对客户端的一个请求发出多个响应,可以主动通知客户端)
- 请求优先级(如果流被赋予了优先级,它就会基于这个优先级来处理,由服务器决定需要多少资源来处理该请求)
详细了解: http2.0协议详解
5、https
https就是安全版本的http,譬如一些支付操作都是基于https的,因为http请求的安全系数指数太低了。
简单来说,https与http的区别就是:在请求时,会建立ssl链接,确保接下来的通信都是加密的,无法被轻易截取分析。
一般来说,要将网站升级成https,需要后端的支持(后端要申请证书等)。
一般来说,主要关注的就是SSL/TLS的握手流程,如下简述:
a、浏览器请求建立SSL链接,并向服务端发送一个随机数-client random 和客户端支持的加密方法,比如RSA加密,此时是明文传输。
b、服务端从中选出一组加密算法和Hash算法,回复一个随机数-Server random,并将自己的身份信息以证书的形式发回给浏览器(证书里包含了网站地址,非对称加密公钥,以及证书颁发机构等信息)
c、浏览器收到服务端的证书后:
- 验证证书的合法性,如果证书信任,则浏览器会显示一个小锁头,否则会有提示
- 用户接收证书后(不管信不信任),浏览器会产生新的随机数-Premaster secret,然后证书中的公钥以及指定的加密方法加密Premaster secret,发送给服务器
- 利用Client random、Server random和Premaster secret通过一定的算法生成http链接数据传输的对称加密key-session key
- 使用约定好的HASH算法计算握手消息,并使用生成的session key对消息进行加密,最后将之前生成的所有信息发送给服务端。
d、服务端收到浏览器的回复
- 利用已知的加解密方式与自己的私钥进行解密,获取Premaster secret。
- 和浏览器相同规则生成session key
- 使用session key解密浏览器发来的握手消息,并验证Hash是否与浏览器发来的一致
- 使用session key加密一段握手消息发送给浏览器
e、浏览器解密并计算握手消息的Hash值,如果与服务端发来的Hash值一致,此时握手过程结束。
之后所有的https通信数据将由之前浏览器生成的session key并利用对称加密算法进行加密。
- HTTPS为什么安全 &分析 HTTPS 连接建立全过程(整篇文章有理有据)
- Https协议详解(这篇文章太杂了,但是有用的知识点还是有)
- WebSocket 教程(ws协议也应该好好学习)
- HTTP/WebSocket详解
五、单独拎出来的缓存问题,http的缓存(这部分包括http缓存头部,etag,catch-control等)
前后端的交互中,使用缓存能很大限度上的提升效率,而且基本上对性能有要求的前端项目都是必用缓存的。浏览器是依靠请求和响应中的的头信息来控制缓存的。
1、强缓存与弱缓存
缓存可以简单地划分为两种类型:强缓存(200 from cache)与协商缓存(304)。区别简述如下:
- 强缓存时,浏览器如果判断本地缓存未过期就直接使用,无需发起http请求。
- 协商缓存时,浏览器会向服务端发起http请求,然后服务端告诉浏览器文件未改变,让浏览器使用本地缓存。
用户行为对缓存的影响:
2、缓存头部简述
上述提到了强缓存和弱缓存,那他们时怎么区分的呢?答案是通过不同的http头部控制。
属于强缓存控制的头部:
- (http1.1)Cache-Control:Max-Age 、no-cache、private、public (Max-Age是Cache-Control设置的缓存有效时间)
- (http1.0)Pragma/Expires (pragma:no-cache不缓存,Expires 设置缓存失效时间)
- 注意:如果cache-control与expires同时存在的话,cache-control的优先级高于expires
属于协商缓存控制的头部:
- (http1.1)If-None-Match/E-tag
- (http1.0) If-Modified-Since/Last-Modified (不同的头部属于不同的时期)
- 这两组搭档都是成对出现的,即第一次请求的响应头带上某个字段(Last-Modified或者Etag),则后续请求则会带上对应的请求字段(If-Modified-Since或者If-None-Match),若响应头没有Last-Modified或者Etag字段,则请求头也不会有对应的字段。如果两者同时存在,If-None-Match优先,忽略If-Modified-Since。现在它们均要配合Cache-Control使用。
缓存流程图描述:浏览器第一次请求
浏览器第二次请求:
总体了解缓存机制:【Web缓存机制系列】 浏览器缓存机制浅析
我们也有必要了解一下manifest,indexDB: H5缓存机制总结
六、浏览器接收到http数据包后的解析流程(解析HTML词法,然后解析成dom树、解析css生成css规则树、合并render树,然后layout、painting渲染、复合图层的合成、GPU绘制、外链资源的处理、loaded和domcontentloaded等)
1、流程简述
浏览器内核拿到内容后,渲染步骤大致可以分为以下几步:
- 解析HTML,构建DOM树
- 解析CSS,生成CSS规则树
- 合并DOM树和CSS规则树,生成render树
- 布局render树(layout/reflow),负责各元素尺寸、位置的计算
- 绘制render树(paint),绘制页面像素信息
- 浏览器会将各层的信息发送给GUI,GUI会将各层合成(composite),显示在屏幕上。
如下图:
2、HTML解析,构建DOM
解析HTML到构建出DOM的过程可减简述如下: Bytes -> characters -> tokens ->nodes ->DOM
譬如假设有这样一个HTML页面:
<html>
<head>
<meta name="viewport" content="width=device-width,initial-scale=1">
<link href="style.css" rel="stylesheet">
<title>Critical Path</title>
</head>
<body>
<p>Hello <span>web performance</span>students!</p>
<div><img src="awesome-photo.jpg"></div>
</body>
</html>
浏览器的处理如下:
列举其中的一些重点过程:
- Conversion转换:浏览器将获得的HTML内容(Bytes)基于他的编码转换为单个字符
- Tokenizing分词:浏览器按照HTML规范标准将这些字符转换为不同的标记token。每个token都有自己独特的含义和规则集
- Lexing词法分析:分词的结果是得到一堆的token,此时把他们转换为对象,这些对象分别定义他们的属性和规则
- DOM构建:因为HTML标记定义的就是不同标签之间的关系,这个关系就像是一个树形结构一样,例如:body对象的父节点就是HTML对象,然后p对象的父节点就是body对象
最后的DOM树如下:
3、生成CSS规则
CSS规则树的生成过程类似:Bytes ->characters ->token ->nodes ->CSSOM
譬如style.css内容如下:
body{font-size:16px}
p{font-weight:bold}
span{color:red}
p span{display:none}
img{float:right}
那么最终的CSSOM树就是:
- HTML5和CSS3新特性一览(要特别注意一些标签或属性的差别用法)
- 深入了解 CSS3 新特性
- CSS选择器的权重详解
4、构建渲染树
一般来说,渲染树与DOM树是相对应的,但不是严格意义上的一一对应。因为有一些不可见的DOM元素不会插入到渲染树中,如head这种不可见的标签或者display:none等。
整体看图:
5、渲染
渲染基本流程如下:
图中重要的四个步骤就是:
- 计算CSS样式
- 构建渲染树
- 布局,主要定位坐标和大小,是否换行,各种position overflow z-index属性
- 绘制,将图像绘制出来
然后,图中的线与箭头表示通过js动态修改了DOM和CSS,导致了重新布局(layout)或渲染(Repaint)。
这里,layout和Repaint的概念是有区别的:
- layout:也称为Reflow,即回流(重排)。一般以为这元素的内容、结构、位置或尺寸发生了变化,需要重新计算样式和渲染树。
- Repaint:即重绘。意味着元素发生的改变只是影响了元素的一些外观之类的s时候(例如:背景色,文字颜色等),此时只需要重新应用新样式绘制这个元素就可以了。
回流的成本开销要高于重绘,而且一个节点的回流往往会导致子节点以及同级节点的回流,所以优化方案中一般都包括,尽量避免回流。
什么会引起回流(重排)?
- 页面渲染初始化
- DOM结构改变,比如删除了某个节点
- render树变化,比如减少了padding
- 窗口resize
- 最复杂的一种:获取某些属性,引发回流
回流一定伴随着重绘,重绘却可以单独出现。所以一般会有一些优化方案: - 减少逐项更改样式,最好一次性更改style,或者将样式定义为class并一次性更新
- 避免循环操作dom,创建一个documentFragment或div,在它上面应用所以的DOM操作,最好再把它添加到window.document。
- 避免多次读取offset等属性,无法避免则将他们缓存到变量。
- 将复杂的元素绝对定位或固定定位,使得他们脱离文档流,否则回流代价会更高。
注意:改变字体大小会引发回流。 - 浅谈DOM的操作以及性能优化问题-重绘重排
6、简单层与复合层
上述中的渲染止步于绘制,绘制可以结合复合层和简单层的概念来讲,简单介绍如下:
- 可以认为默认只有一个复合图层,所有的DOM节点都是在这个复合图层下的
- 如果开启了硬件加速功能,可以将某个节点变成复合图层
- 复合图层之间的绘制互不干扰,由GPU直接绘制
- 而简单图层中,就算是absolute等布局,变化时不影响整体的回流,但是由于在同一个图层中,仍然是会影响绘制的,因此,做动画时仍然性能很低,所以一般做动画推荐使用硬件加速
7、Chrome中的调试
Chrome开发者工具详解: Chrome开发者工具讲解
Chrome的开发者工具中,Performance中可以看到详细的渲染过程:
8、资源外链的下载
在解析html时,会遇到一些资源连接,此时就需要进行单独处理,这里将遇到的静态资源分为几大类(未列举所有): css样式资源、JS脚本资源、img图片类资源。文档加载的顺序:域名解析-->加载HTML-->加载JavaScript和CSS-->加载图片等非文字媒体文件。
遇到外链时的处理:当遇到上述外链时,会单独开启一个下载线程去下载资源(http1.1是每一个资源的下载都要开启一个http请求,对应一个tcp/ip链接)
遇到CSS样式资源(特点):
- CSS下载时异步,不会阻塞浏览器构建DOM树
- 但是会阻塞渲染,也就是在构建render树时,会等到css下载解析完毕后才进行(这点与浏览器优化有关,防止css规则不断改变,避免了重复的构建)。有例外,media query声明的CSS是不会阻塞渲染的。
遇到JS脚本资源(特点):
- 阻塞浏览器的解析,也就是说发现一个外链脚本时,需等待脚本下载完成并执行后才会继续解析html;
- 浏览器的优化,在脚本阻塞时,也会继续下载其他资源(当然有并发上限),但是虽然脚本可以并行下载,解析过程仍然是阻塞的,也就是说必须这个脚本执行完毕后才会接下来的解析,并行下载只是一种优化而已。
- defer(延迟执行)与async(异步执行),普通的脚本是会阻塞浏览器解析的,但是可以加上defer和async属性,这样脚本就变成异步了,可以等到解析完成后再执行。
遇到img图片类资源:
- 遇到图片等资源时,直接就是异步下载,不会阻塞解析,下载完毕后直接用图片替换原有src的地方。
七、css的可视化格式模型(元素的渲染规则,如包含块、控制框、BFC(块级框)、IFC(行内框)等概念)
css的可视化格式模型就是规定了浏览器在页面中如何处理文档树。
css的三种定位机制:普通流,浮动,绝对定位。
- css定位方式已经浮动的了解
- 什么是BFC、IFC
- CSS自适应布局总结
- 移动端适配总结(需要特别了解rem和媒体查询结合的适配方案) px、em、rem的区别
- 利用HTML和CSS实现常见的布局(好文)
- 加深了解
- Flex布局 grid栅格布局 flex与grid布局趋势 flex与grid布局对比
- CSS媒体查询
- CSS选择器大全(最好还要结合jQuery源码,看css选择器是怎么匹配的,然后自己实现一个)
- CSS预处理工具Stylus(这里由于我自己学的是Stylus,但是还可以看看less 和 sass)
- CSS精灵图的使用
八、JS引擎解析过程(JS的解释阶段,预处理阶段,执行阶段生成执行上下文,VO,作用域链,回收机制等等)
JS脚本的执行需要引擎解析,主干流程如下:
1、JS的解析阶段:
首先得明确,JS是解析性语言,所以它无需提前编译,由解释器实时运行。
引擎对JS的处理过程可简述如下(核心:JIT编译器将源码编译成机器码运行):
读取代码,进行词法分析(Lexical analysis),然后将代码分解成词元(token);
对词元进行语法分析(parsing),然后将代码整成语法树(synntax tree);
使用翻译器(translator),将代码转为字节码(bytecode);
使用字节码解释器(bytecode interpreter),将字节码转为机器码。
2、 JS的预处理阶段:在正式执行JS前,会涉及函数提升,变量提升,分号补全等操作。
3、JS的执行阶段:
涉及概念:执行上下文,执行堆栈概念; VO(变量对象)和AO(活动对象); 作用域链; this机制等。
执行上下文简单解释:
- JS有执行上下文;
- 浏览器首次载入脚本,它将创建全局执行上下文,并压入执行栈栈顶(不可被弹出);
- 然后没进入其它作用域就创建对应的执行上下文并把它压入执行栈的顶部
- 一旦对应的上下文执行完毕,就从栈顶弹出,并将上下文控制权交给当前的栈
- 这样依次执行,最终都会回到全局执行上下文。
每一个执行上下文,都有三个重要属性:变量对象(VO,存放一些变量信息)、作用域链、this(不是某个变量对象的属性)。其中,只有全局上下文的变量对象允许通过VO的属性名称来间接访问(因为在全局上下文里,全局对象自身就是变量对象)。
AO,当函数被调用者激活,AO就被创建了。
可以理解为:在函数上下文中,VO === AO
在全局上下文中,VO === this ===global
关于JS的以上三个阶段,设计JS基础 知识很多,包括执行环境、作用域、作用域链、原型、闭包、原型链、this等,可以看看下面这篇博客,通俗易懂:JS基础知识详解
JS事件循环机制(重点):
4、回收机制
JS引擎的基础GC方案是:标记清除。
GC缺陷:GC时,停止响应其他操作。
优化方案:分代回收——多回收“临时对象”区;少回收“持久对象”区;减少每次需遍历的对象,从而减少每次GC的耗时。
九、其它(可以拓展不同的只是模块,如跨域,web安全,hybrid模式等等内容)
1、通信方式(Ajax、axios、fetch,SSE,web Socket等)
2、跨域(jsonp、cors、img、postMessage、domain等)
- cors工作原理详解(好文)
- ajax通过cors实现跨域
- jsonp讲解,为什么只支持get?同步还是异步?
- 各种跨域方式的比较(文章较早,没有cors)
3、web安全
- web安全不可忽视
- web网站中常见攻击手法与原理
- 前端安全之XSS
- CSRF 攻击的应对之道
- HTML5安全攻防详析之完结篇:HTML5对安全的改进 (HTML5加大了对本地存储的访问,如何保证存储资源的安全?)
4、web App
- 单页面WebApp与多页面的区别
- 移动端开发和web端开发的区别
- web App、native App、Hybrid App 对比
- 新技术
- 下一代webApp----PWA 饿了么PWA开发实践 (都是一个作者的文章,好文)
- PWA初探总结(对上面的加深印象)
5、web优化
网页优化:
- 常见的web性能优化法则
- web性能优化法则14
- Yahoo 35条前端优化建议(建议都差不多,只不过起到加深印象的作用)
移动端网页优化:
- 移动端浏览器优化策略
- 移动端网站提升页面加载性能的技巧(这篇和上篇差不多,讲解更偏web)
- 移动端300ms延迟和点击穿透问题
- 点击穿透问题的解决方案
首屏优化:
- 关于首屏性能优化的总结【原创】(以京东为例,说明如何做首屏优化)
- 浅谈自己知道的首屏加载时间的优化策略
6、es6(let\const\var、解构赋值、箭头函数、异步(promise、Generator、async)等)
7、jQuery(源码 学习,项目运用,虽然自己也看了源码学习,但是学的还是太浅显,缺乏自己的思考)
- jQuery源码分析--艾伦
- 【深入浅出jQuery】源码浅析2--奇技淫巧 (别人看源码能学到什么,思考自己所学所得)
8、Vue(源码学习,项目运用(脚手架,全家桶),生命周期、虚拟Dom、数据双向绑定、状态存储Vuex、导航守卫Vue-router等)
- Vue源码学习(比较浅显,熟悉总体)
- 详解VUE生命周期
- 浅谈Vue框架中的响应式原理
- vue与react对比(好文)
- vue源码学习——综述(这是自己对照尤大神推荐的文章写得,可以直接看尤大神给的链接学习)
9、构建工具(主要是webpack,熟悉load)
- 深入理解webpack(好文)
- webpack浅谈(从多方面总结webpack)
10、node.js(涉及后端,就有必要学习express、koa等后端框架,以及写后端必用数据库mysql或mongoDB。。。不想成为全栈的前端不是好前端,所以不停的学吧!!!)
11、数据结构(算法基础,树、链表、哈希等)(需要自己总结一篇)
12、八大类排序算法
13、其它学习
- 浅谈框架模式 MVC、MVP 和 MVVM
- 从Script到Code Blocks、Code Behind到MVC、MVP、MVVM(知乎上的一个高票答案,和上面关于mvc的说法有所区别,就是m是否可以直接操作v的问题,其实是都可以)
- js设计模式(文章内容甚广,自己也看了设计模式的书,写过一篇简短博客,放于下方吧)
- JS设计模式与开发实践
- 前端技术发展概述——拓展
- git常用命令总结
- mongodb与关系型数据库的对比
- 讨论canvas与svg的区别
- 深入理解 requestAnimationFrame
- REST和RESTful浅谈
14、全栈工程师
- 全栈开发工程师的权威指南(里面很多链接可能失效或者英文,但是主要是根据文章有个学习思路,可以自己找相关知识点学习)