preface

My opinion is limited, if there is any improper description, please help to point out, if there is any mistake, we will timely correct.

Why comb through this article?

Recently, I happened to be asked about this question. After trying to sort it out, I found that the coverage of this question can be very wide, which is very suitable for carrying the knowledge system.

Not to mention the ridicule of this topic (this is a topic mentioned countless times, get a lot of people’s approval, is also a lot of people dislike), the purpose of this article is how to use this topic to comb their own front-end knowledge system!

In my opinion, every front-end staff, if they want to develop to a higher level, they will comb their knowledge system again. Without a firm knowledge system, they can’t go to a higher place.

Presentation form: This paper is not a list of all knowledge points, but tends to analyze + comb

Content: Only some important front-end knowledge points will be sorted out in this article, others may be omitted

Objective: The objective of this paper is to sort out a relatively complete front-end knowledge system

This article is the result of personal periodical review of knowledge system, and then modified and published as an article. Therefore, it is not guaranteed to be applicable to all personnel. However, I think this article has some reference value

In addition, if you have different opinions, can discuss together

———- super long warning, need to take a lot of time. ———-

This article is suitable for front-end personnel with certain experience, novice please avoid.

There is so much to read in this article that it is recommended to learn about the backbone first and then read it in batches.

This article is the front end, the knowledge of the former end domain is the focus

The outline

  • Do a pre-rating of the body of knowledge
  • Why is the body of knowledge so important?
  • Main Carding process
  • From receiving the URL from the browser to starting the network request thread
    • Multi-process browser
    • Multithreaded browser kernel
    • Parsing the URL
    • Network requests are individual threads
    • More and more
  • Start the network thread until it makes a complete HTTP request
    • The DNS query results in the IP address
    • TCP/IP request
    • Five layer Internet protocol stack
  • The request is received from the server to the corresponding background
    • Load balancing
    • Background processing
  • HTTP interaction between background and foreground
    • HTTP packet Structure
    • Cookies and optimizations
    • Gzip compression
    • Long connection and short connection
    • The HTTP 2.0
    • https
  • A separate cache issue, HTTP caching
    • Strong cache vs. weak cache
    • Brief description of cache headers
    • Head difference
  • Parsing the page flow
    • The process is briefly
    • HTML parsing, building DOM
    • Generating CSS Rules
    • Building a Render tree
    • Apply colours to a drawing
    • Simple layer and composite layer
    • Debugging in Chrome
    • The download of resources outside the chain
    • The loaded and domcontentloaded
  • Visual formatting model of CSS
    • Containing blocks
    • Controller Enclosure
    • Block Formatting Context (BFC)
    • IFC Inline Formatting Context
    • other
  • JS engine parsing process
    • JS interpretation stage
    • JS preprocessing stage
    • JS execution phase
    • Recycling mechanism
  • other
  • conclusion

Do a pre-rating of the body of knowledge

See this topic, without the help of search engines, their hearts have an answer?

Here, based on my current experience (I have learned about the situation of front-end personnel at different stages), there are probably the following situations :(the following are all met at the point, in fact, people at different stages generally have other hidden knowledge points)

level1:

A completely meaningless, faltering response is usually of this level:

  • The browser makes the request, the server returns the data, and the front end parses it into a web page and executes the script…

Such personnel are generally:

  • Cute new (those who have just touched the front end, including 0-6 months old may have this response)
  • Precipitator (someone who may have been in the front end for a few years, but is still in the early stages…)

Of course, the latter general will occasionally mention HTTP, background, browser rendering, JS engine and other keywords, but the basic is a detailed question do not know…

level2:

There is a preliminary concept, but it may not have been thoroughly combed, so that a complete system cannot be formed, or many details will not be developed, which may be like this :(may conform to several items)

  • Know the concept of an HTTP request after a browser enters a URL
  • Have the concept of background, roughly know the front and back end interaction, know that the front and back end only rely on HTTP packets communication
  • I know that the browser will parse the data after receiving it, but I am not familiar with the specific process (such as render tree construction process, layout, paint, composite layer and simple layer, common optimization scheme, etc.).
  • Have some concept of the parsing process of JS engine, but not familiar with details (such as specific parameters, functions, variable promotion, execution context, VO, AO, scope chain, recycle mechanism, etc.)
  • If you may know some basic concepts of the HTTP specification, but are not familiar with them (such as HTTP packet structure, common headers, caching mechanism, HTTP2.0, HTTPS and other features, but not familiar with cross-domain and Web security).

At this point, after seeing the above a lot of concepts, the heart should also have a little bottom…

In fact, most of the front-end staff may be at level2, but it is not easy to get out of this stage. It usually requires accumulation and continuous learning

Such personnel are generally:

  • Ordinary staff who have worked for 1-3 years or so (accounting for most of them, and most of them have worked for 3 years or so without substantial improvement)
  • Old people who have worked for more than 3 years (most of these people are very skilled in business, one can be used for several purposes, but their foundation is relatively weak and they may not have tried to write frames, components, scaffolding, etc.)

Most junior and intermediate students are stuck in this stage. If you want to break through, keep learning and accumulation, it will naturally follow

level3:

Basically can reach this step, is not high order is close to high order, because many concepts are not back to back to understand, and to understand so much, need to form a system, generally need to accumulate, not in a day.

What kind of answers do they usually include? (Here is my brief answer as an example), generally, the staff at this stage will meet several criteria (not all of them, of course, there may be some missing here) :

  • First of all, leave out keyboard input, interaction with the operating system, screen display principles, hardware interaction with network cards, etc.
  • Have an overall concept of the browser model, know that the browser is multi-process, the browser kernel is multi-threaded, understand the difference between process and thread, and enter a URL will open a new network thread
  • Have an understanding of the process from starting a network thread to making a complete HTTP request (such as DNS queries, TCP/IP links, five-tier Intel stack, etc.), and optimizations such asdns-prefetch)
  • Knowledge of requests received from the server to the corresponding backend (e.g. load balancing, secure interception, and back-code processing)
  • Familiarity with background and foreground HTTP interactions (including HTTP packet structure, scene headers, Cookies, cross-domain, Web security, HTTP caching, HTTP2.0, HTTPS, etc.)
  • Familiar with the parsing process of HTTP data packets received by the browser (including parsing HTML, lexical analysis and parsing into DOM tree, parsing CSS to generate CSS rule tree, merging into render tree, Then layout, painting and rendering, which may also include composite layer composition, GPU drawing, outer chain processing, loading sequence, etc.)
  • Familiar with JS engine parsing process (including JS interpretation, preprocessing, execution context, VO, scope chain, this, recycle mechanism, etc.)

As can be seen, the above includes a large number of concepts, only partial to the front, and without detailed expansion, there are so many concepts, so I think if there is no own opinion, without the formation of their own knowledge system, it is useless to just look, recite, after a period of time will forget all.

Let’s talk a little bit more about what kind of people you might be at this stage. (Not always accurate, but mostly based on a little reality and a lot of speculation)

  • Work for more than 2 years of the front end (basically if according to the normal progress, at least two years of contact with the front end will begin to advanced, of course, now many are school began to learn, and some are gifted, not easy to predict…)
  • Or someone who is already very familiar with another language and then moves to the front end (basically quickly improving the front end)

Generally meet this condition will have a variety of hidden attributes (such as read the source code of each major framework, component, write their own component, frame, scaffolding, do a large project, organize a number of high-quality blog posts, etc.)

level4:

As I have not reached the level, so roughly say their own views.

In general, at this level, many bosses are not just a technology stack, but become technical experts, technical leaders and other roles. So just answering a technical question is not enough to see the level, it may depend more on the architecture, overall control, large engineering construction ability and so on

