Is your page healthy?

The basic work of the front end is to write pages, so you write so many pages, know their page health, performance is good? If you care about the health of your page as well as fulfilling your business needs, then you are a front-end developer with something to aspire to. This article will tell you how to know if your page is healthy.

indicators

Just because a page is healthy and performing well doesn’t mean it’s performing well just because it opens fast on my own network on my own company computer. Have you paid attention to taobao, Jingdong and other large factory page loading performance, and their comparison? In 2018, I met some leaders in the company who were very concerned about the performance of the page produced by our front-end team. They felt it was very slow, so since the big guys had demands, we would meet them. So what should we do? First, identify problems; Second, solve problems; Third, data speaks for itself. Let’s take a look at how I find out if my page is healthy in an elementary, medium, and advanced way.

Before we start, it’s important to know what the metrics are for how healthy a page is. While we’re at it, let’s summarize what happens when the browser enters the URL and renders the page.

1. Enter the URL (we usually enter the domain name)
2. The DNS resolves the domain name into the actual IP address of the target server
3. TCP/IP three-way handshake
4. The browser establishes the HTTP request
5. The server processes the request
6. The browser receives data from the server (typically HTML)
7. Browser rendering HTML
8. Load CSS, JS, IMAGE and other resources when parsing HTML (synchronous or asynchronous, the latter does not block page loading)
9. HTML parsed
10. All resources on the page are loaded

The process from input URL to page rendering is basically like this, so there are two indicators that are familiar to the front end, domReady and onLoad. When we write JS, a lot of times we need to perform the lookup element after domReady. Or onLoad of some pictures lazy loading or statistics of some data reported. The basics of domReady and onLoad will not be parsed here, so we will use these two basic metrics to determine the health of the page.

Primary page health judgment

As a front-end developer, we have to be grateful for the chorme, it has given us too much, so the primary way to judge the health of a page is to use the Chorme developer tools to look at the entire page load data. So where to look?

We use the home page of rental car to see the loading performance of the whole home page:

The simplest way is to look at the bottom right corner. Chorme already gives the domReady and onLoad times for the entire page.

DomReady in less than 1 second, onload in less than 4 seconds, in fact, it is good, so the most preliminary judgment can see the overall performance from here, so let’s go to the details.

Intermediate Page health judgment

The first part, we see first domReady what happened from start to finish, can see all the HTTP is version 2.0, we use this front end can enjoy cutting code, you can see there are ten files are synchronous download, only two files is the need for a TCP connection, the rest are no TCP connections, If you are not familiar with HTTP2.0 you can Google the relevant information or see my last article exploring HTTP in the small front end. From this data, you can see the order of loading, the size of the loaded file, and other relevant information.

Hover over a piece of data to see more detail

It also shows the time taken for every detail of the entire request, DNS resolution time, link server time, SSL time (since HTTPS), TTFB time (from request to receipt of the first byte), download time, total time, etc. Here we can locate the reason why some files are slow, which link is slow, whether it is too large, DNS resolution time is too long, or TTFB time is too long. Sometimes the page is too slow and many ignorant people are pointing to the front end of the resource problem, this time we can from the loading slow page to analyze the loading information of each file, locate the problem is what. (It’s good to throw the pan out.)

Now all our view is based on wifi, there is no limit to the speed of the network, sometimes the user’s network is not so good, many times the mobile device’s network is not stable, so we can also use the Chorme network Settings to simulate 3G or worse network state, so as to get closer to the user’s network state.

Advanced page health judgment

There’s actually a great website to check for us, WebPagetest.

We can choose from many countries, different devices, different networks, different regions to test your page. Webpagetest will have a very detailed indicator of the different dimensions of each page.

You can also see more detailed information, such as the loading image of the page, the waterfall flow of loading resources, and so on.

There are some other indicators:

Because using this website to help us detect will be more comprehensive, we can see some performance problems in different areas. Of course, if you want a lot of China, unfortunately it doesn’t offer a lot of domestic regions to choose from. But it can be a good reference site. But there is one thing we need to know, is that if we really webPagetest network link ah, the carrier situation, then it may not meet your requirements. But I believe there are already a lot of performance testing requirements.

The other is to use Google’s own Audits to test pages that test on your own network, fail to simulate networks elsewhere, and many of the arguments inside don’t fully account for a page’s health but rather express the specifications of the page. So PERSONALLY, DON’t use Google Audits to test your own pages. In case someone takes his or her own pages and uses Audits to test them and then sees the results crash, attach the purged page tests first.

No disrespect, just as a reference.

conclusion

As a front-end developer, we need to have requirements for our work, and we can’t just finish a page to meet them. The above methods for testing page performance are the way to locate problems accumulated in my slow project optimization in 2018, as well as the way to show your page is fast enough with data. Although divided into three levels of junior high school to say, but in fact, it should be more appropriate to use the first step, the second step and the third step to do. Address the problem from the general to the details. Hope this article can bring you some harvest, welcome to continue to add your methods!

Self zhihu article reprinted: zhuanlan.zhihu.com/p/54481501