preface

To do a good job, he must sharpen his tools. Once the performance metrics are understood, the goals for performance optimization are clear. Next, we use some performance measurement tools to determine how far the page is from the optimization goal. A good tool can do more with less effort. In the following three articles, I will introduce three main measurement tools respectively:

  1. Chrome DevTools is used for debugging and performance measurement during daily development.
  2. Lighthouse is used to generate performance measurement reports for web pages.
  3. WebPageTest for the overall site quality assessment, one-stop performance assessment.

With these three tools, we can evaluate website performance from multiple dimensions.

Performance measurement tool -WebPageTest

At its core, WebPagetest is used to measure and analyze the performance of web pages. It is a subproject of Google’s open source project Make the Web Faster, which was originally used internally by AOL and later opened based on BSD in 2008. Its official website is www.webpagetest.org/

Principle: WebPageTest is a PHP website, the user input url, location, custom script and other information, parameters sent to the background. Do some logic in the background, and then launch Chrome, Firefox, or Internet Explorer through a browser agent. After the execution, the browser sends the data back to the background, and the background saves the data. Finally, through various forms (such as graphs, tables, columns, etc.), the analyzed data is presented to the user.

1. The navigation bar

First open WebPageTest official website, you can see the following interface:

  1. Test History: You can view Test History records.
  2. API: The WebGeTest API Key allows developers to automate performance tests in their workflows to continuously deliver faster web pages. WebPageTest support extended development, as long as the application to a key, you can do development according to the API provided. However, the number of calls is limited, so if you want to do your own local or Intranet layout of a WebPageTest environment.
  3. Forums information, with lots of questions and answers and a very wide range of topics.
  4. Docs: English tool documentation, Chinese document can refer to this website github.com/pwstrick/We…
  5. Blog: Blog, which contains some best practices of WebpageTest, etc
  6. About: The Github address of WebPageTest and the download address of the release are given.

2. Basic usage

Basic configuration

  1. Enter the web address: After determining the page you want to test, go to WebPagetest and assign it the URL of the page you want to test, which can be the home page or the details page.
  2. Select geographic location: WebPagetest has test machines located around the world, you should test from a location close to the user’s access, select a location from the list, or clickSelect from MapButton to select a location from the map view (just click on the balloon 🎈 and then OK)
  3. Select a browser: Different locations support different browsers, and if a given location does not have the browser you are looking for, you can try different locations. Chrome is usually recommended.

Advanced configuration

  1. Times of running tests: In order to ensure the accuracy of test results, each run will be tested several times
  2. Duplicate access or not: Because duplicate access takes precedence over cache, the results may differ
  3. Submit tests: When everything is configured, clickStart TestButton that sends the request to the test location for testing. Tests can take a while to run, depending on how many tests there are (there’s at least a minute of testing before the test, but it’s even longer). Once the test is complete, you will get the results.

3. Local deployment

The official website can only test some websites that the external network can access, but often in the development process some projects we are published in the company’s internal LAN, so it is necessary to deploy WebPagetest to the local, using the local network environment to test performance.

Note: Locallhost is not the locallhost on the local PC, because testing locallHost on the local PC is often inaccurate. In most cases, the webpack Dev Sever server is used for local development and debugging. Resources are not compressed, so loading is slow, and the results are often very different from those in an online environment.

The specific steps are as follows:

  1. Download and install the Docker image at docs.docker.com/get-docker/

    Download and install according to the operation step by step to do, here will not be introduced in detail. Need to explain why the installation of docker image, Docker is similar to a virtual machine, on the virtual machine to download the image of WebPageTest, we just do not need to independently install the software WebPageTest, so that can not be limited by the system, completely independent of a set of virtual environment, Port mapping to local services.

  2. Pull the image and run the server instance and agent instance as follows

    #Pull the mirror
docker pull webpagetest
docker pull webpagetest/agent

#Running the Server instance
docker run -d -p 4000:80 webpagetest/server

#Running the Agent instance
docker run -d -p 4000:80 --network="host" -e "SERVER_URL=http://localhost:4000/work/" -e "LOCATION=Test" webpagetest/agent
Copy the code

  3. Visit http://localhost:4000 and you’ll see the same page as WebPagetest’s official website, where you can test the performance of your local service by typing in the addresses of other local ports.

4. Result analysis

4.1 Optimization Level