However, there are probably some answers for some tech-obsessed bigwigs :(guess)

  • From keyboard to system interaction, from browser to CPU, from scheduling mechanism to system kernel, from data request to binary, assembly, from GPU drawing to LCD display, and then analyze the process, memory and so on at the bottom of the system

Anyway, from software to hardware, to materials, to molecules, atoms, quanta, Schrodinger’s cat, the origin of man, the Big Bang, parallel universes? It feels right…

Refer to the original source of this question:

Fex.baidu.com/blog/2014/0…

Why is the body of knowledge so important?

Why is the body of knowledge important? Here are a few examples

Suppose you were asked this question (one that comes to mind at random) :

  • How to understandgetComputedStyle

Before sorting out the body of knowledge, the answer might be:

  • Common version:getComputedStyleGets all the final CSS property values for the current element (the result of the final calculation), and passeswindow.getComputedStyleIs equivalent todocument.defaultView.getComputedStylecall
  • Version details:window.getComputedStyle(elem, null).getPropertyValue("height")The possible values are zero100pxAnd, even if CSS says yesinherit.getComputedStyleI’m going to figure it out. Note, however, that if the element’s background color is transparent, thengetComputedStyleThe obtained background is the transparent one (since transparency itself is also valid), not the parent node’s background. So it doesn’t have to be the final color.

As far as the API is concerned, the above answers are pretty comprehensive.

But it can go on and on.

For example, the answer would now be:

  • getComputedStyleGets all the final CSS property values for the current element,window.anddocument.defaultView.Equivalent…
  • getComputedStyleIt can cause backflow, because it needs to obtain some information about the ancestor node for calculation (such as width height), so use it with caution. Backflow can cause performance problems. Then, as appropriate, topics are directed to backflow, redraw, browser rendering principles, etc. Of course, there are other operations that can cause backflow, such asoffsetXXX.scrollXXX.clientXXX.currentStyle, etc.

Here’s another example:

  • visibility: hiddenanddisplay: noneThe difference between

Answer:

  • Common answer, one hides, but occupies position, one hides, does not occupy position
  • Further,displaySince hiding does not occupy the location, it causes changes in the DOM tree, which can cause backflow and cost a lot
  • Further, when an element on a page often needs to be switcheddisplayHow to optimize, generally will use composite layer optimization, or lower requirementsabsoluteYou can also take it out of the normal document flow. You can then redirect the topic to the normal document flow,absoluteDocument flow, compound layer differences,
  • Further, we can describe the browser rendering principle and the differences between composite layer and normal layer drawing (composite layer allocation, independent drawing, performance improvement, but not too much, and implicit composition, etc.).

The above is probably the answer after the knowledge is systematized, will be more comprehensive, easy to go from shallow to deep, and the opportunity to dig deeper

Focus on front-end knowledge

This part of the content is from a personal perspective, not necessarily the right answer

First of all, it is clear that computer knowledge can be endless digging, and the focus of this paper is to comb the front end of the key knowledge

For the front end (node.js is probably not mentioned here, but the client front end), there are several major categories of knowledge in order of importance:

  • Core knowledge, must master, is also the most basic, such as browser model, rendering principle, JS parsing process, JS operating mechanism, as the skeleton to carry the knowledge system
  • Key knowledge, often each piece is a knowledge point, and these knowledge points are very important, such as HTTP related, Web security related, cross-domain processing and so on
  • Process knowledge, it may a more is to understand, a little practice, but may not know the above so deeply, such as Intel five layer protocol stack, hybrid mode, move the native development, background and so on related (of course, in different areas, there may be some knowledge will rise to the key knowledge level, such as development of a hybrid, Native development is important)

Why is it divided in this way?

This probably has something to do with personal technical growth.

Remember the beginning of learning front-end knowledge, is a bit of accumulation, a knowledge point a knowledge point to conquer.

In this way, although in a very long period of time accumulated a lot of knowledge, but, always can not connect it together. Each comb is very scattered, unable to maintain consistency of thought.

Until later, after combing through the browser rendering principle, JS running mechanism and JS engine parsing process, I felt like I got through the ren Du two veins, and had an overall architecture, and the previous knowledge points were all coherent.

After sorting out a knowledge system, even if I learn new knowledge in the future, I will try my best to draw closer to this system, which is interlinked, easier to understand and less easy to forget

Main Carding process

Back to this question, how do you answer it? Let’s start with a skeleton

In the knowledge system, the most important is the skeleton, the context. Once you have a skeleton, it’s easy to fill in the details. Therefore, first sort out the main process:

