All H5 projects in the acquisition APP are opened through WebView. The general impression about the performance of WebView is that the opening speed is slower than native.
For SPA applications, a user opening Webveiw to access H5 needs to go through the following process:
- Click the App entry (e.g. Banner, etc.)
- Reaching the new page, the page is blank.
- The basic frame of the page appears (skeleton screen), but there is no data. The page is in loading state.
- All the data is present, and the page is completely rendered.
From a program execution point of view, let’s look at an unoptimized WebView loading H5 process:
Compressing the time of each stage is the key to performance optimization.
WEBVIEW
Combined with the APP’s WebView, we adopted two optimization methods:
- Static resources built in: JS, CSS and other static resources built in the App. The App intercepts the request and returns the local file directly, which of course involves a series of caching flush policies. The offline file hit rate is currently over 40%.
- HTML preload: APP cold start will actively pull HTML from key entries as a cache.
There is a 15% increase in the opening rate as shown below.
H5 optimization
SPA and SSR
SPA venue under the page rendering the whole process:
The whole process of page rendering under SSR venue:
SPA vs. SSR performance on FMP, the middle notch is the line cut to SPA, indicating that SSR has an average of 15% improvement in SEC opening.
Loading timing optimization
Analyzing the HTML of the page, we find that some JS scripts block the HTML load.
Reduces the script load of three blocks.
The resource volume
Image optimization
webp
WebP’s ability to achieve a 90% compression rate is extremely important.
Existing solutions in the SSR straight out components do not have WebP capabilities. Even though WebP is supported on the end, JPG or PNG images are also loaded, resulting in too large resources. However, after the 14 version of iOS, iOS has the ability to support WebP. After consulting iOS students, the 14 version accounts for at least 70% or 80% of the total.
plan
All images are webp. Do a WebP check on the server, if it is not supported, downgrade to the original JPG or PNG.
The effect
Mobile phones that don’t support WebP: Note the header diagram.
Lossless compression service
Imagemin/Imagemin is an open source solution to solve the problem of large image from the image source. Unified closure and interaction of the picture transmission at the venue, to avoid the situation of multiple uploads of the same picture. The average compression rate is 60%.
Package volume
- Removal of useless custom components – 33K
- Lodash size as needed -24K
- Shence SDK creates script loading through JS. The SDK also solves the problem of namespace preaccess. 76 k
- The dependence of KOA-Router. -21 k
-
Components are loaded on demand.
Total resource optimization data
Optimize data the first day after launch
Lighthouse score dimension analysis conclusion
Lighthouse scores
Before optimization
After the first phase optimization
Conclusion: Lighthouse improved by 20%+.
Browser resource dimension data analysis conclusion
Data before optimization:
After the optimization of the first phase:
Conclusion: Transferred increased 20%.
Comprehensive analysis conclusion
The first phase of optimization resulted in an overall performance improvement of 10% based on a variety of data aggregations.
SSR component experience optimization
The status quo
Some components don’t pop out on the Node side and don’t have the ability to lazily load images.
plan
Node ends directly out of the component, and off-screen images are lazily loaded.
The effect
Involves one – key voucher, sub-venue entrance and other components
Before:
After:
FMP effect of total
After a series of efforts, APP end optimization and H5 end optimization. We increased the page open rate to about 40% per second.
Ask en about |
Pay attention to the technology of things, hand in hand to the cloud technology