[Front-end tutorial] Baidu App personal homepage optimization of front-end performance optimization practice

Author: front-end engineer panming

Foreword

Performance is a topic that every front-end engineer should pay attention to. There are many articles and practices on general optimization methods, so I wo n’t go into details. This article uses the Baidu App personal homepage as an example to talk about some performance optimization practices for business characteristics.

Applicable to : All the traditional optimization methods can be used: packaging and unpacking, reducing the volume and number of HTTP requests, CDN and on-demand loading, etc., but the performance is still not ideal.

Define indicators, build reports

The establishment of an excellent plan first needs accurate data to support it.

Generally speaking, the front-end performance indicators include DOM ready , First Contentful Paint , ** white screen, first screen, 用户可操作时间and onload时间等，**. In practice, it needs to be defined in accordance with the characteristics of the business itself. The general definition of indicators does not reflect the user ’s current business. Real experience.

The personal homepage is a web page in the Baidu App client. There are two different ways of opening the hybrid version (using the file protocol to directly load local HTML and JS, CSS) and the web version (opening a web URL).

First, let's understand the structure of the personal homepage page:

The head area shows the personal information of the current author, and the tab area is the content created by the author. All data on the page is obtained asynchronously.

The process of opening a personal homepage can be simplified to the following:

The time consumption can be divided into three parts: end time, network and server time, and front-end rendering time:

According to the above process, we have formulated the principle of defining indicators:

The user data displayed on the home page is the asynchronous rendering after the JS request data in the page. Therefore, the first screen is defined as: the rendering of the first screen data of the head area and the tab list is completed (the user is really visible, that is, the user can operate the time)
Home is sanbuilt SPApage, synchronization of DOM and does not appear on the actual content HTML, before the return to the first screen user data, are displayed as page loading state. Therefore, the definition of the white screen is: the content mounted on the page DOM (the time when the user first sees that the page is no longer blank)
Because in the end, different timing iOS and Android onload event-triggered, iOS resource load can block page rendering, so the home page for iOS has been adjusted using rAFthe iOS is triggered onload at the JS started, and Android in the first screen The required pictures, jsonp and other resources are all triggered after the load is completed, so this indicator is mainly used as an auxiliary function.

In the process of report construction, combining the business form of the homepage (both in the Android and iOS dual-end hybrid version and web version) and the meaning of the indicator definition, the stage of the entire process is as detailed as possible, as follows:

Group the three versions of the homepage: hybrid version, hybrid web version, and web version. You can avoid data interference, and you can compare the experiment by controlling the online time
Add the system, inside and outside of the end, and the starting point as the screening conditions to eliminate the data differences caused by different use conditions, which helps to narrow the scope and locate the analysis
According to the execution process of the home page, the time-consuming process is subdivided to further locate the problem. The whole stage is subdivided into: time-consuming at the end (from clicking to the top of the page header), time-consuming to synchronize the JS reference stages in HTML, and time-consuming to request data , The internal capabilities of the page and the time-consuming time of each component to the first screen (the time-consuming part is gradually refined in the actual optimization analysis)

Finally get a detailed division of each stage:

Additional notes:

End-to-end RBI records data from the moment when the user performs the operation, covering the client time, network time, server time, front-end consumption from the time the user initiates the click operation until the page is fully displayed The complete process of time management.
Among them, the start timestamp is recorded by the previous page when the user operates, and is transparently transmitted to the personal homepage; the
front end records the current time stamp every time a network request is initiated, and the return value of the interface is passed back to the backend processing interface At the time, the difference between the two is the time-consuming HTTP connection.
This time, the front-end computing report and platform display solution are adopted, and the front-end control is flexible and iterative.
The time-consuming part of the end can only calculate the total time from the previous page click to the top of the resolution page.

Data analysis, propose optimization direction

After the first stage, it takes time to get stable data and pages, analyze and propose solutions.

The performance data in the figure shows the main time-consuming stages: time-consuming at the end, time-consuming introduction of the main profile.js into js, time-consuming for the first screen interface, time-consuming for page data processing and rendering . For the following aspects:

For the end of the time-consuming , with the front end look for optimization points
for the first screen interface time-consuming interface optimized front-end joint server
for JS internal time-consuming , their own front-end code optimization

Start to optimize and gradually improve

There are many homepage entrances, which need to be compatible with different entrance conditions and historical legacy. The basic situation of personal homepage business is as follows:

The page is in SPA mode, but the business is complex and the total code size is large
The resources required for the first screen of the hybrid version are returned by the two interfaces, and the two interfaces are dependent and executed serially at the front end
The user data on the top of the web version uses synchronous data, and the tab interface depends on the same as the hybrid
Features of the hybrid version:
The hybrid version and the web version use the same set of code compiled in different ways, but the first interface on the web version is 同步的that the data is returned with the HTML template, and all interfaces in the hybrid are asynchronous
Use more scenes
Use the file protocol to load HTML templates, and use jsonp to request the back-end data interface

According to the four directions of front-end code, engineering, server, and client native framework, optimization plans are individually formulated. The following mainly introduces two aspects of front-end controllable code and engineering.

Front-end code

Trigger iOS onload in advance

Methods: rAF 嵌套 setTimeoutadvance trigger onload event to address the situation iOS blocking resources to load the page display
Benefits: The first screen time visible to users is not blocked by load

Reduce dependence on first screen

The first screen time can reflect the user's perception of the page speed. The more actions the first screen depends on, the longer the user has to wait. Therefore, in the performance optimization, it is necessary to reduce the operations performed before the first screen and some non-essential operations after the first screen, which can improve the user experience to some extent.