1. From the browser to receive the URL to start the network request thread (this part can expand the mechanism of the browser and the relationship between process and thread) 2. Start the network thread until it sends a complete HTTP request (this part involves DNS query, TCP/IP request, layer 5 Internet protocol stack, etc.) 3. The server receives the request and the corresponding background receives the request (this part may involve load balancing, security interception and processing inside the background, etc.) 4. HTTP interaction between background and foreground (this part includes HTTP header, response code, packet structure, cookie and other knowledge, which can improve cookie optimization of static resources, as well as encoding and decoding, such as Gzip compression, etc.) 5. HTTP caching (this part includes HTTP cache headers, eTAG, catch-control, etc.) The parsing process after the browser receives HTTP packets (parsing HTML-lexical analysis and then parsing into DOM tree, parsing CSS to generate CSS rule tree, merging into render tree, 7. Visual format model of CSS (element rendering rules, such as include block, controller box, BFC, etc.) JS engine parsing process (JS interpretation stage, preprocessing stage, execution stage generate execution context, VO, scope chain, recycle mechanism, etc.) 9. Others (can expand different knowledge modules, such as cross domain, Web security, Hybrid mode, etc.)Copy the code

Tease out the skeleton, and then fill in the details

From receiving the URL from the browser to starting the network request thread

This part expands the content is: browser process/thread model, JS operation mechanism

Multi-process browser

Browsers are multi-process, with a master process and a new process for each TAB page (in some cases multiple tabs merge processes).

Processes may include master processes, plug-in processes, Gpus, TAB pages (browser cores), and so on

  • Browser process: the main process of the Browser (responsible for coordination and control), there is only one
  • Third-party plug-in process: Each type of plug-in corresponds to one process, which is created only when the plug-in is used
  • GPU process: a maximum of one, used for 3D drawing
  • Browser rendering process (kernel) : one process per Tab page by default, with no influence on each other, controlling page rendering, script execution, event handling, etc. (sometimes optimized, such as multiple blank tabs will be merged into one process)

The diagram below:


Multithreaded browser kernel

Each TAB page can be thought of as a browser kernel process, and this process is multi-threaded, with several classes of child threads

  • The GUI thread
  • JS engine thread
  • Event trigger thread
  • Timer thread
  • Network request thread

As you can see, the JS engine is a thread in the kernel process, which is why it is often said that the JS engine is a single thread

Parsing the URL

When you enter a URL, it is parsed (urls are essentially Uniform resource locators)

A URL generally consists of several parts:

  • protocol, protocol headers, such as HTTP, FTP, etc
  • host, host domain name or IP address
  • portAnd the port number
  • path, directory path
  • query, that is, query parameters
  • fragment, i.e.,#Hash value, usually used to locate a location

Network requests are individual threads

A separate thread is created for each network request, for example, if the URL is resolved to HTTP, a new network thread is created to handle the resource download

Therefore, the browser will open up a network thread to request the resource according to the parsed protocol.

More and more

Due to the length of the relationship, here is about a main process, about the browser process mechanism, more can refer to the previous summary of an article (because the content is too much, including JS running mechanism, process thread details)

From browser multi process to JS single thread, JS running mechanism is the most comprehensive combing

Start the network thread until it makes a complete HTTP request

This part mainly includes: DNS query, TCP/IP request construction, five layer Internet protocol stack and so on

The trunk is still combed first, and some detailed processes are not expanded (because it would be too much to expand).

The DNS query results in the IP address

If you enter a domain name, perform DNS resolution to obtain an IP address. The process is as follows:

  • If the browser has a cache, use the browser cache, otherwise use the native cache, or use host
  • If no IP address exists on the local server, the system queries the CORRESPONDING IP address on the DNS server (through routing and caching, etc.)

Note that domain names may be queried through the CDN scheduler (if CDN storage is available).

In addition, DNS resolution is time-consuming. If too many domain names are resolved, the first screen load will be slow. Therefore, dnS-Prefetch optimization can be used

This section can be expanded in depth, please go to the Internet search, there is no space here (you can see a very detailed answer online)

TCP/IP request

The essence of HTTP is TCP/IP requests

You need to know the three-way handshake rule to establish a connection and the four-way wave when disconnecting

TCP divides HTTP long packets into short packets and establishes a connection with the server through three-way handshake for reliable transmission

Steps of the three-way handshake :(abstract)

Client: Hello, are you server? Server: Hello, I'm server, are you client client: Yes, I'm clientCopy the code

Once the connection is established, the data is transferred

Then, when the connection is disconnected, four waves are required (four waves are required because it is full-duplex)

Steps for four waves :(abstract)

Passive: RECEIVED the message that the channel is closed. Passive: Let me also tell you that my active channel to you is also closed. Active: Finally received the data, and then the two parties cannot communicateCopy the code

TCP/IP concurrency limit

Browsers limit concurrent TCP connections under the same domain name (2-10)

And in HTTP1.0 there is often a TCP/IP request for each resource download

Therefore, there are a lot of resource optimization schemes for this bottleneck

Get and POST

Get and POST are both TCP/IP in nature, but they differ in TCP/IP in addition to HTTP.

Get generates one TCP packet and post two

Specifically:

  • When a GET request is made, the browser willheadersanddataAll together, the server responds with 200,
  • When a POST request is made, the browser sends it firstheaders, server response100 continue.

The browser sends data, and the server responds with 200 (returns data).

Again, the difference here is the specification level, not the implementation level

Five layer Internet protocol stack

It’s actually kind of hard to remember all of this, and it’s okay if you don’t remember all of it, but you have to have a general idea

It’s a concept: an HTTP request from the client to the server goes through a series of processes.

In a nutshell:

From sending HTTP requests at the application layer, to establishing TCP/IP connections through three-way handshake at the transport layer, to IP addressing at the network layer, to encapsulation into frames at the data link layer, and finally to the physical layer using physical media transmission.

Of course, reception on the server is the reverse step

The five-tier Intel stack is essentially:

1. Application layer (DNS, HTTP) The DNS resolves to AN IP address and sends an HTTP request 2. Transport layer (TCP, UDP) Establishing a TCP connection (three-way handshake) 3. Network layer (IP,ARP) IP address 4. 5. Physical layer (using physical media to transmit bit stream) Physical transmission (then transmission through twisted pair, electromagnetic wave and other media)Copy the code

Of course, there is also a complete OSI seven-layer framework, with more session layers and presentation layers.

OSI seven-layer framework: physical layer, data link layer, network layer, transport layer, session layer, presentation layer, application layer

Presentation layer: mainly deals with the presentation of information exchanged in two communication systems, including data format exchange, data encryption and decryption, data compression and terminal type conversion, etc. Session layer: it specifically manages the dialogue between different users and processes, such as the control of login and logout processCopy the code

The request is received from the server to the corresponding background

The server does a lot of processing internally when it receives a request

This is not a professional back-end analysis, so it is only a brief introduction, not in-depth

Load balancing

For large projects, because of the large number of concurrent visits, it is often too much for one server. Therefore, there are generally several servers in a cluster, and then cooperate with reverse proxy to achieve load balancing

Of course, there is more to load balancing than this, so I won’t go into it here…

To put it simply:

All user-initiated requests are directed to the scheduling server (reverse proxy server, for example, installed with NGINx control load balancing). The scheduling server then allocates different requests to the servers in the corresponding cluster according to the actual scheduling algorithm. The scheduler then waits for the HTTP response from the actual server and feeds it back to the user

Background processing

Generally, the backend is deployed in a container, so it is generally:

  • First the container receives the request (such as the Tomcat container)
  • The request is then received by the daemon in the corresponding container (such as a Java program)
  • Then the background will have its own unified processing, processing and response results

Summarized below:

  • There are some common backend authentication, such as security interception, cross-domain authentication
  • If this step does not comply with the rules, the corresponding HTTP packet is directly returned (for example, rejecting the request).
  • Then, when the validation passes, it goes to the actual background code, where the program receives the request and executes it (database query, bulk computation, etc.)
  • When the program completes execution, it returns an HTTP response package (typically this step is also wrapped in multiple layers).
  • The packet is then sent from the back end to the front end to complete the interaction

HTTP interaction between background and foreground

During the interaction between the front and back ends, HTTP packets are used as information carriers

So HTTP is an important piece of content, and this section focuses on it

HTTP packet Structure

A packet generally contains a general header, a request/response header, and a request/response body

General head

This is also the most information a developer has ever seen, including the following:

Request Url: address of the requested Web server Request Method: Request Method (Get, POST, OPTIONS, PUT, HEAD, DELETE, CONNECT, TRACE) Status Code: Remote Address: the Address of the requested Remote server (which will be converted to IP)Copy the code

For example, in the case of cross-domain rejection, methods may be options, status codes 404/405, etc. (of course, there are many possible combinations)

Method is generally divided into two batches:

HTTP1.0 defines three request methods: GET, POST, and HEAD. HTTP1.1 adds five new request methods: OPTIONS, PUT, DELETE, TRACE, and CONNECT.Copy the code

The most commonly used one is the status code, which is often judged by the status code, such as (to list a few of the most common) :

200 -- indicates that the request was successfully completed and the requested resource is sent back to the client 304 -- The requested page has not been modified since the last request, Ask client to use local cache 400 -- client request error (for example, it can be blocked by security module) 401 -- unauthorized request 403 -- Access forbidden (for example, it can be forbidden when not logged in) 404 -- Resource not found 500 -- server internal error 503 -- service unavailable...Copy the code

Again, enumerate the meanings of the roughly different ranges of states

1xx -- indicating message, request received, continue processing 2XX -- success, request received, understood, accepted 3XX -- redirection, further action must be taken to complete the request 4XX -- client error, request has syntax error or request cannot be implemented 5XX -- server error, The server failed to fulfill a valid requestCopy the code

In short, when a request goes wrong, the status code can help quickly locate the problem, and the full version of the status can be searched on the Internet itself

Request/response headers

Request and response headers are also frequently used for analysis

Common request headers (parts) :

Accept: Accept-encoding: Indicates the compression Type supported by the browser, such as gzip. If the value exceeds the compression Type, content-type cannot be received. The type of entity content the client sends cache-control: Specifies a caching mechanism for requests and responses, such as no-cache if-modified-since: last-modified for the server to match to see If the file has changed. If-none-match (http1.1) specifies the server time for which a request is not made, and the server time for which a request is not made. The server ETag is used to match whether the file content has changed (very accurately). For example, keep-alive Host: URL of the requested server Origin: where the original request originated (only down to the port),Origin has more respect for privacy than Referer: The source URL of the page (applicable to all types of requests, down to the detailed page address, which is often used by CSRF interceptors) User-agent: Some necessary information about the User client, such as the UA headerCopy the code

Common response headers (parts) :

Access-control-allow-headers: specifies the request Headers allowed by the server. Headers access-Control-allow-methods: Specifies the request Headers allowed by the server. Access-control-allow-origin: specifies the request Headers allowed by the server. Content-type: specifies the Type of entity Content returned by the server. Date: Specifies the time when data is sent from the server. Cache-control: specifies the time when data is sent from the server. 6. tell the browser or other client when it is safe to cache a document last-modified: Expires: The time at which a document should be considered expired so that it cannot be cached max-age: ETag: the current value of the entity tag of the request variable set-cookie: Sets the Cookie associated with the page. The server passes the Cookie to the client keep-alive through this header. If the client has keep-alive, the Server also responds (e.g. Timeout =38). Server: Some information about the ServerCopy the code

In general, request headers and response headers are matched for analysis.

For example, Accept in the request header must match the content-Type in the response header, otherwise an error will be reported

For example, in a cross-domain request, Origin in the request header must match access-Control-Allow-Origin in the response header; otherwise, a cross-domain error will be reported

For example, when caching is used, if-modified-since and if-none-match of the request header correspond to last-Modified and ETag of the response header, respectively

There are also many analysis methods, which are not described here

Request/response entity

In HTTP requests, in addition to headers, there are message entities, generally speaking

The request entity will put some of the required parameters in (for post request).

For example, entities can put serialized forms of parameters (a=1&b=2), or directly put Form objects (Form Data objects, which can be uploaded with parameters and files), etc

In general, the response entity is to put the content that the server needs to pass to the client

The current interface request is a JSON format for the information in the entity, whereas a page request is an HTML string that is parsed and rendered by the browser.

CRLF

CRLF (Carriage-Return line-feed), which stands for Carriage Return Line Feed, usually exists as a delimiter

There is a CRLF separation between the request header and the entity message and a CRLF separation between the response header and the response entity

In general (delimiter category) :

CRLF->Windows-style
LF->Unix Style
CR->Mac Style
Copy the code

The following figure shows a brief analysis of the HTTP packet structure of a request


Cookies and optimizations

Cookie is a local storage mode of the browser. It is generally used to help the communication between the client and the server, and is often used for identity verification, combined with the session of the server.

The scenario is as follows (brief description) :

In the login page, when the user logs in, the server will generate a session, which contains information about the user (such as user name, password, etc.) and then a sessionID (equivalent to the key corresponding to the session on the server). Then the server will write cookies in the login page. Jsessionid = XXX and then the browser has the cookie. When you visit the page under the same domain name in the future, it will automatically bring the cookie, automatic verification, no need to log in again within the valid time.Copy the code

This is a brief description of common scenarios for cookies (of course, there are more factors to consider in the real world)

Generally speaking, cookies are not allowed to store sensitive information (do not store user names and passwords in plain text), because it is very insecure. If you must forcibly store cookies, first of all, you must set httpOnly in the cookie (so that it cannot be operated by JS), in addition, you can consider rsa and other asymmetric encryption (because in fact, Browser native is also easy to crack, not secure)

In addition, because the browser will bring local cookies by default when requesting resources of the same domain name, this situation needs to be optimized in some scenarios.

For example, the following scenario:

The client has cookies under domain name A (this can be written by the server when logging in) and then there is A page under domain name A that has A lot of dependent static resources (all domain name A, for example, there are 20 static resources) and then there is A problem. When the page loads and requests these static resources, The browser is going to put cookies on it by default, so each of these 20 HTTP requests for static resources has to put cookies on it, and static resources don't actually require cookie validation so it's a huge waste and it slows down access (because there's more content)Copy the code

Of course, there are optimizations for this scenario (multi-domain splitting). The specific approach is:

  • Group static resources into different subdomain names
  • The cookies of the parent domain are not included in the request, so waste is avoided

Speaking of multi-domain splitting, here is another question, that is:

  • On mobile terminals, if too many domain names are requested, the request speed will be reduced (because the whole domain name resolution process is time-consuming, and the bandwidth of mobile terminals is generally not as good as that of PCS).
  • In this case, an optimization scheme is needed:dns-prefetch(Allow your browser to resolve DNS domain names in advance when idle, but use them wisely.)

For the cookie interaction, see the following summary


Gzip compression

First, make it clear that gzip is a compression format that requires browser support (which browsers generally do today) and that gzip compression is very efficient (up to 70%)

Gzip is then typically started by Web servers such as Apache and Tomcat

Of course servers will have other compression formats besides Gzip (deflate, for example, is not as efficient and popular)

Therefore, you only need to enable GZIP compression on the server, and then all subsequent requests are based on gZIP compression format, very convenient.

Long connection and short connection

Let’s start with the TCP/IP definition:

  • Long connection: Multiple packets can be sent continuously on a TCP/IP connection. If no packets are sent during the TCP connection, both parties need to send detection packets to maintain the connection. Generally, they need to maintain the connection online (similar to heartbeat packets).
  • Short connection: A TCP connection is established when data is exchanged between communication parties. After data is sent, the TCP connection is disconnected

Then at the HTTP level:

  • http1.0By default, short connections are used, that is, the browser establishes a connection without making an HTTP operation and then breaks the connection at the end of the task, such as a separate connection for each static resource request
  • As of http1.1, long connections are used by default, and this line is used for long connectionsConnection: keep-aliveIn the long connection case, when a web page is opened, the TCP connection for HTTP transmission between the client and the server is not closed. If the client accesses the page of the server again, the established connection is used

Note: Keep-alive does not last forever. It has a duration and is usually configured on the server (such as Apache). Keep-alive only works when both the client and the server support it

The HTTP 2.0

Http2.0 is not HTTPS, it is the next generation of HTTP specification (e.g. HTTPS request can be HTTP2.0 specification)

Then briefly summarize the significant differences between HTTP2.0 and HTTP1.1:

  • In http1.1, each request for a resource is required to open a TCP/IP connection, so the corresponding result is that each resource is corresponding to a TCP/IP request, because TCP/IP itself has a concurrent limit, so when the resource is more than one, the speed is significantly slower
  • Http2.0, a TCP/IP request can request multiple resources, that is, as long as a TCP/IP request, you can request several resources, split into smaller frame requests, speed significantly improved.

So, if http2.0 is fully applied, many of the optimizations in HTTP1.1 will not be used (such as packaging into sprites, static resources multi-domain split, etc.).

Then briefly summarize some of the features of HTTP2.0:

  • Multiplexing (i.e. one TCP/IP connection can request multiple resources)
  • Header compression (HTTP header compression, reduced volume)
  • Binary frame splitting (a binary frame splitting layer is added between the application layer and the transmission layer to improve transmission performance and achieve low latency and high throughput)
  • Server-side push (the server can send multiple responses to a request from the client and can actively notify the client)
  • Request priority (If a stream is assigned a priority, it is processed based on that priority, with the server deciding how many resources it needs to process the request.)

https

HTTPS is a secure version of HTTP. Some operations, such as payment, are based on HTTPS because HTTP requests are too insecure.

The simple difference between HTTPS and HTTP is that an SSL link is established before a request is made, ensuring that subsequent communication is encrypted and cannot be easily intercepted and analyzed

Generally speaking, if you want to upgrade your website to HTTPS, you need backend support (which requires certificate application, etc.), and then HTTPS is more expensive than HTTP (because of the additional need to establish secure links, encryption, etc.), so http2.0 is generally better with HTTPS (because http2.0 is faster).

In general, the main focus is on the SSL/TLS handshake flow, as follows (briefly) :

1. The browser requests an SSL link and sends a random number - Client Random and an encryption method supported by the Client, such as RSA encryption, to the server. In this case, plaintext transmission is performed. 2. The Server selects a set of encryption algorithms and Hash algorithms, returns a random number - Server Random, and sends its identity information back to the browser in the form of a certificate (the certificate contains the website address, asymmetric encrypted public key, and certificate authority information) 3. After the browser receives the certificate from the server - verifies the validity of the certificate (whether the issuer is legitimate, whether the url contained in the certificate is the same as the one being accessed), if the certificate is trusted, the browser will display a small lock, otherwise there will be a prompt - after the user receives the certificate (regardless of the letter does not trust), Browsing produces a new random number -- Premaster Secret, and then the public key in the certificate and the specified encryption method encrypt 'Premaster Secret' and send it to the server. - Using Client Random, Server Random and Premaster Secret to generate symmetric encryption key for HTTP link data transmission through certain algorithms - 'session key' - using the agreed HASH algorithm to calculate the handshake message, The generated 'session key' is used to encrypt the message, and finally all the generated information is sent to the server. 4. The server receives the reply from the browser -- decrypts it with its own private key using the known encryption and decryption method, obtains' Premaster secret '-- generates' session key' using 'session key' to decrypt the handshake message sent by the browser. Verify that the Hash is the same as the one sent by the browser - use 'session key' to encrypt a handshake message and send it to the browser 5. The browser decrypts and computes the HASH of the handshake message. If the HASH is the same as that sent by the server, the handshake is complete.Copy the code

All subsequent HTTPS traffic data will be generated by the previous browsersession keySymmetric encryption algorithm is used for encryption

Here is a diagram (source: Ruan Yifeng – illustration of SSL/TLS protocol)


A separate cache issue, HTTP caching

The use of caching can greatly improve the efficiency of HTTP interactions at the front and back ends, and it is almost mandatory for front-end projects that require performance

Strong cache vs. weak cache

Caches can be easily divided into two types: strong cache (200 from cache) and negotiated cache (304).

The differences are summarized as follows:

  • Strong cache (200 from cache), if the browser determines that the local cache is not expired, it directly uses it without sending an HTTP request
  • Negotiated cache (304), the browser makes an HTTP request to the server, which then tells the browser that the file has not changed and lets the browser use the local cache

For negotiated caches, forcing a refresh with Ctrl + F5 invalidates the cache

With strong caching, however, the resource path must be updated before new requests can be made (changing the path is a different resource, which is a common technique used in front-end engineering).

Brief description of cache headers

Strong cache and negotiated cache were mentioned above, but how are they distinguished?

The answer is through different HTTP header controls

Take a look at these heads:

If-none-match/e-tag, if-modified-since/last-modified, cache-control/max-age, Pragma/ExpiresCopy the code

So these are the common headers that we use in caches, so we don’t expand them here. Just to list the general usage.

Belonging to strong cache control:

(http1.1) cache-control/max-age (http1.0) Pragma/ExpiresCopy the code

Note: max-age is not a header, it is the value of the cache-control header

Belonging to the negotiated cache control:

(http1.1) if-none-match/e-tag (http1.0) if-modified-since/last-modifiedCopy the code

As you can see, with http1.1 and HTTP1.0 mentioned above, these different headers are from different HTTP eras

There is also a meta tag in HTML pages that controls caching schemes -Pragma

<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
Copy the code

However, this solution is rarely used because of poor support, such as the caching proxy server certainly does not support, so it is not recommended

Head difference

To be clear, HTTP evolved from HTTP1.0 to HTTP1.1

In HTTP1.1, there are some new things that make up for http1.0.

Cache control in HTTP1.0:

  • Pragma: Strictly speaking, it does not belong to the specific cache control header, but it doesno-cache(this is a compilation control that implements specific instructions, and has been widely used in the past due to compatibility with HTTP1.0)
  • ExpiresIt is used to control that the browser will not make a request before the specified time. Instead, the browser will directly use the local cache. Note that Expires usually represents a server-side time, such asExpires: Fri, 30 Oct 1998 14:19:41
  • If-Modified-Since/Last-Modified: These two come in pairs and belong to the negotiated cache, where the browser header isIf-Modified-Since, and the server side isLast-Modified, which is used when making a request, ifIf-Modified-SinceandLast-ModifiedIf yes, the server resource has not changed, so the server does not return the resource entity, but only the header, notifying the browser that the local cache is available.Last-Modified“, as the name implies, refers to the time when a file was last modified, and can only be accurate to1swithin

Cache control in HTTP1.1:

  • Cache-Control: Cache control header, including no-cache and max-age
  • Max-AgeMax-age is a value in the cache-control header, not a separate header, for exampleCache-Control: max-age=3600And it is worth the absolute time, calculated by the browser itself
  • If-None-Match/E-tag: These two come in pairs and belong to the negotiated cache, where the browser header isIf-None-Match, and the server side isE-tag, similarly, after making the request, ifIf-None-MatchandE-tagA match indicates that the content has not changed, notifying the browser to use the local cache. Unlike last-Modified, e-tag is more accurate, and it’s something like a fingerprint, based onFileEtag INode Mtime SizeGenerate, that is, as long as the file changes, the fingerprint will change, and there is no 1s accuracy limit.

Max-age versus Expires?

Expires uses server-side time

But sometimes there is a situation where the client time is out of sync with the server

In this case, there may be a problem, causing the browser’s local cache to become useless or never expire

So Expires is generally not recommended after HTTP1.1

Max-age does not have this problem because it uses calculations of the client’s local time

Therefore, max-age is recommended.

Note that cache-control takes precedence if both cache-control and Expires are enabled.

E-tag compared to last-Modified?

Last-modified:

  • Indicates when the server file was last changed
  • One drawback is that it can only be accurate to 1s,
  • Then there is the problem that some server files change periodically, causing the cache to become invalid

The E – tag:

  • Is a fingerprint mechanism that represents the fingerprint associated with a document
  • Only the files change, and as the files change,
  • There is no precise time limit, as soon as the file is read, the e-tag will be different

If both e-Tag and Last-Modified are used, the server checks the E-tag first

The overall relationship between the cache headers is shown below


Parsing the page flow

I mentioned HTTP interaction earlier, so what follows is that the browser takes the HTML, parses it, and renders it

A lot of this section refers to online sources, especially pictures, and references to articles from sources

The process is briefly

After the browser kernel gets the content, the rendering steps can be roughly divided into the following steps:

1. Parse HTML to build a DOM tree 2. Parse CSS to generate a CSS rule tree 3. 4. Render tree (Layout/reflow), responsible for the size of each element, location calculation 5. 6. The browser will send the information of each layer to the GPU, which will composite the layers and display them on the screenCopy the code

The diagram below:


HTML parsing, building DOM

HTML parsing is the first step in the rendering process.

To put it simply, this step goes like this: The browser parses the HTML and builds a DOM tree.

But actually, when analyzing the overall build, you can’t just brush it off, you have to expand it a little bit.

From parsing HTML to building the DOM, of course, the process can be summarized as follows:

Bytes → characters → tokens → nodes → DOM
Copy the code

For example, suppose you have an HTML page like this:

<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>Copy the code

The browser does the following:


To list some of the key processes:

1. Conversion: The browser will obtain HTML content (Bytes) into a single character based on its encoding. 2. Tokenizing word segmentation: the browser will convert these characters into different token according to the HTML specification standard. Each token has its own unique meaning and set of rules. 3. Lexing: The result of word segmentation is a bunch of tokens, which are then converted into objects that define their properties and rules respectively. Because HTML tags define the relationship between different tags, the relationship is like a tree structure. For example, the parent node of the body object is the HTML object, and the parent node of the segment P object is the body objectCopy the code

The final DOM tree looks like this:


Generating CSS Rules

Similarly, CSS rule tree generation is similar. A brief introduction as follows:

Bytes → characters → tokens → nodes → CSSOM
Copy the code

For example, style.css would look like this:

body { font-size: 16px }
p { font-weight: bold }
span { color: red }
p span { display: none }
img { float: right }
Copy the code

So the final CSSOM tree is:


Building a Render tree

Once the DOM tree and CSSOM are in place, it’s time to build the render tree

In general, render trees correspond to DOM trees, but not strictly one-to-one

This is because some invisible DOM elements are not inserted into the render tree, such as invisible tags like head or display: None

As a whole, you can see the picture:


Apply colours to a drawing

With the Render tree in place, it’s time to start rendering. The basic flow is as follows:


The four important steps in the diagram are:

1. Calculate CSS style 2. Build render tree 3. Draw, draw the imageCopy the code

Then, the lines and arrows in the diagram represent dynamic changes to the DOM or CSS through JS, resulting in a Layout or Repaint

There is a difference between Layout and Repaint:

  • Layout, also known as Reflow, means back flow. This typically means that the content, structure, position, or size of an element has changed, requiring recalculation of styles and rendering trees
  • Repaint. Meaning that the changes to the element only affect the appearance of the element (for example, the background color, border color, text color, etc.), then simply apply the new style to the element

The cost of backflow is higher than redrawing, and backflow of a node often leads to backflow of child nodes and nodes at the same level, so the optimization plan generally includes to avoid backflow as far as possible.

What causes reflux?

2.DOM structure changes, such as removing a node. 3. Render tree changes, such as reducing the padding 4. Window resize 5. The most complex type: Many browsers will optimize for backflow by waiting until there is enough of it to do a batch backflow. However, in addition to direct changes to the render tree, when fetching some properties, the browser will also trigger backflow in order to get the correct value, rendering the browser optimization ineffective. Offset (Top/Left/Width/Height) (2) Scroll (Top/Left/Width/Height) (3) cilent(Top/Left/Width/Height) (4) Width, Height (5) Call getComputedStyle() or IE currentStyleCopy the code

Reflow must accompany repainting, but repainting can occur alone

Therefore, there are generally some optimization schemes, such as:

  • Instead of changing styles item by item, it’s better to change the style once, or define the style as class and update it once
  • Instead of looping around the DOM, create a documentFragment or div, apply all DOM operations to it, and finally add it to window.document
  • Avoid multiple reads of attributes such as offset. If you can’t avoid it, cache them in variables
  • Locate complex elements absolutely or fixedly out of the document flow, otherwise backflow would be costly

Note: Changing the font size causes backflow

Here’s another example:

var s = document.body.style; s.padding = "2px"; // backflow + redraw s.order = "1px solid red"; // Redraw s.color = "blue"; // Redraw s.buckgroundcolor again = "# CCC "; // Redraw s.ontSize = "14px" again; / / return again + redrawing / / add a node, reflux + redraw the document again. The body. The appendChild (document. The createTextNode (' ABC! '));Copy the code

Simple layer and composite layer

The above rendering stops at drawing, but actually drawing is not so simple, it can be combined with the concept of composite layer and simple layer.

Here is not to expand, into a brief introduction:

  • You can assume that there is only one compound layer by default, and that all DOM nodes are under this compound layer
  • If hardware acceleration is enabled, you can turn a node into a composite layer
  • The drawing between composite layers does not interfere with each other, and is directly controlled by the GPU
  • On a simple layer, even with absolute layout, the change does not affect the overall backflow, but the drawing will still be affected in the same layer, so the performance of animation is still very low. Composite layers are independent, so hardware acceleration is generally recommended for animation

More references:

Normal and composite layers

Debugging in Chrome

In Chrome’s developer tools, you can see the detailed rendering process in Performance:



The download of resources outside the chain

Above introduced HTML parsing, rendering process. In reality, however, when parsing THE HTML, you encounter some resource connections that require separate processing

For simplicity, the static resources encountered are grouped into the following categories (not all listed) :

  • CSS style resources
  • JS Script Resources
  • Img Image resources

Processing when encountering external chain

When an external link is encountered, a separate download thread is opened to download the resource.

CSS style resources are encountered

The handling of CSS resources has several characteristics:

  • CSS downloads asynchronously and does not block the browser from building the DOM tree
  • (this is related to browser optimization to prevent CSS rules from constantly changing and avoid repeated builds)
  • There are exceptions,media queryDeclared CSS does not block rendering

JS script resources are encountered

The processing of JS script resources has several characteristics:

  • Block browser parsing, which means that if an external script is found, parsing HTML will continue until the script has been downloaded and executed
  • The optimization of the general modern browsers have optimization, browser in a script block, will also continue to download other resources (of course with a concurrent limit), but even though the script can be downloaded in parallel, the parsing process is still blocked, which means to be after the script execution is the next parsing, parallel downloads are just a kind of optimization
  • Defer and Async. Normal scripts block browser parsing, but you can add defer or async properties so that the script becomes asynchronous and can wait until the parsing is complete

Note that defer and async are different: defer executes, while async executes asynchronously.

To put it simply (without expanding) :

  • asyncThe asynchronous execution is performed after the asynchronous download is complete. The execution sequence is not guaranteed, but must be inonloadBefore, but not sure inDOMContentLoadedBefore or after the event
  • deferIt is delayed execution, which in the browser looks as if the script has been placedbodySame behind (although the specification should be inDOMContentLoadedBefore the event, but actually different browser optimization effect is different, may also be behind it)

An IMG image class resource is encountered

When you encounter images and other resources, it is directly asynchronous download, will not block parsing, directly replace the original SRC place with pictures after downloading

The loaded and domcontentloaded

A simple comparison:

  • The DOMContentLoaded event is triggered only when the DOM is loaded, not including stylesheets, images (e.g. not if there are async loaded scripts)
  • When the load event is triggered, all the DOM, stylesheets, scripts, and images on the page have been loaded

Visual formatting model of CSS

Many of the references for this section are CSS Mastery – Advanced Web Standards Solutions and reference sources

The overall rendering concept was mentioned earlier, but the actual rendering rules for the elements in the document tree can be further expanded. This part of the content is: visual format model of CSS

To understand:

  • CSS dictates that each element has its own box model.
  • And then the visual format model is to put these boxes on the page according to the rules, how do you lay them out
  • In other words, the box model dictates how the boxes are placed on the page, how the boxes interact, and so on. Right

Bottom line: The visual formatting model of CSS dictates how the browser handles the document tree on the page

Key words:

Containing Block Controlling Box Block Formatting Context (BFC) Inline Formatting Context (IFC) Positioning system floating...Copy the code

In addition, the CSS has three positioning mechanisms: normal flow, floating, and absolute positioning. Unless specifically mentioned, the following are for normal flow

Containing blocks

The position and size of an element’s box is associated with a rectangular box called a containment block.

An element creates a containment block for its descendants. However, the containment block of an element is not its parent element. The containment block of an element is related to the style of its ancestor element, etc

Such as:

  • The root element is the topmost element, it has no parent node, and its contain block is the initial contain block
  • Static and relative contain blocks are created by the content box of their nearest block level, cell, or inline block ancestor element
  • Fixed’s contain block is the current visible window
  • Absolute contains a block made up of its nearest position propertyabsolute,relativeorfixedThe ancestor element is created
    • If its ancestor element is an inline element, the containing block depends on its ancestor elementdirectionfeatures
    • If the ancestor element is not inline, the region containing the block should be the inner margin boundary of the ancestor element

Controller Enclosure

Concepts related to block-level elements and block boxes and inline elements and row boxes

Block box:

  • Block-level elements generate a block box (Block Box), the block box takes up an entire line and is used to contain the child box and the generated content
  • A block box is also a block containing box (Containing Box), which contains either block boxes or inline boxes (not intermixed). If a block box contains both block-level elements and inline elements, the inline elements are surrounded by anonymous block boxes

Examples of anonymous block box generation:

<DIV>
Some text
<P>More text
</DIV>
Copy the code

Div generates a block box containing another block box P and Some text. Some text is forced to be added to an anonymous block box, which is contained in the block box generated by div. Line boxes and inline boxes are different.)

In other words:

If a block box contains another block box, we force it to contain only block boxes, so the rest of the text is generated as anonymous block boxes (not anonymous inline boxes).

Inline box:

  • An inline element generates an inline box
  • Inline elements can be placed in a row, allowing other elements to be left or right

An example of the generation of anonymous inline boxes:

<P>Some <EM>emphasized</EM> text</P>
Copy the code

The P element generates a block box with several inline boxes (such as EM) and the text Some, text, for which anonymous inline boxes are generated

The effect of the display attribute

Several properties of display can also affect the generation of different boxes:

  • blockThe element generates a block box
  • inlineThe element produces one or more inline boxes
  • inline-block, the element produces an inline block box, the inside of which is formatted as a block, and the element itself is formatted as an inline boxBFC)
  • noneDon’t generate boxes, don’t format structures, of course, another onevisibility: hiddenAn invisible box is generated

