preface

With the development of mobile Internet, users have higher and higher requirements for product experience. As an important carrier of services, H5 is widely used in mobile terminals, so H5 page performance is a very core index of user experience.

This paper introduces the idea of page performance optimization based on [First-screen optimization practice of Ele. me].

First screen performance indicators

The primary foundation of performance optimization is data and metrics. Without correct data and indicators, optimization ideas and directions may be biased.

UC supports kernel and W3C standards in front screen performance statistics.

The kernel indicators

  • Start: The point at which the blink kernel starts to create requests, which can be understood as point “0”
  • T0: blink Time when the HTTP head is received
  • T1: indicates the time when content is displayed on the first screen
  • T2: the time when the first screen is fully displayed

Performance W3C metrics

First screen time refers to the time when all resources are displayed on the first screen. This is a very direct experience metric for users, but a very difficult metric to measure statistically for the front end.

The usual approach is to use domContentLoadeDeventend-fetchstart, or even loadeventstart-fetchstart, while the page DOM tree is parsed and the content is displayed. The following describes how to collect page performance statistics.

Performance monitoring

Online monitoring is of great significance for data tracking and problem discovery. Generally, in the testing stage, we can only do basic analysis, and it is difficult to obtain real and accurate data in different environments. Then how to know whether there is a problem after the online performance, or how to eliminate the problem as soon as possible when there is a problem? Real-time online monitoring is the best choice.

Yueying panoramic monitoring platform can conduct real-time analysis of the data collected and reported by THE SDK, and view the performance indicators of applications intuitively and conveniently. In addition, you can set alarm rules to notify performance indicators when they reach the threshold. In this way, problems can be discovered and handled in a timely manner.

Real-time market

Through the real-time market, the initial understanding of performance fluctuations.

Viewing the Performance Trend

View page performance and analyze the first screen performance and page loading performance by core indicators, such as first byte, DOM Ready, and page full loading. (If UC kernel is connected, the performance of the first screen can be intuitively understood through T2)

Analyze and locate the page

Further analysis to understand the performance of TOP access pages

Through the multi-dimensional aggregation analysis, further locate the problem scope

Details analysis

Performance Optimization

Further analysis and optimization can be carried out after ground analysis with online data.

1 Optimization Direction

Front end: The front end focuses on the optimization of the first screen, convergence of domain names, JS resource governance, JS time-consuming governance, image governance, interface governance and other directions.

Client: Client focuses on improving container startup speed, optimizing interception logic, providing front-end preloading and other capabilities, and providing class native experience.

[Dry goods Warning] The following is our overall optimization idea in the SPECIAL OPTIMIZATION of ELE. me H5.

H5 resources and data depend on the network, so one of the strategies in optimization is preloading. Let’s take a look at some of the common caches in an H5 scenario.

  • HttpCache: Cache resources that are returned from the network according to certain rules and can be read directly from the local server the next time they are used. Stale-while-revalidate allows a resource to continue to be used for a certain period of time after expiration, while making an asynchronous request that allows the resource to be used before validation.
  • LocalStorage: The front-end can use LocalStorage to store resources locally, as well as IndexedDB. LocalStorage also has some restrictions. For example, a domain name can only store 5M of data and cannot be read across domains.
  • MemoryCache: MemoryCache. In Chrome, MemoryCache is mainly managed by GC. Resources entering the MemoryCache are associated with a weak reference, which is cleared when the main document is closed.
  • ZCache: When the user accesses a page, the kernel uses a shouldInterceptRequest to ask if the shell has available resources. If it does, the shell returns resources instead of going to the network to request them. ZCache will go to the shell interception logic, which is less efficient than HttpCache. It takes 100ms for normal resources to the Blink kernel and 300ms for main documents.
  • NetCache: DNS resolution result, which is multiplexed over long connections.
  • V8 Bytecode Cache: V8 Bytecode Cache. JS execution once, the second execution can significantly reduce the time.
  • Image Decode Cache: Image Decode Cache.
  • PageCache: a page-level cache. The WebViewCache is generated when you click the forward and back buttons in the UC browser.

For these caches, we often use preloading methods.

  • Load full-screen documents in advance: mainly used in information flow, load documents of the first few items in advance, and users can access them in seconds when they click.
  • Preloading the first screen image: mainly used for information flow. When clicking to access a document, the image request is sent at the same time. When the image is needed for document parsing, the first screen image has been preloaded to the local.
  • Link preload: Indicates resources that need to be preloaded in the resource response header or main document header. The kernel preloads these resources according to certain rules and priorities.
  • Module preload: Similar to Link preload, but module-level preload. In addition to preloading the dependent resources of the Module, Module JS can be compiled and parsed ahead of time.
  • Link prefetch: domain name advance addressing.
  • Preloading interface data: navigation preloading & algorithm preloading at idle time.

For interface preloading, we do it in the JS plugin. You can also intercept processing in the network library middleware. There are two implementations of HTTP interface preloading:

  • ShouldInterceptRequest: if there is a Response cache, return it.
  • MtopWVPlugin (ANetBridge) interception: We re-implemented a JS Plugin extension similar to MtopWVPlugin, which intercepts in the extension layer.

2 Performance analysis tools and platforms

  • Rulban: Built on Lighthouse, UC Rulban analyzes how pages are actually rendered in the kernel and makes recommendations for optimization.
  • Seagull LABS: UC Seagull LABS is a performance analysis platform that provides complete first screen, memory, startup, frame rate analysis data.
  • Lighthouse: Detects page performance bottlenecks.
  • Timeline: Records details about the running process of a page and analyzes the location of a fault on the page.
  • Profile: Analyzes page memory usage and JS/CSS execution time. TImeline can be used to figure out the location, and JavaScript CPU profiler can be used to analyze the elapsed time of each JS function in detail.
  • Chrome Trace: Records the complete process of page execution in the browser kernel. The granularity is fine to each function method, which can accurately locate specific problems.

To optimize the practice

Let’s take a look at how to analyze performance optimization points for an H5 page.

1. Get performance analysis data

UC Luban platform can be used. It generates a sexual performance report

You can also capture Timeline and Chrome Trace logs locally. Once we get the performance report, we can see roughly where the time is, resource loading, S time, etc. Then make specific analysis according to the Trace log.

2. Get the T2 log and analyze the T2 timeline

If the UC kernel is connected, you can analyze T2 logs. Pay attention to the following data during analysis:

  • FrameCount: The last frameCount of T2, which means T2 has been computed at this frame. When we search for T2Paint_Event on the Trace screen, we find this frameCount, press m, and mark T2.
  • TStart: indicates the time when T0 starts to calculate. Search TStart_Point to locate this point.

Once T2 line is determined, the page rendering before T2 line can be analyzed, as well as the factors affecting page rendering.

3 Analyze the overall performance

Analyze the overall rendering condition of render before T2, such as the part with long JS execution and the part with long loading time.

4 Analyze the loading performance

Mainly Doc, interface and load performance of various resources. Generally speaking, loading time over 300ms is considered very slow, depending on whether the resource is in the offline cache.

5. Analyze typesetting performance

The main analysis is whether the content of typesetting is reasonable, whether the timing of typesetting is reasonable, whether there is a lot of rearrangement, refresh the style.

6 Analyze THE JS performance

JS performance mainly includes three aspects:

  • JS parsing and compilation time
  • JS corresponding business logic
  • JS specific function execution time

Generally speaking, v8.compile takes more than 100ms, which is relatively time-consuming.

Also be aware of the execution interval between two V8.8. runs, which typically occurs when waiting for an interface or resource. This can be a point of optimization, such as interface preloading, resource offline, etc.

Then use timeline to analyze the time of specific functions, find out js functions that are time-consuming, and optimize them accordingly.

7 observe the influence of image decoding on T2 time

Generally speaking, there are two factors that affect T2 calculation:

  1. Picture decoding and rendering.
  2. The first screen content is changed. (Slide, image lazy loading, dynamic node)

Pictures, especially small ICONS, will significantly affect T2 time on some pages, such as the selection of red envelope page in Ele. me. After analysis, it is the small ICONS on the red envelope list that greatly extend T2 time. It took more than 1400 ms to optimize T2, and the performance was improved by more than 45%.

Therefore, we can replace these small images with IconFont or CSS (SVG vector image cannot calculate the width and height of the image, so it is not included in the calculation). The uc-perf-stat-ignore flag (3.22 is supported in newer versions of the kernel) can also be used if the T2 calculation is to be ignored in some images.

Compare the time difference between UC’s T2Paint_Event and W3C’s loadEventStart to observe the effect of image decoding on T2 calculation.

Search DecodeImage to see how images are decoded

Free trial yueying panoramic monitoring platform

This article will introduce you so much, if you want to know the performance of the application online, welcome to try yue Ying panoramic monitoring platform.

Yueying panoramic monitoring platform, let the user experience to improve the more simple >>>