preface
Browsers have different meanings for different roles:
Ordinary users browse the web through it, care about stability, efficiency and security;
Front-end development students are concerned about compatibility and performance optimization. We can better understand various optimization methods by learning the internal mechanism of Chromium.
General introduction is not meaningful, let’s start from the dimensions of fast/stable/economy/security to see how the browser can achieve these points, take Chromium as an example, after all, open source, and rich data.
fast
Load faster
After Chromium gets the page request, it first classifies the resources that need to be requested, then verifies the permissions of the resources according to relevant security policies, and then sorts the loading order according to the priority, and then loads it according to the order.
Resources supported by Chromium fall into the following 14 categories:
|
type |
introduce |
|
kMainResource |
HTML page file resources fall into this category, including location (navigational input address), nested pages using frame/ IFrame, pages clicked through hyperlinks, and form submission |
|
kImage |
Image resources |
|
kCSSStyleSheet |
CSS resource |
|
kScript |
Script resources, such as JS resources |
|
kFont |
Font resources, such as font sets commonly used in web pages. Woff resources |
|
kRaw |
Mixed type resources, the most common type of Ajax request |
|
kSVGDocument |
SVG scalable vector graphics file resource |
|
kXSLStyleSheet |
Extend the stylesheet language XSLT |
|
kLinkPrefetch |
Link prefetch of HTML5 pages, such as dnS-prefetch |
|
kTextTrack |
Subtitle resources for video, i.e. |
|
kImportResource |
HTML Imports, which import an HTML file into other HTML documents, such as |
|
kMedia |
Multimedia resources, video, and audio belong to this category |
|
kManifest |
HTML5 applications cache resources |
|
kMock |
Reserved test type |
Resource permission verification is covered in the security section.
Chromium defines resource priorities as follows:
You can see that there are five levels of priority: Very-high, high, medium, low and very-low, among which page, CSS and font have the highest priority, followed by Script and Ajax. The default priority of pictures, audio and video is relatively low, and the lowest is prefetch resources.
Resources are downloaded in order of priority, which helps greatly in the experience.
Prefetch is an interesting thing, sometimes you may need to have some resources loaded and ready.
For example, when the user makes an error in the input box, the picture of an X will be displayed on the right. If the user waits for the loading time to display, there will be a delay. At this time, a link tag can be used:
<link rel="prefetch" href="image.png">Copy the codeWhen the browser is idle, it loads. You can also pre-resolve DNS:
<link rel="dns-prefetch" href="https://cdn.test.com"> Copy the codePre-establishing TCP connections:
<link rel="preconnect" href="https://cdn.chime.me">Copy the codeA resource cache
Caching of resources is an important means of optimizing browser loading. Loaded resources will be stored in the resource cache pool. When chromium needs to request resources, it will preferentially search from the cache pool, and the search key is the URL of the resource.
The resource cache pool uses the LRU algorithm to manage its resources. If it is a strong cache and can hit the cache, the request is not sent. If it is a negotiated cache, the request is still sent to the server.
Multi-process resource loading
Chromium uses a multi-process resource loading mechanism:
The Render process (corresponding to TAB) does not have permission to download resources. For security and efficiency reasons, the Render process actually obtains resources from the Browser process (corresponding to the entire Browser) through inter-process communication (IPC). Browser process has the permission to obtain local or network resources.
One advantage of this architecture is that all resource requests are handled entirely on the I/O thread, with no interference between activities generated by the user interface and network events. The resource filter runs in the I/O thread of the Browser process, intercepts resource request messages and forwards them to the ResourceDispatcherHost singleton of the Browser process.
This singleton interface allows the browser to control the network access permissions of individual Render processes. It also enables efficient and consistent resource sharing, such as:
1. Socket pool and connection restrictions: The browser can limit the number of enabled sockets for each profile, proxy, and {scheme, host, port} group (256, 32, and 6, respectively). Note that according to this rule, the same {host, port} can have up to six HTTP and six HTTPS connections.
2. Socket reuse: Persistent TCP connections are retained in the socket pool for a period of time after the request is processed for connection reuse, thus avoiding the additional DNS, TCP, and SSL startup overhead (if necessary) associated with initiating new connections.
3. Socket late binding: When the socket is ready to dispatch application requests, the requests are bound to the underlying TCP connection. This allows for better order optimization (e.g., higher priority requests arrive while the socket is in connection), and greater traffic (e.g. Reuse of “just used” TCP connections while existing sockets are available and new connections are being opened) and the generic mechanism for TCP preconnections and other optimizations.
4. Consistent session state: Authentication, cookies, and cache data are shared by all Render processes.
5. Global resource and network optimization: The browser can make decisions globally from all Render processes and pending requests. For example, a request made to a foreground TAB gives network priority.
6. Predictive optimization: Chromium builds and revises predictive models to improve performance by observing all network traffic.
In the case of the Render process, it simply sends a resource request message via IPC, which is typed with a unique request ID for the Browser process, and the rest is handled by the Browser kernel process.
Start the fast
There are many factors that affect page rendering efficiency, and Chromium has made a lot of optimization.
Optimization of the V8 engine
In 2017, the V8 got a major upgrade, switching to Ignition and TurboFan.
The goal is to reduce memory footprint, reduce startup time, and reduce complexity.
Composite
Composite is a technology where Chromium divides pages into multiple layers, opens multiple Compositor threads, and rasterizes them individually. When scrolling occurs on the page, all you need to do is compose a new frame because the layers have already been rasterized.
To figure out which elements belong to which Layer, the main thread generates a Layer Tree based on the Layout Tree. If you want an element to be layered, you can remind the browser to do so by setting the will-change style property.
Once the layer tree has been created and the drawing order determined, the main thread submits this information to the Compositor thread. The Compositor thread then rasterizes the layers. A layer can be as large as the entire length of the page, so the synthesizer thread divides them into blocks and sends each block to the raster thread. The raster thread rasterizes each graph block and stores them in GPU memory.
The Compositor thread assigns different priorities to the different blocks so that the portions within the viewport are rasterized preferentially. The layers also have multiple splices of different resolutions to handle zooming in and out.
Using the GPU
The original motivation for Chromium to use GPU is 3D CSS. In addition to speeding up 3D CSS, GPU can also be used to improve the rendering of ordinary pages. This idea has been implemented in Chromium. First of all, Chromium applied GPU acceleration to the rendering of video Canvas and other tags, and introduced the concept of image synthesis for efficient synthesis of overlapping elements in z-axis direction.
Chromium uses GPU to solve several performance issues:
1. Part of the rasterization task is handed over to GPU, and the time used for drawing is reduced (from 100ms to 4-5ms per frame), so as to gain more time for the execution of JavaScript
2. Using a synthesizer, some CSS animations can be drawn entirely on the GPU without the intervention of the CPU Main Thread, which can keep the animation smooth even if blocked by JavaScript
3. Layers do not affect each other, reducing the number of elements to traverse when reflow repaint occurs
Chromium introduced the GPU process on top of its multi-process architecture. This model is scalable, and on some lower performance platforms, GPU processes may be reduced to GPU threads. The renderer’s access to the GPU is sent as a command to the CommandBuffer, which is an area of memory shared by the renderer and GPU processes, and then notified to the GPU process via IPC. In general, the benefits of the architecture outweigh the costs of IPC. Since most instructions do not require a return value, this allows the renderer process to return immediately and continue processing other rendering tasks. In addition, isolating the rendering process in a secure sandbox that doesn’t have direct access to the GPU is especially important in Chromium scenarios where native extensions are available.
Run smoothly
Multithreaded model
Page running is not smooth performance is mainly Janky (jump frame), as the front end of the students, how much we all know about how to avoid the jump frame, the optimization of the lag, of course, the browser in this above also made a lot of improvement.
Chromium uses a multithreaded model based on asynchronous communication to solve the problem of page lag. That is, when a thread asks another thread to perform a task, it can do something else without waiting for the task to complete, thus avoiding stalling.
Optimization of events
Generally, our screen refresh rate is 60fps, but certain events are triggered at a higher rate than that. Chromium will merge successive events (e.g. Wheel, mousewheel, mousemove, pointermove, touchmove) for optimization purposes. And delay execution until the next frame of rendering.
Non-consecutive events such as KeyDown, KeyUp, MouseUp, mouseDown, TouchStart, and TouchEnd are triggered immediately.
steady
Multiprocess model
When introducing multi-process resource loading before, the Render process and Browser process were briefly mentioned. In order to ensure the stability of Browser, Chromium adopts multi-process architecture, separating Render, Plugin and GPU process from Browser process. These processes Crash to retrieve other exceptions without causing the entire browser to Crash.
There are four main types of Chromium processes:
1. The Browser process
Responsible for synthesizing the browser UI, including the title bar, address bar, toolbar and TAB page content. A Chromium instance has only one Browser process.
2. The Render process
Responsible for parsing and rendering web content. In general, a TAB should have a Render process.
We can also set startup parameters so that tabs with the same domain name run in the same Render process.
Both the Browser process and the Render process Render the UI through the GPU process when hardware-accelerated rendering is enabled. Whereas the Render process renders the web content in an off-screen window, such as a Frame Buffer Object, the Browser process renders the UI directly on the Frame Buffer, i.e. the screen.
Because of this, the UI rendered by the Render process cannot be seen on the screen until the Browser process has synthesized it.
(As an aside, speaking of off-screen Windows, I think of a practice in a previous project: in a Bindows project, when you drag a form, you throw the elements inside the form out of the viewport, and then put them back when the drag stops.)
3. The process of the Plugin
Run third-party plugins to extend the functionality of the browser. Flash is a Plugin that runs in a separate Plugin process.
To avoid creating too many Plugin processes, different instances of the same Plugin run in the same Plugin process.
That is, whether a Plugin of the same kind is created on the same TAB page, or a Plugin of the same kind is created on different TAB pages, they all run in the same Plugin process.
4. The process of the GPU
The GPU process was introduced earlier in rendering and will not be covered here.
province
In the official document of Chromium, there seems to be no content about energy saving. From what I’ve seen online, Chromium seems to take a lot of power, too. It’s said that due to sandbox limitations, when Chromium plays videos, it can only use GPU to speed up rendering, not decoding. But I don’t know this, so I’m not going to expand it.
security
When we access web pages through the browser, the browser needs to protect our data security. Information such as cookies, account numbers/passwords, which involve personal privacy and transaction payment, cannot be obtained by malicious web pages.
The same-origin policy
Domain is a very important concept in the browser security model. Domain consists of protocol, domain name and port. Access to resources between domains is strictly controlled. The DOM, user data, and XHR of the page are not accessible across domains.
CSP
In practice, the same origin policy is ineffective against many XSS (cross-site scripting attacks) because many resources can be loaded across domains (image, JS). Browsers provide CSPS to prevent XSS, using HTTP headers to specify which resources in which domains a web page is allowed to load.
CSP is made by the server through the HTTP header. Due to historical reasons, there are altogether three types of header types, which are only compatibility differences. For Chromium browser, we only need to pay attention to the Content-Security-Policy header. CSP headers are defined as follows:
The Content ws-security – Policy: name value; The name value; The name value;
The specification of instruction values is as follows:
HTTPS
We are all familiar with this, do not make special introduction.
The sandbox models
As mentioned earlier, Chromium is a multi-process architecture where web pages are rendered in a separate Render process, which provides the basis for implementing the sandbox model by placing web page rendering in a process with limited permissions.
The sandbox model depends on the technology provided by the operating system, and the security technology provided by different operating systems is different, so the implementation of the sandbox model on different systems is also different.
Take Chromium’s sandbox model in Android as an example. According to the documentation, the Android sandbox is the same as Linux.
Site Isolation
Site Isolation is a feature implemented by Chromium to deal with potential security problems and prevent malicious sites from accessing information from other sites.
Site Isolation provides a second layer of additional protection beyond the same-origin policy by combining the same-origin policy with address space isolation of processes, isolating different websites in different processes, and preventing one process from accessing sensitive information of other websites. In this way, even if there is a Spectre type bypass attack, data can be obtained from any memory address in the process, but not from other web sites.
Site Isolation mainly consists of two parts. Process model modification and cross-domain read masking (CORB).
site-per-process
Currently, the default process model in Chromium is called process-per-site-instance (there are other process models such as process-per-site and process-per-tab)[3]. The process model basically creates a process for each page, but there are still situations where different sites use the same process, such as iframes and parent pages, page jumps within the same TAB, and when there are too many tabs. Site Isolation introduces a new strategy called site-per-process. This policy is more stringent. For every site, whether you open in a new TAB, jump to the same TAB, or embed in iframes, a new process is required. The main effort here is to take the iframes and put them into different processes (OOPIF, out of process iframe).
Using the same protocol, the addresses of the same registered domain name (eTLD+1) belong to the same website, which is broader than the same Origin policy. Different subdomains and different ports are considered to be the same website.
CORB
Cross-origin Read Blocking (CORB) is a function that blocks cross-domain resource loading.
The same origin policy prevents malicious sites from accessing information from other sites, with some exceptions such as and
The resources
Inside Webkit Technology
The Story behind Chrome (Series)
How to load resources from Chrome source
Understand WebKit and Chromium: WebKit resource loading mechanism
HTML5 Canvas,WebGL,CSS Shaders,GLSL ambiguous relationship
Use Shader to make your pages smaller, shinier, and faster
Browser page resource loading process and optimization
Cache elimination algorithm -LRU algorithm
High Performance Networking in Chrome (2)
Chrome rendering pipeline performance improvements
HTTP cache – 304 and 200 from cache
Illustrate the basic workings of the browser
From browser multi process to JS single thread, JS running mechanism is the most comprehensive combing
Chromium in 21 days (1)
A performance optimization point for the Chromium CC layer
Inside look at modern web browser (part 4)
The inner workings of modern browsers
Chromium Web rendering Scheduler (Scheduler) implements analysis
Chromium web page rendering mechanism brief introduction and learning plan
Chromium page loading process brief introduction and learning plan
Multi-process Architecture
Internet Explorer Security series: Technological Changes in Internet Explorer (PART 1)
Internet Explorer Security series: Technological Changes in Internet Explorer (Part 2)
Open a page in a new window? Watch out for potholes!
The sandbox
Chromium multithreading model design and implementation analysis
Chromium Multi-process architecture brief introduction and learning plan
【OpenGL】17- Frame buffering and off-screen rendering
Chrome’s GPU process behind
The whole web at maximum FPS: How WebRender gets rid of jank
Chrome Site Isolation Overview
Rendering performance
XSS analysis and prevention
Why the New V8 is so Damn Fast
Scrolling optimization (infinite scrolling loading, scrolling elements with a large number of DOM, resulting in the problem of stalling optimization solution)