At the top of the results page is a set of the most critical performance tuning levels. Covers basic optimizations that apply to all sites, anything that is not A or B needs further optimizations.

! [image-20210504164729533](/Users/liyang/Library/Application Support/typora-user-images/image-20210504164729533.png)

Letter grade Accounted for
A 90% +
B 80% ~ 89%
C 70% ~ 79%
D 60% ~ 69%
F 0% ~ 59%

4.2 Summary of Performance Indicators

The data table at the top of the results page provides some high-level information about the loaded pages, where metrics for first and repeat views clearly see the results of first and repeat view visits.

First View: The test of the First View, which clears the browser’s cache and cookies, represents what visitors will experience when they First visit the page.

Repeat View: A Repeat View is executed immediately after the first View test and does not clear anything. The browser window closes after the First View test, and a new browser is launched to perform the Repeat View test. The repeated view test simulates a scenario where the user leaves the page and immediately re-enters the page.

In addition, here are a few key indicators:

  1. Time To First Byte: The First Byte Time (often abbreviated TTFB) is the Time measured from the initial request To the First Byte of the server’s response, which is received by the browser (excluding DNS queries, TCP connections).
  2. Start Render: Measures the time from the initial request to the time when the first content is drawn to the browser display.Start RenderThis is measured by capturing the video of the page loading and looking at each frame when the browser first displays something other than a blank page. It can only be measured in a laboratory and is usually the most accurate measurement.
  3. Speed Index: The Speed Index is a calculated measure of how quickly a page renders content visible to the user (the lower the better). For more information about the calculation method, click here.
  4. Total Blocking Time: refers to the Total Time that a page is blocked and a user cannot interact with it. As you can see, the resource cache reduces the Blocking Time on secondary access.
  5. Document Complete: From initializing the request to loading all static content (images, CSS, JavaScript, etc.), but may not include content triggered by JavaScript execution, which can be understood as the start of executionwindow.onload.
  6. Fully Loaded time of all elements of the page: refers to the time when there is no network activity within 2 seconds (hundreds of milliseconds in the middle) after the initial request to Document Complete, but these 2 seconds are not included in the measurement, so there will be two differences greater or less than 2 seconds.

The difference between the first byte load time and the first byte time

First Byte Time: the Time when the browser receives the First Byte of HTML content, including DNS lookup, TCP connection, SSL negotiation (if HTTPS request), and TTFB.

Time To First Byte (TTFB) : The First Byte is the Time measured from the initial request To the First Byte of the server response, which is received by the browser (excluding the Time of DNS query and TCP connection). TTFB is calculated from requestStart to responseStart in the figure below, which is the time when the request is sent out.

So, first byte load time = DNS search time +TCP connection time +SSL negotiation time +TTFB request sent time

4.3 Waterfall chart requests waterfall chart

At the bottom of the result page, we can see the waterfall diagram displayed during each run. Click it to see the details of specific parameters, as shown below

In this chart we can see that all the requested resources are listed, which is more detailed than the information provided by Chrome DevTools, such as the following indicators:

  1. When is the Browser Main Thread occupied
  2. Long Tasks: The Long task duration, which is the technology interaction time of the page. The red area represents the blocking time
  3. Bandwidth In: indicates the Bandwidth
  4. CPU Utization: CPU usage

In addition, in the figure below, we can also see some optimization points, such as 42-50 parallel requests for image resources to reduce the load time of resources, and 57-58 highlighted yellow resources have been redirected, WebpageTest prompts us that the resource has changed, can be optimized to not redirection resources.

conclusion

  1. How to use WebpageTest: Visit the official website test, install the local image test
  2. Key metrics for WebpageTest: First Byte Time, Start Render Time, Speed Index, Total Blocking Time, Document completion Fully Loaded
  3. First byte load time = DNS search time + TCP connection time + SSL negotiation time + TTFB request sending time

The resources

  1. Web Performance optimization Tool WebPageTest – Overview and configuration
  2. Web Performance optimization tool WebPageTest (2) – Performance data
  3. Web Performance Optimization Tool WebPageTest (3) — Local Deployment (Windows 7)

The last

If there are any mistakes in this article, please correct them in the comments section. If this article has helped you, please like it and follow it.

Read more high-quality articles, you can follow my wechat public number [Sister Yang talks about the front end], push high-quality articles every day, we communicate and grow together.