Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable WebView caching #11800

Open
Pilzinsel64 opened this issue Jul 12, 2023 · 5 comments
Open

Enable WebView caching #11800

Pilzinsel64 opened this issue Jul 12, 2023 · 5 comments
Labels
enhancement feature: editor performance 🚀 Performance improvement opportunities (non-crash related)

Comments

@Pilzinsel64
Copy link

Pilzinsel64 commented Jul 12, 2023

Is your feature request related to a problem? Please describe.

Whenever you open a document, the amount of data downloaded (even for empty documents) is about 15 MB. On mobile data this is absolutely too much.
--> The reason is file core-common.js is too big and the WebView wont cash it.

I already have http compression enabled but this does not help in WebView. The Cache of the WebView seems to be cleared each time directly on closing it. This triggeres a completely redownload of that js file (and of course others).

Also, this absolutely slows down the process of opening a document - from tapping on it to the content is shown. Most of the times there is "it needs long to load" at the bottom to read. (No, my server is fast enough and my internet connection is 500/100 glass fiber - this is not the problem.)

This does also happen to the Notes apps, see here: nextcloud/notes-android#1843

Describe the solution you'd like

Enable caching of WebView or at least make it an option. The cache should not be cleared on closing the WebView and also not on closing the App. It should be saved into the App Cache (at least I read this would likely for apps with webview cashing enabled, you probably know the right solution).

Describe alternatives you've considered

Reduce the size of loaded components on https://github.com/nextcloud/server, with under core-common.js. The pull request nextcloud/server#38329 is mostly a performance boost in general but will not degrese the amount of data downloaded. For public web pages like direct editing it should not use all of that components.
This is only a workaround in my opition.

Additional context

See the following topic. Read carefully, there are screenshots, logs and so on. Also check the issue following.
https://help.nextcloud.com/t/loading-new-page-hanging-under-certain-conditions/165873
nextcloud-snap/nextcloud-snap#2450

NOTE: Be super sure to remove sensitive data like passwords, note that everybody can look here! You can use the Issue Template application to prefill some of the required information: https://apps.nextcloud.com/apps/issuetemplate

@Pilzinsel64
Copy link
Author

Pilzinsel64 commented Jul 26, 2023

I found this line. Is there any reason to not set this to LOAD_CACHE_ELSE_NETWORK or at least LOAD_DEFAULT when Debug mode is DISABLED?

if ((getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0) {
webSettings.setCacheMode(WebSettings.LOAD_NO_CACHE);
}

@AndyScherzinger
Copy link
Member

can't tell, maybe @tobiasKaminsky knows

@joshtrichards joshtrichards added the performance: misc lag, ANR, etc and rarer exceptions/errors that don't have their own labels label Oct 18, 2023
@joshtrichards
Copy link
Member

My reading of that line (and the docs) is that it's only disabled for debug mode. So LOAD__DEFAULT is the default when not debugging [1].

So I don't think the fix will be as simple as toggling that...

[1] https://developer.android.com/reference/android/webkit/WebSettings#LOAD_DEFAULT

@Pilzinsel64
Copy link
Author

Pilzinsel64 commented Oct 19, 2023

Hm, maybe something else block the caching. While LOAD_DEFAULT should be the best thing (and yea, your're right, it's default here), it simply doesn't use or even save the cache.

Even the text on the API documentation says "if available". Maybe it isn't available at all due another configuration? 🤔 What could be other options to check?

Maybe it even might be a vendor thing? We have tested "Android System WebView" and Googles WebView implementation on a LineageOS 20 & 19 (= Android 12 & 13) and on a Samsung Galaxy S20 (also 12 or 13, not sure exactly yet) with the most recent updates.

Anyway, I would like to test the one line change from above via LOAD_CACHE_ELSE_NETWORK to see if any cache is avaible at all, but don't want to install and configure Android Studio just for this line. Would it be okay if I make a quick draft PR, so I can get the APK from it?

@Pilzinsel64
Copy link
Author

Pilzinsel64 commented Oct 19, 2023

A quick screen record using a fresh NC28 dev instance via https: https://cloud.pilzinsel64.de/s/eGiFQ94g6EQyoAP

Also in NC28 the amount of data still is between 15 and 20MB for each time opening a document. Even due the reduced size of core-common.js.

@joshtrichards joshtrichards added the performance 🚀 Performance improvement opportunities (non-crash related) label Dec 20, 2023
@joshtrichards joshtrichards removed the performance: misc lag, ANR, etc and rarer exceptions/errors that don't have their own labels label Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement feature: editor performance 🚀 Performance improvement opportunities (non-crash related)
Projects
None yet
Development

No branches or pull requests

3 participants