Conclusion:

  • If a box contains a block-level element, the contents of the box will be formatted as a block box, because whenever a block-level element appears, the contents of the box will be divided into several blocks, each of which has an exclusive line (the occurrence of a row can be solved by using anonymous block boxes).
  • If there are no block-level elements in a box, the contents of the box will be formatted as inline boxes, because the contents are arranged in rows in order

Block Formatting Context (BFC)

FC?

FC is the format context, which defines the rules for rendering elements inside the box

FC is like a big box with a lot of elements in it. The box separates the inside elements from the outside elements (so the outside doesn't affect the rendering inside the FC). The internal rules can be: how to position, width and height calculation, margin folding, etc.Copy the code

Different types of enclosures participate in different FC types. For example, block-level enclosures correspond to BFC and inline enclosures correspond to IFC

Note that not all boxes will generate FC, but only if certain conditions are met. Only after the corresponding FC is generated will the corresponding rendering rule be applied

Landing the rules:

Each element in a block formatting context outside left in contact with the left side of the containing block (for formatting from right to left, right outside the contact on the right) even there is floating (so the floating element will directly close to its normal to the left of the containing block, and common elements overlapping) unless this element also created a new landingCopy the code

To summarize the characteristics of BFC:

  1. internalboxIn the vertical direction, one after the other
  2. The vertical direction of the box is defined bymarginIt is decided that the margin between two boxes belonging to the same BFC will overlap
  3. The BFC area is not associated withfloat boxOverlap (can be used for typesetting)
  4. A BFC is a separate container on a page, and the child elements inside the container do not affect the outside elements. And vice versa
  5. When calculating the height of the BFC, floating elements are also involved (no floating collapse)

How do I trigger the BFC?

  1. The root element
  2. floatProperties fornone
  3. positionforabsoluteorfixed
  4. displayforinline-block.flex.inline-flex.table.table-cell.table-caption
  5. overflowDon’t forvisible

Display: table, by itself, does not produce BFC, but it does produce an anonymous box (the box containing display: table-cell), and that anonymous box produces BFC

For more, please search online

IFC Inline Formatting Context

IFC is the format context generated by the inline box

IFC rules

The inline formatting context boxes are arranged horizontally one after the other, starting at the top of the containing block. The horizontal margin, border, and padding are retained between the boxes. The boxes can be aligned vertically in different ways: they are aligned at the top or bottom, or aligned according to the baseline of the text within themCopy the code

Line box

The rectangular area that contains those boxes will form a row, called a row box

The width of a row box is determined by its containing block and floating elements, and the height is determined by the row height calculation rules

Rules for line boxes:

If several row boxes cannot fit horizontally into a row box, they can be divided among two or more vertically stacked row boxes (i.e. the split of row boxes). The row boxes are stacked without vertical splits and never overlap row boxes at a height that is always large enough to hold all the boxes contained. However, it may be higher than the highest box it contains (for example, box alignment causes baseline alignment). The left side of the row box touches the left side of its containing block, and the right side touches the right side of its containing block.Copy the code

In combination with the supplementary IFC rules:

Floating elements may be between edges and line box containing block Although the line boxes in the same inline formatting context usually have the same width (the width of the containing block), they may be shortened by floating elements available width, and the change in the width The same inline formatting in the context of a line box usually is not the same as the height (e.g., One line contains a tall figure, while the other lines contain only text.) When the sum of the width of the inline lines in a line is less than the width of the line that contains them, their horizontal alignment depends on the 'text-align' feature. Empty inline lines should be ignored i.e. contain no text, leave whitespace, Margin /padding/border inline elements that are not 0, as well as other normal stream content (for example, images, inline blocks and inline tables), and line boxes that do not end with a newline, must be treated as zero height line boxesCopy the code

Conclusion:

  • Inline elements always apply IFC rendering rules
  • Inline elements are rendered using IFC rules, for exampletext-alignCan be used to center
  • Inside the block box, for anonymous elements such as text, anonymous line boxes are generated, and inside the line box, IFC rendering rules are applied
  • Inside the inline box, IFC rendering rules apply to those inline elements as well
  • In addition,inline-block, will generate IFC in the outer layer of the element (so the element is allowed to passtext-alignHorizontal center), of course, its interior is rendered according to BFC rules

IFC can be more abstract than BFC rules (because there are less coherent rules and trigger conditions)

But in general, it’s a rendering rule for how the elements in the row themselves are displayed and how they are placed inside the box, so it should be easier to understand, right

other

Of course, there are a few other things:

  • Such as conventional flow, floating, absolute positioning and so on
  • Floating elements, for example, are not included in the regular flow
  • Such as relative positioning, absolute positioning,FixedPositioning and other differences
  • Such asz-indexHierarchical display mechanism, etc

Please refer to:

Bbs.csdn.net/topics/3402…

JS engine parsing process

As mentioned earlier, when encountering a JS script, it will wait until it is executed. In fact, it needs the engine to parse it.

JS interpretation stage

First things first: JS is interpreted speech, so it doesn’t need to be compiled ahead of time, but runs in real time by the interpreter

The engine processing of JS can be summarized as follows:

Once the code is read, Lexical analysis is performed and the code is broken down into tokens. 2. Parsing the primitives, and then arranging the code into a syntax tree. 3. Translate code into bytecode using a translator. The bytecode is converted into machine code using the Bytecode interpreterCopy the code

Ultimately, the computer executes machine code.

Modern browsers generally use JIT-Just In Time compiler to improve performance.

That is, bytecode is compiled only at runtime, which line is used, and the compiled results are cached inline cache.

So the speed of the whole program can be significantly improved.

Also, different browsers may have different policies. Some browsers skip the bytecode translation step and convert directly to machine code (e.g. Chrome’s V8)

To summarize, the core JIT compiler compiles the source code into machine code to run it

JS preprocessing stage

This is the overall process of the interpreter, but there is also a pre-processing phase (e.g. variable promotion, semicolon completion, etc.) before JS is executed.

The preprocessing phase does a few things to ensure that JS executes correctly, just to name a few:

The semicolon completion

JS execution requires semicolons, but why does the following statement work?

console.log('a')
console.log('b')
Copy the code

The JS interpreter has a Semicolon Insertion rule that adds semicolons at appropriate positions according to certain rules

Here are a few rules that automatically add semicolons:

  • When there is a newline character (including a multi-line comment containing a newline character), and the nexttokenA semicolon is automatically added if the preceding syntax does not match.
  • When you have}If the semicolon is missing, the semicolon is added.
  • At the end of the program’s source code, a semicolon is added if it is missing.

