All h5 projects in App are opened through WebView. The common impression of webView performance is that it is slower to open than native.

For SPA applications, a user opens Webveiw to access H5 through the following process:

  1. Click on the App entry (such as banner, etc.)
  2. The new page is reached, and the page is blank.
  3. The basic frame of the page appears (skeleton screen), but there is no data and the page is in loading state.
  4. All data appears and the page is fully rendered.

From a program execution perspective, let’s look at the process of loading H5 in an unoptimized WebView:Compress the time of each phase, is the key point of performance optimization.

WEBVIEW

In combination with the WebView of App, we adopted two optimization methods:

  • Built-in static resources: Static resources such as JS and CSS are built into the App. The App intercepts the request and returns it directly to the local file, which of course involves a series of caching strategies. The offline file hit rate is currently in the high 40% range.

  • HTML preloading: App cold start will actively pull the key entry HTML for caching.

As shown below, the second opening rate has increased by 15%.

H5 optimization

SPA and SSR

The whole process of page rendering in SPA session:The whole process of page rendering in SSR conference:The performance of SPA and SSR on FMP, the middle groove is the case of the line cut to SPA, it can be seen that SSR has an average 15% improvement on SEC.

Load timing optimization

Analyzing the HTML of the page, we found that some JS scripts block HTML loading.

Reduce script loading by three blocks.

The resource volume

Image optimization

webp

Webp’s ability to achieve 90% compression is extremely important.

Existing solutions in SSR straight out components do not have webP capability. JPG or PNG images are loaded even if webP is supported on the side, causing the resource to be too large. After ios version 14, ios has the ability to support WebP. After consulting ios students, the 14 version accounts for at least 70% or 80%.

plan

All images displayed from the node are WebP. Do a webP check on the end, not support will be degraded to the original JPG or PNG.

The effect

Phones that do not support WebP: Note the header diagram.

Lossless compression service

From the image source to solve the problem of the image is too large, using the open source solution Imagemin/Imagemin. The meeting picture transfer unified interface interaction, to avoid the same picture uploaded several times. The average compression rate is 60%.

Package volume

  • Delete useless custom components -33k
  • On demand lodash size -24K
  • The SDK uses JAVASCRIPT to create script loads. And solve the divine policy SDK namespace front access. 76 k
  • The dependency of the KOA-Router. -21 k
  • Components are loaded on demand.

Total resource optimization data

Optimize data on the first day after launch

Conclusion of Scoring dimension analysis of Lighthouse

Comprehensive Score of Lighthouse

Before optimization

After the first phase optimization

Conclusion: Lighthouse improved by 20%+ accordingly.

Conclusion of browser resource dimension data analysis

Data before optimization:

After the first phase of optimization:

Conclusion: TRANSFERRED increased by 20%.

Conclusion of comprehensive analysis

In the first phase of optimization, performance was improved by 10% based on various data aggregates.

SSR component experience optimization

The status quo

Some components are not directly displayed on node, and there is no lazy image loading capability.

plan

Components are directly displayed on the node, and off-screen images are loaded lazily.

The effect

It involves one-key coupons, sub-conference entrance and other components

Before:After:

FMP effect of total

After a series of efforts, App side optimization and H5 side optimization. We’ve increased our page opening rate to around 40%.

Wen | ask en

Focus on object technology, hand in hand to the cloud of technology