Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”.

This article has participated in the “Digitalstar Project” and won a creative gift package to challenge the creative incentive money.

One, foreword

A few days ago when I was sorting out the front-end performance analysis, I felt that there was a problem that no one seemed to have mentioned before.

Is the pressure test tool, can simulate the front end of the complete request chain? For example, stress tools such as LoadRunner /Jmeter.

As we all know, a lot of performance testing these days starts with interfaces, and front-end performance becomes a separate part.

In the early days of performance testing tools, the philosophy was to “simulate the behavior of real users.”

Looking at current performance testing strategies and methods, it feels more and more remote from the real user.

Therefore, another idea is proposed: full link performance test. And this idea of change is based on the transformation of architecture. But in practice, some essential things, such as performance testing strategies and scenarios, have not changed.

In view of the experience of some projects, I will do more sorting and analysis from the idea of full link in the future.

I just want to say one thing today is what front end actions of the pressure tool are not being simulated?

Second, the browser rendering principle

Let’s take a look at the browser rendering process:

Is the working process of the WebKit kernel. From HTML parsing to Display, you can clearly see what the front end is doing. Obviously, these are things that stress tools can’t do on the browser side. For example: HTML parsing, DOMtree creation, CSS parsing, rendering trees, drawing, etc., these stress tools are not dry.

So what does a pressure tool do?

Let’s look at it in a different position.

From the moment you enter a URL in the browser to the moment you start loading, the browser does something that the stress tool doesn’t simulate. But starting with the Redirect, AppCache, DNS resolution, TCP creation, request sending, and response receiving, pressure tools inevitably have to do that. The next local action of these processes is one that pressure tools do not do. That seems to make sense.

Let’s look at it again in a different position: After a URL request is sent, there are more subdivided resources to be processed individually. These resources are processed over and over again in a cycle of request sending and response receiving. AppCache, DNS resolution, TCP creation, etc., are reusable.

Additionally, section 8.1.1 of RFC2616 explicitly states limiting browser concurrency. If you are interested, read the original:

  1. Fewer TCP connections can save CPU and memory resources of routes and hosts (clients, servers, proxies, gateways, channels, and caches).
  2. HTTP requests and responses can be sent over a connection using Pipelining. Pipelining allows clients to make multiple requests without waiting for each to return, making a TCP connection more efficient.
  3. Reducing network congestion by reducing the number of TCP open also gives TCP enough time to resolve congestion.
  4. Subsequent requests spend no more time on the TCP three-way handshake, reducing latency.
  5. Because there is no penalty for closing a TCP connection when reporting an error, HTTP can be upgraded more gracefully.
  6. Without limitation, a client sends many links to the server, reducing the number of clients that the server’s resources can serve at the same time.

Our common browsers have the following concurrency limits.In the stress tool, there are no parameters to control the concurrency value, if it is in the same thread, it is executed in parallel.

Let’s break down the specific action of a request.

Each request consumes time in this cycle. Queue – wait – block – send request – wait TTFB- download. And this process can be simulated by the pressure tool. So, if we want to analyze the performance of the front end, it is best to distinguish between time spent on the front end and time spent on the back end. In this way, the performance time can be broken down into more details.

Third, summary

Most of the current stress tools are on the server side, simulating “network API requests,” while the front end is basically driven by a series of “user interaction events,” whose business state is a DOM tree.

Generally speaking, the front-end performance of the browser page rendering time, resource loading order, number of requests, front-end cache resource usage, compression, etc, hoping to find the page load time is in the process of operation and resources, and then targeted optimization, finally to optimize the purpose of the end user experience on the browser end.

At present, the following aspects can be used to obtain and measure the Performance of a page: Performance Timing API, Prpfile tool, page buried point Timing, resource loading sequence diagram analysis;

  • Performance Timing APIIs a support Internet Explorer 9Above version and WebKit;

A mechanism used in the kernel browser to record key points in the page loading and parsing process. It keeps a detailed record of each page resource from the beginning of the loading process to the end of the parsing process, so that the process can be calculated from the start and end of the timestamp;

  • Profile is an API provided by standard browsers such as Chrome and Firefox to test the memory and CPU usage of the system when page scripts are running.
  • Calculate the running time of no part of the code by the way of embedded timing of the script;
  • Use a resource loading sequence diagram from a browser or other tool to help analyze performance issues during page resource loading. This method provides a coarse-grained macro analysis of all browser resource file request times and file load order.