So, the code above becomes

console.log('a');
console.log('b');
Copy the code

So it works

Of course, here’s a classic example:

function b() {
    return
    {
        a: 'a'
    };
}
Copy the code

Because of the semicolon completion mechanism, it becomes:

function b() {
    return;
    {
        a: 'a'
    };
}
Copy the code

So it runs undefined

Variable ascension

Generally including function promotion and variable promotion

Such as:

a = 1;
b();
function b() {
    console.log('b');
}
var a;
Copy the code

After variable enhancement, it becomes:

function b() {
    console.log('b');
}
var a;
a = 1;
b();
Copy the code

There’s no expansion here, but expansion can involve a lot of things

Examples include variable declarations, function declarations, parameters, priority order of arguments, and temporary dead zones related to lets in ES6

JS execution phase

Understanding JavaScript series 10: the Core of JavaScript

After the interpreter interprets the grammar rules, it begins execution, and the following concepts are generally included in the execution process:

  • Execute context, execute stack concepts (e.g., global context, current active context)
  • VO (variable object) and AO (active object)
  • The scope chain
  • This mechanism etc.

These concepts are too much to explore in depth, so only a few features are mentioned here

The execution context is explained briefly

  • JS haveExecution context)
  • The browser first loads the script it will createGlobal execution contextAnd push to the top of the execution stack (cannot be ejected)
  • Each time it enters another scope, it creates the corresponding execution context and pushes it to the top of the execution stack
  • Once the corresponding context is executed, it pops off the top of the stack and gives context control to the current stack.
  • Execute in sequence (eventually returning to the global execution context)

