Open QingAn opened 2 years ago
WebView vendors maybe could export API like webview.prefetch()
to native-app developers?
WebView vendors maybe could export API like
webview.prefetch()
to native-app developers?
Maybe @rayankans can provide some input?
Perhaps load offline resource for one party business can accelerate content display?
Reducing the First Contentful Paint is always a huge improvement, and definitely something that should be made as simple as possible.
There are many ways to address this via the Web Platform, like the prefetch/resource hints suggested by @QingAn, or potentially the use of ServiceWorkers. Assuming there is full feature parity with the Web Platform, that would improve loading times.
I'm not sure what advantages prefetching from the native side would give us here. I'm more leaning towards improving Web Platform feature coverage in WebViews since it seems to be it would give the same result with less work for developers and more coverage across different WebViews.
I'd love to hear some more use-cases about prefetching from from the native side however if there are any.
@rayankans
I'm more leaning towards improving Web Platform feature coverage in WebViews since it seems to be it would give the same result with less work for developers and more coverage across different WebViews.
I think that's what @yuanyan means by saying:
WebView vendors maybe could export API like
webview.prefetch()
to native-app developers?
From native side, I think currently there is no option but to implement prefetching from native side, because this Web Platform feature has not been covered in WebView yet. We can further discuss the possibility and potential risk if any of supporting this feature in WebView.
We try some experimental work. Load first party web application by an invisible WebView. When the application is updated, the server push requires the client to updated cache by reload in invisible WebView. We try to improve the cache loading rate on the user side.
Perhaps WebView should provide official webview.prefetch(request) capability. 对于一方业务,有助于提高有缓存加载率,也可以保障缓存的新鲜度满足要求(这句话几个名词不太知道咋翻译,在下洋文水平有限,只能用中文表达了)。
If there is no local cache of web page resources and the network conditions are good, it will take about 1.2s to load web page. If load web resources form cache, the loading time from the disk cache is 0.5s, and load memory cache time is 0.3s. In the process of invisible WebView preload exploration, Website load speed looks faster through the data. The cache loading rate and the efficiency of the cache are okay. But, there are still some unforeseen problems in loading resources with invisible WebView. If WebView provides an official capability of webView.preload(request), then provides the configuration of various http caching strategies, which is of great help to the business. User experience will be improved.
中文对照: 我们有做一些探索性的工作,比如我们的App内,有部分重点一方的业务采用网页的方式实现,如果本地没有网页资源的缓存,网络条件好的情况下,网页完成加载大致需要1.2s左右。有网页资源的缓存的情况下,从磁盘缓存加载需要时间0.5s,内存缓存0.3s。 基于上述数据,我们想,如果可以提高网页的有缓存加载率,用户视角就可以更快的看到内容。于是尝试搞了个静默的WebView加载资源,一旦网页更新,后台就通过push让客户端访问一次那个网页,刷新本地的网页资源缓存。 在探索过程中,通过数据可以发现效果还是可以的,有缓存加载率以及缓存的新鲜率都还可以,但是用静默的WebView加载资源还是有一些坑的,后续没有进行进行大范围的商业化推广,如果WebView提供官方的机制去给一方业务做预加载,再提供上各种http缓存策略的配置,对于业务大有助益,用户体验也会得到可观的提升。
If there is no local cache of web page resources and the network conditions are good, it will take about 1.2s to load web page. If load web resources form cache, the loading time from the disk cache is 0.5s, and load memory cache time is 0.3s. In the process of invisible WebView preload exploration, Website load speed looks faster through the data. The cache loading rate and the efficiency of the cache are okay. But, there are still some unforeseen problems in loading resources with invisible WebView. If WebView provides an official capability of webView.preload(request), then provides the configuration of various http caching strategies, which is of great help to the business. User experience will be improved.
This demonstrates the benefits of pre-render of a WebView page, which includes prefetch page resources and page data. I think we share similar use cases.
@rayankans In next meeting, suggest we can discuss further whether it could be listed as a valid use case?
@rayankans In next meeting, suggest we can discuss further whether it could be listed as a valid use case?
+1, prerendering is a good use-case.
From native side, I think currently there is no option but to implement prefetching from native side, because this Web Platform feature has not been covered in WebView yet.
That seems like even more reason to cover it from the Web Platform side.
Rough consensus from 2022-05-11 meeting: https://www.w3.org/2022/05/11-webview-minutes.html#t02
Title: Load a WebView page
Submitter(s)
Qing An, Alibaba
Motivation:
It is quite common to use WebView in Native App development, due to WebView’s benefit of cross-platform interoperability. But the page loading performance of WebView cannot satisfy Native App well, which means the loading of a WebView page is quite slower than loading a Native page.
The above is WebView page loading, it firstly shows the white screen.
But for the Native page loading, it shows the skeleton immediately, which gives a better user experience compared with WebView.
Therefore, how to enhance the loading performance of WebView page needs to be addressed.
Stakeholders:
Stakeholders include:
Analysis
The reason of long white screen is due to serial execution in loading a WebView page. The duration of white screen directly depends on the time cost from routing intercept to JS download & parse & exec as described in the following figure.
Related W3C deliverables and/or work items:
How is the issue solved in the Browser, and what’s more is needed?
Prefetch
,Preload
andNext
are used to pre-request resources (e.g. HTML, CSS, JavaScript, Img, etc.), but they are not supported or only partly supported by WebView.