Closed SamuAlfageme closed 3 years ago
Just realized how slow the authorization webview for OAuth2 loads under mobile networks / slow connections. Profiling a bit with chrome; I found out there is ~500KB worth of JS and CSS assets loaded:
we did not pay that much attention to this because usually they are all grabbed from the browser cache. But for the mobile oauth webview this might be an issue because the user most likely did not hit the server before ....
the user most likely did not hit the server before ...
Every webview is sandboxed and run from scratch, so yes: no way there are cached contents as for today.
However, I'm not completely sure removing some unnecessary statics from here and there would speed up the whole workflow. Need to do some benchmarking.
Similar to this behavior; yesterday I found out that regular pooling to the /notifications
endpoint is also happening under the hood on an open OAuth's "authorize" screen.
As a rule of thumb, I'd say when the top bar (where the notification container is located) is hidden, we should simply not pool this endpoint for events. I'll create an issue.
Just realized how slow the authorization webview for OAuth2 loads under mobile networks / slow connections. Profiling a bit with chrome; I found out there is ~500KB worth of JS and CSS assets loaded:
https://github.com/owncloud/core/blob/55fb4c27eaf05e33b29b9acae1391db51664af7b/core/templates/layout.guest.php#L16-L24
I guess the "guest" layout applies also for things like the "anonymous uploads" view and probably more. But keeping leaner login-authorize pages will result in a better mobile integration.
Feel free to close if considered not relevant. Or if it turns out most of the assets are indeed required or the ones that could go away are a negligible portion.
cc/ @felixheidecke