Skip to content

Analyse document loading time #4811

Open
Overview
Open
Analyse document loading time#4811
Overview
Labels
1. to developWaiting for a developerhighperformance 🚀

Description

@juliusknorr
juliusknorr
opened on May 28, 2025

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

Activity

  1. juliusknorr
    added
    1. to developWaiting for a developer
    performance 🚀
    on May 28, 2025
  2. juliusknorr
    added the
    Overview
    issue type on May 28, 2025
  3. juliusknorr
    added this to 📝 Productivity teamon May 28, 2025
  4. github-project-automation
    moved this to 🧭 Planning evaluation (don't pick) in 📝 Productivity teamon May 28, 2025
  5. juliusknorr
    moved this from 🧭 Planning evaluation (don't pick) to 📄 To do (~10 entries) in 📝 Productivity teamon May 28, 2025
  6. juliusknorr
    added
    high
    on May 28, 2025
  7. juliusknorr
    assigned
    elzody
    on Jun 4, 2025

  8. elzody commented on Jun 12, 2025

    @elzody
    elzody
    on Jun 12, 2025
    Collaborator

    @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

  9. juliusknorr commented on Jun 13, 2025

    @juliusknorr
    juliusknorr
    on Jun 13, 2025
    MemberAuthor
    Also adding some screenshots for further reference

    Total for opening a file after clicking on it

    Image

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

    Image

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

    Image

    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

  10. juliusknorr commented on Oct 22, 2025

    @juliusknorr
    juliusknorr
    on Oct 22, 2025
    MemberAuthor

    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

  11. mmeeks commented on Oct 22, 2025

    @mmeeks
    mmeeks
    on Oct 22, 2025
    Contributor

    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!

  12. juliusknorr commented on Oct 22, 2025

    @juliusknorr
    juliusknorr
    on Oct 22, 2025
    MemberAuthor

    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

  13. juliusknorr commented on Oct 22, 2025

    @juliusknorr
    juliusknorr
    on Oct 22, 2025
    MemberAuthor

    Regarding those user / system settings, can we tell how often they are really updated? Currently we store them on disk, but it may be wise to have some in memory caching in between

  14. juliusknorr
    unassigned
    elzody
    on Nov 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    1. to developWaiting for a developerhighperformance 🚀

    Type

    Overview

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions