Analyse document loading time

[juliusknorr]

We should analyse and improve where feasible

• Loading time when opening a link to a document (loading with files app from scratch)
  • Frontend profiling, possibly optimize viewer and files app loading to be deferred
• Loading time when having the files list open and clicking on a file in the file list
  • Frontend profiling for files app, viewer, richdocuments
• Time of requests that happen from Collabora to Nextcloud
  • Profile requests and see what happens in them in the backend and if things can be improved
  • See if requests can be saved with the new settings endpoints being fetched
• iframe load until document rendering within Collabora
• Can we do any smart pre-loading, like when hovering elements
  • Within Collabora
  • Within Nextcloud

[elzody]

@juliusknorr and I spent some time analyzing the frontend profiling I did and found at least three things so far that should be looked into:

• There is a request to /template/field/undefined
  fix: do not extract fields for blank template server#53477
  This is most likely because the empty/default template uses a technically "invalid" negative integer file ID, so it is not a real file and therefore cannot have its fields extracted.

• There are two WebDAV requests happening on the same file when it is opening
  It seems like the Viewer app along with Richdocuments both send WebDAV requests to get file metadata/info, so while the Viewer API is still being refactored, we can try to find ways to reuse the file information in Richdocuments to avoid this second request.

• The /token endpoint seems to takes a while
  We can profile it in the backend with something like Blackfire to see if there is anything to be improved there

• We can also take a closer look at any potential backend performance issues using the built-in profiler app

[juliusknorr]

Also adding some screenshots for further reference

Total for opening a file after clicking on it

Just the Nextcloud side until the cool.html iframe is loaded 388ms

cool.html loading until document is shown and ui is rendered 1711ms

A few more observations:

• I do not see any frontend side blocking scripts or network requests for Collabora so the question is probably what happens in the backend requests between both servers (as already noted as a last point)
• Collabora: At the end we have some layout shift as the sidebar is showing and that is animated
  • Should we not hide it by default on load or can we not animate it

[juliusknorr]

To save the webdav request after nextcloud/viewer#2989 we can actually reuse the Node object from the viewer and do not need to do another webdav propfind. This also means we can clean up quite some code for the files app integration

[mmeeks]

Ooh - the cool.html loading is too long indeed; do we have timings for the various WOPI fetches that go on for settings etc. behind the scenes there ? and I assume this is a bundled product build (the development build fragments the JS into hundreds of files which are slower to load separately) =) Thanks for chasing this!

[juliusknorr]

Yes, that was on a production build with bundled js files.

I guess settings fetching is worth to investigate, from some production access logs, last number is the request time:

Opening an odt file:

2001:XXXX::877d - - [22/Oct/2025:20:01:05 +0000] "POST /apps/richdocuments/token HTTP/1.1" 200 988 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:144.0) Gecko/20100101 Firefox/144.0" 120783
135.XXX.XXX.XXX - - [22/Oct/2025:20:01:05 +0000] "GET /index.php/apps/richdocuments/wopi/files/11782618_ocmk9xspynvl?access_token=random-token-for-file&access_token_ttl=0 HTTP/1.1" 200 1919 "-" "COOLWSD HTTP Agent 25.04.7.0" 151805
135.XXX.XXX.XXX - - [22/Oct/2025:20:01:07 +0000] "GET /index.php/apps/richdocuments/wopi/settings?type=systemconfig&access_token=4R0gsWJLVIpcpAxHepyYs4d8bnDqC3T3&fileId=-1 HTTP/1.1" 200 1420 "-" "COOLWSD HTTP Agent 25.04.7.0" 126741
135.XXX.XXX.XXX - - [22/Oct/2025:20:01:07 +0000] "GET /index.php/apps/richdocuments/wopi/files/11782618_ocmk9xspynvl/contents?access_token=random-token-for-file&access_token_ttl=0 HTTP/1.1" 200 37051 "-" "COOLWSD HTTP Agent 25.04.7.0" 126132
135.XXX.XXX.XXX - - [22/Oct/2025:20:01:07 +0000] "GET /apps/richdocuments/settings/systemconfig/random-token-for-settings-3/xcu/documentView.xcu HTTP/1.1" 200 7355 "-" "COOLWSD HTTP Agent 25.04.7.0" 82839
135.XXX.XXX.XXX - - [22/Oct/2025:20:01:07 +0000] "GET /index.php/apps/richdocuments/wopi/settings?type=userconfig&access_token=4R0gsWJLVIpcpAxHepyYs4d8bnDqC3T3&fileId=-1 HTTP/1.1" 200 1535 "-" "COOLWSD HTTP Agent 25.04.7.0" 1032271
135.XXX.XXX.XXX - - [22/Oct/2025:20:01:08 +0000] "GET /apps/richdocuments/settings/userconfig/random-token-for-settings-2/browsersetting/browsersetting.json HTTP/1.1" 200 2255 "-" "COOLWSD HTTP Agent 25.04.7.0" 66378
135.XXX.XXX.XXX - - [22/Oct/2025:20:01:08 +0000] "GET /index.php/apps/richdocuments/wopi/settings?type=userconfig&access_token=4R0gsWJLVIpcpAxHepyYs4d8bnDqC3T3&fileId=-1 HTTP/1.1" 200 1530 "-" "COOLWSD HTTP Agent 25.04.7.0" 1271869
135.XXX.XXX.XXX - - [22/Oct/2025:20:01:10 +0000] "GET /apps/richdocuments/settings/userconfig/random-token-for-settings/xcu/documentView.xcu HTTP/1.1" 200 7365 "-" "COOLWSD HTTP Agent 25.04.7.0" 52858
135.XXX.XXX.XXX - - [22/Oct/2025:20:01:10 +0000] "GET /apps/richdocuments/settings/userconfig/random-token-for-settings/browsersetting/browsersetting.json HTTP/1.1" 200 2293 "-" "COOLWSD HTTP Agent 25.04.7.0" 91993
135.XXX.XXX.XXX - - [22/Oct/2025:20:01:10 +0000] "GET /apps/richdocuments/settings/userconfig/random-token-for-settings/template/New%20presentation%20%281%29.odp?identifier=10900873 HTTP/1.1" 200 13161 "-" "COOLWSD HTTP Agent 25.04.7.0" 287557

I cannot easily visualize but it seems the document rendering is only finished after the last settings request has succeeded, but not fully sure about this part.

• The request time of 120-150ms is reasonably good for a Nextcloud request, especially for the ones that need to access the file system and setup possibly complex mount point scenarios with shares
  • optimizing that is continuous effort and nothing that can easily be improved
• However a few things that stand out:
  • Why are we loading odp templates here as the last one?
  • Why is browsersetting.json and xcu/documentView.xcu requested twice?
  • Is the document loading delayed until all those requests are finished?
• /settings?type=userconfig takes unreasonably long, https://blackfire.io/profiles/73ff60d6-04eb-4ada-ad19-3c52d53967f3/graph is a profile of such a request
  • We possibly can optimize the logic that gets the templates in there on our side