For example, if the program completes execution, is thrown off the stack, and then is not referenced (no closure is formed), the memory used in this function is automatically reclaimed by the garbage processor


The relationship between the execution context and VO, scope chain, this is:

Each execution context has three important properties:

  • Variable object (The Variable object, VO)
  • Scope chain (Scope chain)
  • this

VO with AO

VO is an attribute of the execution context (abstract concept), but only the variable objects of the global context are allowed to be accessed indirectly through the VO attribute name (because in the global context, the global object is itself a variable object).

The AO (ACTIVATION object) is created when the function is activated by the caller

It can be understood as:

  • In the context of functions:VO === AO
  • In the global context:VO === this === global

In general, VO stores variable information (declared variables, functions, arguments, etc.)

The scope chain

It is an attribute in the execution context, similar in principle to a prototype chain, and is very important.

For example, process brief:

In the function context, look for a variable foo. If it is found in the VO of the function, use it directly. Otherwise, look in its parent scope chain (__parent__)Copy the code

This pointer

This is also one of the core knowledge of JS, because the content is too much, here will not expand, only mention part

Note: This is a property of the execution context, not of a variable object

Therefore:

  • There is no such thing as a search for variables
  • When this is used in code, the value of this is taken directly from the execution context, rather than being searched through the scope chain
  • The value of this depends only on the context in which the

