Enterprise WeChat | leads the mobile end projects have demand to show visual chart data trends, through investigation and research, finally decided to H5 to complete in a single page, some use in the APP H5 implementation of functional modules, general experience is worse than the native, so how to improve the H5 loading speed? Optimize the H5 experience?

Application scenario: Functional modules for presentation that require rapid iteration and are difficult to implement on the client, such as visual charts.

Why does the H5 experience suck

Why does an H5 page have a long blank screen? Because it does a lot of things, like:

Initialize webView -> request page -> Download data -> parse HTML -> request JS/CSS resources -> DOM render -> parse JS execution -> JS request data -> parse render -> download render image


Generally, pages can only be displayed after DOM rendering. It can be found that the key reason for H5 first screen rendering blank screen problem lies in how to optimize and reduce the time between the request to download the page and rendering.

How to optimize

The above process of opening a page has many optimization points, including front-end and client side. General front-end and back-end performance optimization has been summarized by predecessors as best practices. The main ones are:

  • Reduce request volume: merge resources, reduce HTTP requests, Minify/gzip compression, webP, lazyLoad.
  • Speed up the request: pre-resolving DNS, reducing the number of domain names, parallel loading, CDN distribution.
  • Cache: HTTP protocol cache request, offline cache manifest, offline data cache localStorage.
  • Render: JS/CSS optimization, load order, server render template straight out.

In general, most front-end performance problems can be solved simply by comparing differences with this list. However, after careful re-analysis, network requests, including requests for static resources such as HTML, CSS, image and display data, have the greatest impact on the first screen startup speed.

So H5 related pages and resources package to the client, and then the client will display data to the page, through the webView loading display, so almost no network request, webView just render the page, js can be executed, this experience is not very perfect?

Third, how to achieve it?

The overall idea seems clear, but there are a few key issues that need to be addressed:

3.1 How does the local H5 page communicate with Native?

There are basically three ways to communicate with native H5 pages: JSAPI, URL Scheme and string substitution. Specific methods are suitable for different scenarios:

Jsapi: The client provides an interface. The injection API enables Javascript to call and directly execute the corresponding Native code, which is suitable for data request scenarios requiring interaction

URL Scheme: The Web sends a URL Scheme request, and Native intercepts the request and performs related operations according to the URL Scheme and its parameters. This mode is applicable to page hopping scenarios.

String substitution: After reading the local H5, the client loads the display page by performing string substitution on the agreed marker bits in H5. Suitable for scenarios where there is no complex interaction and only data is rendered through the page.

3.2 How to Develop, debug, and maintain

To develop local H5 modules, it is easy to think of simulating data development locally, and then packaging the H5 to each client for joint tuning. However, the implementation of such a scheme is very complicated, because H5 resources are scattered and not unified when packaged to the client, and it is difficult to manage.

Then we will use the page of the local H5 implementation module to establish a unified Git repository. The IOS and Android clients will link the local H5’s Git external to the project through git submodule, so that the resources in the client can be managed uniformly. It frees up the tedious manual replacement packing every time.

However, this approach is not perfect, H5 instead of the native implementation advantage, one is low development cost, another is that H5 can be updated more quickly, if packaged in the client H5 page is just like the client, can not be updated quickly. It is easy to think of the H5 resources to the background, the client according to the service module pre-download the entire offline package, the offline package according to the version of incremental update. This kind of scheme can better solve the above problems.


Fourth, detail optimization

With the above issues resolved, the native H5 can actually load in seconds, but there are a few details that need to be optimized to achieve the same experience as the client:

Preload webView and prepull data

In the process of combining local H5 pages, it was found that the time of loading the page for the first time was much slower than the time of opening subsequent pages. The reason was expected to be that there were many resources and services needed to be started when webView was initialized for the first time. Therefore, the client tried to initialize the webView scheme in advance, and as expected, it was faster when the page was opened for the first time. At the same time, in order to display data directly when H5 is opened for the first time, the client will pre-pull data and cache it before the page is opened, so as to reduce the blank screen caused by data request time.

Disables automatic recognition of WebView HTML content

By default, IOS webView automatically detects and marks mobile phone number, email, and address in HTML. Workaround: Disable the default behavior by adding a meta header

  <meta name="format-detection" content="telephone=no,email=no,adress=no">Copy the code

Click on the delay

In a WebView, click typically has a latency of about 300ms (which also includes any user click, link click, form submission, control interaction, etc.).

Solution: Using Fastclick/Touchend generally solves this problem.

internationalization

H5 in the client also needs to be internationalized. There are many front-end internationalization schemes, and usually the corresponding internationalization plug-ins are selected according to the project framework. However, introducing additional plug-ins in the local H5 page will increase the client package size, which is slightly redundant. What works for you is best, and a lightweight internationalization approach is adopted here.

1. Extract language copy

2. Extracted copy referenced in pages and JS

3. Switch the language scheme based on the configuration

 $('.i18n').each(function() {
     var key = $(this).attr('name');
     $(this).html(language[key]);
 });

 var language = getQueryVariable('en') ? i18n.en : i18n.zhCopy the code

WKWebView compatible

WKWebView performance is much better than UIViewView performance, so client development is generally recommended to use WKWebView.

However, there are some compatibility issues when using WKWebView to load local HTML. In iOS8, you cannot reference local CSS or JS or image files in HTML files. IOS8 and above is normal, you can reference remote resources. In order to take into account compatibility and second open experience, so do degrade solution, dynamic loading JS by system version, IOS8 using network resources, IOS8 using local resources.

Also in iOS8, the use of some remote CDN CSS or JS files, must pay attention to the reference tag with the charset attribute, or CSS and JS library will be garbled

Five, the last

From front-end optimizations, to client caching, to offline packages, to more detailed optimizations, H5 pages start up almost as good as the native experience.

In summary, the general optimization idea is: reduce all network requests, do a good job of preloading and caching, and try to load everything before users open it. Some of these optimizations also need to be evaluated based on the project and actual requirements, and need to be weighed against development costs and efficiencies. The optimization scheme discussed above is only for the single-page H5 page of function modules. Other H5 pages with more complex interactions may not be applicable, and it needs to be determined by the actual situation and requirements.

reference

WebView performance, experience, analysis and optimization: https://tech.meituan.com/WebViewPerf.html

More than 70% of the business is developed by H5. How to optimize and evolve the structure of mobile QQ Hybrid?

Mp.weixin.qq.com/s/evzDnTsHr…

If you think our content is good, please forward it to moments and share it with your friends