What happens after the user enters the URL, and the optimization problem

User angle:
1. Open the browser
2. Enter the URL
3. Press ENTER
4. Browser Rendering Screen

When the user enters the page address, the browser obtains the address that the user wants to access, and initiates a series of requests to the site server that include not only requests for the page, but also requests for many components in the page, Slices (img), Overlay style sheets (CSS), scripts (JavaScript), Embedded pages (IFRAME), audio media files, and so on. Over time, the browser waits for the server's response and the returned data. After the browser obtains all the returned data, after the browser local computation and renders, finally renders a complete page in front of the user.

In this process, the main experience is the following three parts of time:
1. The time of data transmission on the network;
2. The site server accepts processing requests and generates time for response data
3, the browser local calculation and rendering time;

The time that data travels over the network consists of two parts:
1, the browser sends the request data to the server, passes through the network to consume the time;
2, the server response data to the browser, through the network time required to consume;
The total time that these two parts consume is what we call response time. Its determinants include the amount of data sent and the network bandwidth;

The site server accepts processing requests, and the time to generate the response data is primarily consumed on the server side, which includes a very significant number of links.
For example, the concurrency policy of the server, I/O model, I/O performance, CPU cores, etc., including the logic complexity of the application itself and database operations.

Browser-local computing and rendering time is naturally consumed on the browser side, and it relies on factors such as the concurrency policy adopted by the browser itself, CSS style rendering, the performance of the JavaScript script interpreter, the size of the page, the number of page components, the cache state of the page component, The domain name distribution of the page component and DNS resolution of the domain name. And the factors will vary depending on the type and version of each vendor's browser. For example, an IE, it can only support concurrent 4 downloads. And some Firefox can be 8 or more.

Scenario One: Reduce the HTTP requests in the page
Any one page contains multiple components (img/css/js/iframe, etc.), each of which needs to be downloaded, calculated, or rendered, without a doubt that these actions consume time. So if we can let the page reduce these behaviors, we should be able to speed up the page display speed. There is no doubt about it.
1, design a more concise page, so that it contains fewer pictures and scripts, and even CSS. But that would sacrifice aesthetics and user interaction.
2. Merging multiple images into one file, using CSS background image offset technology to render it in the Web page, avoid multiple images to download. (Sprite Chart)
3. Combine and compress JavaScript scripts and CSS style sheets.
4. Make full use of the browser-side cache policy in HTTP to reduce duplicate downloads.

Scenario Two: Speed up the computation of server-side scripts
For example, to upgrade PHP version, it is reported that the 7.x version than 5.x version performance optimization nearly 20 times times faster. For some of the more commercially supportive scripting languages such as. NET and JSP, there are built-in optimization scenarios. For example, the interpreter caches the first time a script is interpreted for the next use

Scenario three: Using dynamic cache technology
Caches the HTML output of dynamic content and outputs it directly after a period of time when there is user access and skips repeated dynamic content calculations.
But not all dynamic content is good for page caching. Actual situation analysis. The difficulty with caching is a series of very realistic questions, such as how thousands of cache files are stored, and how much cache hits? How is the expiration policy of the cache designed?

Scenario Four: Data caching
Some of the dynamic content of the calculation time, in fact, mainly consumed in some annoying special data, these data or updates are too frequent, or consume a lot of I/O waiting time, such as database a field frequently updated and read, we can consider to cache the data.

Scenario Five: Load Balancing

When we maximize the processing power of a single Web server, but still exceed the limit of its pressure, we need more servers to share the work. We need to find a way to transfer traffic to other servers reasonably. We can implement web load balancing in different ways, such as simple HTTP redirection, DNS polling resolution, and reverse proxy. LVS component server cluster.

Scenario Six: Optimizing the Database
Often, some performance problems occur in poorly performing data access levels. For example, unreasonable SQL statements, unreasonable application access design, unreasonable database table structure design. Lack of understanding of the internal structure of the database, it is no exaggeration to say that the above optimization all for nothing!

What happens after the user enters the URL, and the optimization problem