浏览器如何工作&浏览器工作链路环节性能优化(写代码时就能做)
2021-12-31 11:24:41 0 举报
AI智能生成
浏览器如何工作&浏览器工作链路环节性能优化
作者其他创作
大纲/内容
概述
性能面临的两个问题
网络延迟
Latency is our main threat to overcome to ensure a fast load.
To be fast to load, the developers’ goals include sending requested information as fast as possible,
or at least seem super fast.
Network latency is the time it takes to transmit bytes over-the-air to computers.
Web performance is what we have to do to make the page load happen as quickly as possible.
To be fast to load, the developers’ goals include sending requested information as fast as possible,
or at least seem super fast.
Network latency is the time it takes to transmit bytes over-the-air to computers.
Web performance is what we have to do to make the page load happen as quickly as possible.
浏览器的单线程
minimizing the main thread's responsibilities, where possible and appropriate,
to ensure rendering is smooth and responses to interactions are immediate.
to ensure rendering is smooth and responses to interactions are immediate.
性能优化两大方向
少加载文件
少执行代码
1. 与Web 服务器
建立连接
(这个流程里没有讲关闭连接,
关闭连接与性能没啥关系)
建立连接
(这个流程里没有讲关闭连接,
关闭连接与性能没啥关系)
1.1 DNS 查询
优化策略
DNS 预获取
淘宝网的例子
1.2 TCP 三次握手建立连接/双向通道
1.3 TLS 协商
For secure connections established over HTTPS, another "handshake" is required.
This handshake, or rather the TLS negotiation,
determines which cipher will be used to encrypt the communication, verifies the server,
and establishes that a secure connection is in place before beginning the actual transfer of data.
This requires three more round trips to the server before the request for content is actually sent.
While making the connection secure adds time to the page load,
a secure connection is worth the latency expense,
as the data transmitted between the browser and the web server cannot be decrypted(破解)by a third party.
This handshake, or rather the TLS negotiation,
determines which cipher will be used to encrypt the communication, verifies the server,
and establishes that a secure connection is in place before beginning the actual transfer of data.
This requires three more round trips to the server before the request for content is actually sent.
While making the connection secure adds time to the page load,
a secure connection is worth the latency expense,
as the data transmitted between the browser and the web server cannot be decrypted(破解)by a third party.
图示总结
After the 8 round trips, the browser is finally able to make the request.
优化策略
长连接
减少文件请求次数
雪碧图
webpack-spritesmith 插件
js、css 打包
浏览器缓存控制
由协商缓存改为强制缓存
Access-Control-max-age
The Access-Control-Max-Age 这个响应头表示 preflight request (预检请求)的返回结果
(即 Access-Control-Allow-Methods 和Access-Control-Allow-Headers 提供的信息) 可以被缓存多久。
但只针对完全一样的 url,如果是 get 请求,url 后面参数变化则 url 也变化了不生效。
(即 Access-Control-Allow-Methods 和Access-Control-Allow-Headers 提供的信息) 可以被缓存多久。
但只针对完全一样的 url,如果是 get 请求,url 后面参数变化则 url 也变化了不生效。
懒加载
代码拆分
一开始只请求首屏必要的,其他的按需加载。
JavaScript
CSS
图片与 iframe
loading 属性
<img>元素上的加载属性(或<iframe>上的加载属性)可用于指示浏览器延迟加载屏幕外的图像/iframe,直到用户在其附近滚动。
加载事件在急切加载的内容已全部加载时激发;
在那个时候,可能在视觉视口(en-US)中存在尚未加载的延迟加载图像。
通过检查给定图像的complete属性的值,可以确定该图像是否已完成加载。
加载事件在急切加载的内容已全部加载时激发;
在那个时候,可能在视觉视口(en-US)中存在尚未加载的延迟加载图像。
通过检查给定图像的complete属性的值,可以确定该图像是否已完成加载。
js 实现
本地存储
2. 请求与响应
Once we have an established connection to a web server,
the browser sends an initial HTTP GET request on behalf of the user,
which for websites is most often an HTML file.
Once the server receives the request, it will reply with
relevant response headers and the contents of the HTML.
the browser sends an initial HTTP GET request on behalf of the user,
which for websites is most often an HTML file.
Once the server receives the request, it will reply with
relevant response headers and the contents of the HTML.
TCP Slow Start / 14kb rule
The first response packet will be 14Kb.
This is part of TCP slow start, an algorithm which balances the speed of a network connection.
Slow start gradually increases the amount of data transmitted
until the network's maximum bandwidth can be determined.
In TCP slow start, after receipt of the initial packet, the server doubles the size of the next packet to around 28Kb.
Subsequent packets increase in size until a predetermined threshold is reached, or congestion is experienced.
This is part of TCP slow start, an algorithm which balances the speed of a network connection.
Slow start gradually increases the amount of data transmitted
until the network's maximum bandwidth can be determined.
In TCP slow start, after receipt of the initial packet, the server doubles the size of the next packet to around 28Kb.
Subsequent packets increase in size until a predetermined threshold is reached, or congestion is experienced.
If you’ve ever heard of the 14Kb rule for initial page load, TCP slow start is the reason why the initial response is 14Kb,
and why web performance optimization calls for focusing optimizations with this initial 14Kb response in mind.
TCP slow start gradually builds up transmission speeds appropriate for the network's capabilities to avoid congestion.
and why web performance optimization calls for focusing optimizations with this initial 14Kb response in mind.
TCP slow start gradually builds up transmission speeds appropriate for the network's capabilities to avoid congestion.
Congestion control
As the server sends data in TCP packets, the user's client confirms delivery by returning acknowledgements, or ACKs.
The connection has a limited capacity depending on hardware and network conditions.
If the server sends too many packets too quickly, they will be dropped. Meaning, there will be no acknowledgement.
The server registers this as missing ACKs.
Congestion control algorithms use this flow of sent packets and ACKs to determine a send rate.
The connection has a limited capacity depending on hardware and network conditions.
If the server sends too many packets too quickly, they will be dropped. Meaning, there will be no acknowledgement.
The server registers this as missing ACKs.
Congestion control algorithms use this flow of sent packets and ACKs to determine a send rate.
优化策略
减少文件体积
js、css 打包压缩
分析文件大小
webpack-bundle-analyzer 插件
- 可以根据生成的图来找出并优化大的包。
- 可以将常用的稳定的包如 vue vue-router 单独打包?打包到 runtime 里??,这样可以有效利用缓存。
一般减少包体积的方法是按需加载
图片优化
图片压缩
图片类型选择
jpg
1. 有损压缩
2. 体积小
3. 不支持透明
2. 体积小
3. 不支持透明
适用于背景图、轮播图
png
1. 无损压缩,质量高
2. 支持透明
2. 支持透明
适用于小图,比如logo,商品icon
svg
1. 无损压缩
2. 矢量模式
3. 体积小
4. SVG文件是用XML编写的,其展示的效果可以在运行时改变。
2. 矢量模式
3. 体积小
4. SVG文件是用XML编写的,其展示的效果可以在运行时改变。
适用于小logo和图标。
因为无论是Retina屏幕或在其他低清晰度的屏幕上它的形状都是一样的。
SVG文件的大小通常是极小的,即使它们看起来的样子真的很大。
因为无论是Retina屏幕或在其他低清晰度的屏幕上它的形状都是一样的。
SVG文件的大小通常是极小的,即使它们看起来的样子真的很大。
参考
https://www.jianshu.com/p/c66f52d875d9
gzip
Gzip 是一种用于文件压缩与解压缩的文件格式。
它基于 Deflate 算法,可将文件压缩地更小,从而实现更快的网络传输。
Web服务器与现代浏览器普遍地支持 Gzip,这意味着服务器可以在发送文件之前自动使用 Gzip 压缩文件,而浏览器可以在接收文件时自行解压缩文件。
它基于 Deflate 算法,可将文件压缩地更小,从而实现更快的网络传输。
Web服务器与现代浏览器普遍地支持 Gzip,这意味着服务器可以在发送文件之前自动使用 Gzip 压缩文件,而浏览器可以在接收文件时自行解压缩文件。
gzip 原理
开启 gzip
服务端
- Compression is enabled via webserver configuration
- Different web servers have different instructions (explained below)
webpack devServer
客户端请求头
accept-encoding:gzip
减少用户和服务器的距离
cdn
3. 解析
解析是浏览器将通过网络接收的数据转换为DOM和CSSOM的步骤,渲染器使用DOM和CSSOM在屏幕上绘制页面。
即使请求页面的HTML大于最初的14KB数据包,浏览器也将开始解析并尝试根据其拥有的数据呈现体验。
这就是为什么web性能优化需要在最初的14千字节中包含浏览器开始呈现页面所需的一切,或者至少包含页面模板(第一次呈现所需的CSS和HTML)。
但是在将任何内容呈现到屏幕之前,必须对HTML、CSS和JavaScript进行解析。
即使请求页面的HTML大于最初的14KB数据包,浏览器也将开始解析并尝试根据其拥有的数据呈现体验。
这就是为什么web性能优化需要在最初的14千字节中包含浏览器开始呈现页面所需的一切,或者至少包含页面模板(第一次呈现所需的CSS和HTML)。
但是在将任何内容呈现到屏幕之前,必须对HTML、CSS和JavaScript进行解析。
HTML 解释器将 HTML 文档
解析为 DOM 树
解析为 DOM 树
处理 HTML 标记并构建 DOM 树
不会导致暂停HTML解析的资源
- an image
- a CSS file
导致暂停HTML解析的资源
非异步的 <script> 标签
之所以对 <script> 标签应用阻塞式的解析策略,是因为 JS 拥有改变 HTML 文档结构的权限。
预加载扫描仪
(Preload scanner)
(Preload scanner)
当浏览器构建DOM树时,这个过程会占用主线程。
这时,预加载扫描程序将解析可用的内容,并请求诸如CSS、JavaScript和web字体等高优先级资源。
由于有了预加载扫描程序,我们不必等到解析器找到对外部资源的引用后再请求它。
它将在后台检索资源,以便在主HTML解析器到达请求的资产时,它们可能已经在运行中,或者已经被下载。
预加载扫描仪的优化可减少堵塞。
这时,预加载扫描程序将解析可用的内容,并请求诸如CSS、JavaScript和web字体等高优先级资源。
由于有了预加载扫描程序,我们不必等到解析器找到对外部资源的引用后再请求它。
它将在后台检索资源,以便在主HTML解析器到达请求的资产时,它们可能已经在运行中,或者已经被下载。
预加载扫描仪的优化可减少堵塞。
优化策略
js
为确保脚本不会阻止进程,
如果JavaScript解析和执行顺序不重要,
请添加 async 或者 defer属性。
如果JavaScript解析和执行顺序不重要,
请添加 async 或者 defer属性。
script 元素的 async 与 defer attribute
字体
Waiting to obtain CSS doesn't block HTML parsing or downloading,
but it does block JavaScript,
because JavaScript is often used to query CSS properties’ impact on elements.
but it does block JavaScript,
because JavaScript is often used to query CSS properties’ impact on elements.
CSS 解释器将 CSS
解析为 CSSOM
解析为 CSSOM
the total time to create the CSSOM is generally less than the time it takes for one DNS lookup.
Other Processes
JavaScript Compilation
While the CSS is being parsed and the CSSOM created, other assets,
including JavaScript files, are downloading (thanks to the preload scanner).
JavaScript is interpreted, compiled, parsed and executed.
The scripts are parsed into abstract syntax trees.
Some browser engines take the Abstract Syntax Tree and pass it into an interpreter,
outputting bytecode which is executed on the main thread.
This is known as JavaScript compilation.
including JavaScript files, are downloading (thanks to the preload scanner).
JavaScript is interpreted, compiled, parsed and executed.
The scripts are parsed into abstract syntax trees.
Some browser engines take the Abstract Syntax Tree and pass it into an interpreter,
outputting bytecode which is executed on the main thread.
This is known as JavaScript compilation.
优化策略
服务端渲染
Building the Accessibility Tree
The browser also builds an accessibility tree that assistive devices use to parse and interpret content.
The accessibility object model (AOM) is like a semantic version of the DOM.
The browser updates the accessibility tree when the DOM is updated.
The accessibility tree is not modifiable by assistive technologies themselves.
Until the AOM is built, the content is not accessible to screen readers.
The accessibility object model (AOM) is like a semantic version of the DOM.
The browser updates the accessibility tree when the DOM is updated.
The accessibility tree is not modifiable by assistive technologies themselves.
Until the AOM is built, the content is not accessible to screen readers.
4. 渲染
渲染步骤包括样式、布局、绘制,在某些情况下还包括合成。
在解析步骤中创建的CSSOM和DOM树被组合成一个渲染树,用于计算每个可见元素的布局,然后绘制到屏幕上。
在某些情况下,可以将内容提升到自己的层并进行合成,通过在GPU而不是CPU上绘制部分屏幕来提高性能,因为这样能释放主线程。
在解析步骤中创建的CSSOM和DOM树被组合成一个渲染树,用于计算每个可见元素的布局,然后绘制到屏幕上。
在某些情况下,可以将内容提升到自己的层并进行合成,通过在GPU而不是CPU上绘制部分屏幕来提高性能,因为这样能释放主线程。
默认情况下,字体请求会延迟到构造渲染树之前,
这可能会导致文本渲染延迟。
这可能会导致文本渲染延迟。
优化策略
CSSOM和DOM树组合成一个渲染树
The third step in the critical rendering path is combining the DOM and CSSOM into a render tree.
The computed style tree, or render tree, construction starts with the root of the DOM tree,
traversing each visible node.
Tags that aren't going to be displayed, like the <head> and its children and
any nodes with display: none, such as the script { display: none; } you will find in user agent stylesheets,
are not included in the render tree as they will not appear in the rendered output.
Nodes with visibility: hidden applied are included in the render tree, as they do take up space.
As we have not given any directives to override the user agent default,
the script node in our code example above will not be included in the render tree.
(这句意思不懂,以后需要理解了再研究)
Each visible node has its CSSOM rules applied to it.
The render tree holds all the visible nodes with content and computed styles
-- matching up all the relevant styles to every visible node in the DOM tree,
and determining, based on the CSS cascade, what the computed styles are for each node.
The computed style tree, or render tree, construction starts with the root of the DOM tree,
traversing each visible node.
Tags that aren't going to be displayed, like the <head> and its children and
any nodes with display: none, such as the script { display: none; } you will find in user agent stylesheets,
are not included in the render tree as they will not appear in the rendered output.
Nodes with visibility: hidden applied are included in the render tree, as they do take up space.
As we have not given any directives to override the user agent default,
the script node in our code example above will not be included in the render tree.
(这句意思不懂,以后需要理解了再研究)
Each visible node has its CSSOM rules applied to it.
The render tree holds all the visible nodes with content and computed styles
-- matching up all the relevant styles to every visible node in the DOM tree,
and determining, based on the CSS cascade, what the computed styles are for each node.
Layout
The fourth step in the critical rending path is running layout on the render tree to compute the geometry of each node.
Layout is the process by which the width, height, and location of all the nodes in the render tree are determined,
plus the determination of the size and position of each object on the page.
Reflow is any subsequent size and position determination of any part of the page or the entire document.
Once the render tree is built, layout commences. The render tree identified which nodes are displayed (even if invisible) along with their computed styles, but not the dimensions or location of each node. To determine the exact size and location of each object, the browser starts at the root of the render tree and traverses it.
On the web page, most everything is a box. Different devices and different desktop preferences mean an unlimited number of differing viewport sizes. In this phase, taking the viewport size into consideration, the browser determines what the dimensions of all the different boxes are going to be on the screen. Taking the size of the viewport as its base, layout generally starts with the body, laying out the dimensions of all the body’s descendants, with each element's box model properties, providing placeholder space for replaced elements it doesn’t know the dimensions of, such as our image.
The first time the size and position of nodes are determined is called layout.
Subsequent recalculations of node size and locations are called reflows. In our example, suppose the initial layout occurs before the image is returned.
Since we didn't declare the size of our image, there will be a reflow once the image size is known.
Layout is the process by which the width, height, and location of all the nodes in the render tree are determined,
plus the determination of the size and position of each object on the page.
Reflow is any subsequent size and position determination of any part of the page or the entire document.
Once the render tree is built, layout commences. The render tree identified which nodes are displayed (even if invisible) along with their computed styles, but not the dimensions or location of each node. To determine the exact size and location of each object, the browser starts at the root of the render tree and traverses it.
On the web page, most everything is a box. Different devices and different desktop preferences mean an unlimited number of differing viewport sizes. In this phase, taking the viewport size into consideration, the browser determines what the dimensions of all the different boxes are going to be on the screen. Taking the size of the viewport as its base, layout generally starts with the body, laying out the dimensions of all the body’s descendants, with each element's box model properties, providing placeholder space for replaced elements it doesn’t know the dimensions of, such as our image.
The first time the size and position of nodes are determined is called layout.
Subsequent recalculations of node size and locations are called reflows. In our example, suppose the initial layout occurs before the image is returned.
Since we didn't declare the size of our image, there will be a reflow once the image size is known.
Paint
The last step in the critical rendering path is painting the individual nodes to the screen,
the first occurence of which is called the first meaningful paint.
In the painting or rasterization(光栅化) phase, the browser converts each box calculated in the layout phase to actual pixels on the screen.
Painting involves drawing every visual part of an element to the screen, including text, colors, borders, shadows,
and replaced elements like buttons and images. The browser needs to do this super quickly.
To ensure smooth scrolling and animation, everything occupying the main thread, including calculating styles, along with reflow and paint, must take the browser less than 16.67ms to accomplish.
At 2048 X 1536, the iPad has over 3,145,000 pixels to be painted to the screen. That is a lot of pixels that have to be painted very quickly.
To ensure repainting can be done even faster than the initial paint, the drawing to the screen is generally broken down into several layers.
If this occurs, then compositing is necessary.
Painting can break the elements in the layout tree into layers.
Promoting content into layers on the GPU (instead of the main thread on the CPU) improves paint and repaint performance.
There are specific properties and elements that instantiate a layer, including <video> and <canvas>,
and any element which has the CSS properties of opacity, a 3D transform, will-change, and a few others.
These nodes will be painted onto their own layer, along with their descendants,
unless a descendant necessitates(使成为必要) its own layer for one (or more) of the above reasons.
Layers do improve performance, but are expensive when it comes to memory management,
so should not be overused as part of web performance optimization strategies.
the first occurence of which is called the first meaningful paint.
In the painting or rasterization(光栅化) phase, the browser converts each box calculated in the layout phase to actual pixels on the screen.
Painting involves drawing every visual part of an element to the screen, including text, colors, borders, shadows,
and replaced elements like buttons and images. The browser needs to do this super quickly.
To ensure smooth scrolling and animation, everything occupying the main thread, including calculating styles, along with reflow and paint, must take the browser less than 16.67ms to accomplish.
At 2048 X 1536, the iPad has over 3,145,000 pixels to be painted to the screen. That is a lot of pixels that have to be painted very quickly.
To ensure repainting can be done even faster than the initial paint, the drawing to the screen is generally broken down into several layers.
If this occurs, then compositing is necessary.
Painting can break the elements in the layout tree into layers.
Promoting content into layers on the GPU (instead of the main thread on the CPU) improves paint and repaint performance.
There are specific properties and elements that instantiate a layer, including <video> and <canvas>,
and any element which has the CSS properties of opacity, a 3D transform, will-change, and a few others.
These nodes will be painted onto their own layer, along with their descendants,
unless a descendant necessitates(使成为必要) its own layer for one (or more) of the above reasons.
Layers do improve performance, but are expensive when it comes to memory management,
so should not be overused as part of web performance optimization strategies.
Compositing
When sections of the document are drawn in different layers, overlapping each other,
compositing is necessary to ensure they are drawn to the screen in the right order and
the content is rendered correctly.
As the page continues to load assets, reflows can happen (recall our example image that arrived late).
A reflow sparks a repaint and a re-composite.
compositing is necessary to ensure they are drawn to the screen in the right order and
the content is rendered correctly.
As the page continues to load assets, reflows can happen (recall our example image that arrived late).
A reflow sparks a repaint and a re-composite.
5. Interactivity
Once the main thread is done painting the page, you would think we would be "all set."
That isn't necessarily the case.
If the load includes JavaScript, that was correctly deferred, and only executed after the onload event fires,
the main thread might be busy, and not available for scrolling, touch, and other interactions.
Time to Interactive (TTI) is the measurement of how long it took from that first request
which led to the DNS lookup and SSL connection to when the page is interactive
-- interactive being the point in time after the First Contentful Paint when the page responds to user interactions
within 50ms.
If the main thread is occupied parsing, compiling, and executing JavaScript,
it is not available and therefore not able to responsd to user interactions in a timely (less than 50ms) fashion.
In our example, maybe the image loaded quickly, but perhaps the anotherscript.js file was 2MB
and our user's network connection was slow. In this case the user would see the page super quickly,
but wouldn't be able to scroll without jank until the script was downloaded, parsed and executed.
That is not a good user experience. Avoid occupying the main thread.
That isn't necessarily the case.
If the load includes JavaScript, that was correctly deferred, and only executed after the onload event fires,
the main thread might be busy, and not available for scrolling, touch, and other interactions.
Time to Interactive (TTI) is the measurement of how long it took from that first request
which led to the DNS lookup and SSL connection to when the page is interactive
-- interactive being the point in time after the First Contentful Paint when the page responds to user interactions
within 50ms.
If the main thread is occupied parsing, compiling, and executing JavaScript,
it is not available and therefore not able to responsd to user interactions in a timely (less than 50ms) fashion.
In our example, maybe the image loaded quickly, but perhaps the anotherscript.js file was 2MB
and our user's network connection was slow. In this case the user would see the page super quickly,
but wouldn't be able to scroll without jank until the script was downloaded, parsed and executed.
That is not a good user experience. Avoid occupying the main thread.
参考
https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work
开课吧教程pdf
0 条评论
下一页