After a period of data collection analysis and code review, we found some improvements:

In the logic before the first screen, when JS initialized some data, it called multiple native-provided methods (end capabilities) at one time, resulting in the end capability execution time-consuming 80-quantile value far exceeding the theoretical value;
The outermost component App of the SPA page is mounted after the data of the first interface is returned. For the web version of the page, the first interface is synchronized, so the App is mounted after the interface has little effect; but for the hybrid version with more usage scenarios, the first screen of the page requires at least two interfaces, and all interfaces The requests are all asynchronous, and the logic necessary to process many pages before the first interface returns is sufficient, and the timing of App mounting is very inappropriate.
There are a lot of dots buried on the page, except for pv, which are mostly the display of some widgets on the page. Frequent sending of dot requests before the first screen squeezes the loading time of the pictures in the first screen.

Based on the above findings, the code has been adjusted as follows:

Adjust the execution order of native end capability calls, the first screen must be left behind, and the other is placed behind, reducing the time spent on end capability execution
Optimize the necessary code information (for example: the runtime of personal homepage from beginning to end) initialization logic
The outermost App component mounting does not depend on the interface data, the page is initialized in advance, the interface data is requested in parallel, and the rendering is asynchronous
Adjust code execution logic, move key logic to store, execute in advance
Logical postpositioning of parts of the page, such as dots, reduces the page mounting execution time. After
a wave of operations, the 80-bit 100ms + gain is obtained.

First screen interface merge

As mentioned above, the first screen of the hybrid requires two asynchronous network interfaces to be serially executed at the front end. From the statistical performance data, in the process of calling the interface and getting the interface data, the longest time is the establishment of the network connection. The two interfaces are merged into one interface, and the first screen time can be saved at least once Internet connection time ( 110ms + for personal homepage ). Of course, the interface merge also needs to consider the server's flat sound, and consider the possible loss of white screen time.

Front screen interface

As a standard SPA page, almost all the logic on the personal homepage page is executed after the public js is loaded, but the js loading takes time, especially when it is first loaded and there is no local cache.
The hybrid version does not have a synchronization interface, and the first request for the first screen can only be issued after the js is loaded, so there is room for optimization in the hybrid version here.
It is known that the mainstream browsers can currently process 4 to 6 requests by default. When loading js, get the data (jsonp) required for the first screen, and the serial becomes parallel to save a time when the two overlap.
The front screen interface did so before:
hybrid packaged a minimal code package as small as possible to fetch the data of the first interface of the first screen, and stored the global variables and events in the event after completion Forms are sent out. Due to the time-consuming first request to establish a network connection in some iOS scenarios, the native-side capability is used instead of jsonp. The iOS screen gain in the first screen interface is 260ms +, and Android is about 60ms .

Engineering

The optimization of engineering is mainly to work hard on packaging. Packaging affects the time-consuming http loading JS, CSS and other resources. Under the same conditions, the smaller the package size and the fewer the number of requests, the faster the resource loading speed.

Packing and unpacking

JS and CSS resources are packaged and merged, but it needs to be considered that the package file is too large, the single request takes too long, and the code package needs to be reasonably split in accordance with the business scenario.
Mainstream browsers can usually process 4 to 6 requests in parallel, which can reasonably split resource packages and use parallel requests to reduce the overall response time.
The browser cache is used to the maximum extent by dividing the packets reasonably. Lock version, keeping each small bundlewhen not change the hash value is stable, larger JS, CSS, and images can be directly written into the hard disk cache. For example, the personal homepage splits the js package into three volumes of similar size according to the frequency of code modification. Vendors are various npm dependencies, the version is stable, and usually does not change. Each time the user goes online, the user's browser only needs to request two other code packages from the CDN. Vendors use the local cache that has not expired last time.

Modern mode

Usually, we use ES6 (ES2015 +) to write code during development. The new features of ES6 can make the development work more convenient and fast. But when packaging, we need to use Babel to convert to make our code run on browsers that do not support ES6. The converted code will be added to polyfill, the most intuitive feeling is that the code package increases in size. modern mode In browsers that support native ES6, js will load the ES module

|
|

White screen (ms)

First screen (ms)


test group
Control group
income

Summary of optimization effects

After optimization, the JS initialization time is reduced. The first screen data jsonp request is sent before the page is prepared using the inline minimal code package. Before the jsonp gets the return value, the other CSS and JS resources required by the page are loaded in parallel; The page runtime is initialized ahead of time. After the first screen data comes back, you can immediately process and render the data without taking up valuable time for some other operations; after the request such as RBI, after the first screen is completed, let JS focus on data and rendering. Free up bandwidth to load user-visible resources such as pictures. The optimized process can be represented by the following diagram:

Data analysis after optimization

The first screen time of both ends is greatly reduced. The first screen request (orange part in the two pictures) is benefited from the optimization of the interface performance of the server classmates. The flat sound alone reduces the time by 80ms +;

And on Android, thanks to the optimization of the hybrid framework of the classmates, the hybrid page and local js resources are loaded faster, and the effect is more significant.

to sum up

If a worker wants to do his job well, he must first sharpen his weapon. Before embarking on optimization, a lot of time was spent selecting data reference points and collecting data, and through repeated code reviews, experiments, and business logic scrutiny to ensure that each key indicator reflected true and reliable data. This article only provides an analysis method of optimization points starting from data. The listed optimization methods are inseparable from the actual business and are not too universal. I hope it can bring you a little different way to solve the bottleneck. Ideas.