So the classic example:

var baz = 200; var bar = { baz: 100, foo: function() { console.log(this.baz); }}; var foo = bar.foo; // Enter the environment: global foo(); // 200, Cannot read property 'baz' of undefined // global bar bar.foo(); / / 100Copy the code

The above example is easy to understand

More references:

Deeper understanding of JavaScript Series (13) : This? Yes,this!

Recycling mechanism

JS has a garbage handler, so there is no need to reclaim memory manually, but it is handled automatically by the garbage handler.

Generally speaking, garbage handlers have their own collection policies.

For example, functions that have completed execution will be reclaimed if there are no external references (which would form closures). (Of course, the recovery action is generally cut to different time periods to avoid affecting performance)

Two common garbage collection rules are:

  • Mark clear
  • Reference counting

The basic GC scheme for the Javascript engine is simple GC: Mark and sweep.

  1. Iterate over all accessible objects.
  2. Reclaim objects that are no longer accessible.

For example :(from javascript elevation)

When a variable enters the environment, for example, declaring a variable in a function, mark the variable as “entering the environment.” Logically, you can never free up memory occupied by variables that enter the environment, because they may be used whenever the execution stream enters the corresponding environment.


When a variable leaves the environment, it is marked as “out of the environment.”


At run time, the garbage collector marks all variables stored in memory (of course, it can be marked in any way).


It then unflags variables in the environment and variables referenced by variables in the environment (closures, that is, variables referenced in and around the environment are unmarked).


Variables tagged after this point are considered to be ready for deletion because they are no longer accessible to variables in the environment.


Finally, the garbage collector completes the memory cleanup, destroying the tagged values and reclaiming the memory space they occupy.

About reference counting, a simple understanding:

Track how many times each value is referenced and, when a value is referenced, how many times+ 1, underweight- 1, the next garbage collector will collect times is0(of course, easy to loop reference bug)

The defect of the GC

As with other languages, javascript’s GC strategy is not immune to the problem of stopping to respond to other operations while GC is in progress

This is for safety reasons.

Javascript GC is 100ms or more

For the general application is good, but for JS games, animation on the coherence requirements of the application is high, it is troublesome.

This is where the engine needs to be optimized: to avoid long pauses in response caused by GC.

GC optimization strategy

Generation GC (Generation GC)

The aim is to distinguish between “temporary” and “permanent” objects:

  • Multiple reclaim temporary Objects area (young generation)
  • Recycle less persistent Objects section (tenured generation)
  • Reduce the number of objects to traverse each time, thereby reducing the time of each GC.

The Node V8 engine uses generational recycling (like Java, the author is the Java virtual machine author).

For more information:

V8 Memory Analysis

other

Cross domains can be mentioned

For example, when making network requests, AJAX is used, and cross-domain problems can occur if the interface is cross-domain

For reference:

Ajax is cross-domain, and this should be the most complete solution

Web security can be mentioned

For example, browsers have XSSAuditor when parsing HTML, which extends to web security-related areas

For reference:

Are AJAX requests really insecure? Talk about Web security and AJAX.

More and more

You can mention viewport, physical pixels, logical pixels, CSS pixels, etc

If you are familiar with Hybrid development, you can mention Hybrid and optimization

.

conclusion

So much content above, the purpose is: comb out their knowledge system

Due to the front-end, this paper focuses on the knowledge combing, and many other knowledge points are briefly described or omitted. The key modules are summarized as follows:

  • The process/thread model of the browser, the JS runtime mechanism (this section is linked to another article)
  • HTTP specification (including packet structure, headers, optimizations, HTTP2.0, HTTPS, etc.)
  • HTTP caching (listed separately because it’s important)
  • Page parsing process (HTML parsing, DOM building, CSS rule generation, rendering tree building, rendering process, composite layer synthesis, outer chain processing, etc.)
  • JS engine parsing process (including interpretation stage, preprocessing stage, execution stage, including execution context, VO, scope chain, this, recycle mechanism, etc.)
  • With cross-domain relevance, Web security links to specific articles alone, while others such as CSS box models, viewports, and so on are merely concepts

What is the value of this article?

This article is the result of an individual’s periodic review of the body of knowledge, then modified and published as an article, so it is not guaranteed to be applicable to all personnel

However, I think this article has some reference value

Write the last words

Or the same sentence: knowledge to form a system

After sorting out the knowledge system, there is a skeleton, the knowledge point is not easy to forget, and the learning of new knowledge will be more quickly, more importantly, it is easy to draw inferring, can be from a common problem, deep digging to expand to the underlying principle

Front-end knowledge is endless, this paper is just a simple comb out the skeleton of a knowledge system, more content still need to learn and accumulate

In addition, this article combines from browser multi process to JS single thread, JS operation mechanism of the most comprehensive combing this article, better oh!

The appendix

blog

First published 2018.03.12 on my personal blog

www.dailichun.com/2018/03/12/…

The resources

  • Segmentfault.com/a/119000001…
  • www.html5rocks.com/zh/tutorial…
  • Coolshell. Cn/articles / 96…
  • Igoro.com/archive/wha…
  • Blog.csdn.net/dojiangv/ar…
  • Bbs.csdn.net/topics/3402…
  • Segmentfault.com/a/119000000…
  • www.bubuko.com/infodetail-…
  • Fex.baidu.com/blog/2014/0…
  • www.cnblogs.com/winter-cn/a…
  • Fanerge. Making. IO/B5 8 f % % % E6% E…
  • www.cnblogs.com/TomXu/archi…
  • Segmentfault.com/q/101000000…