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

display content first and then load menus #2226

Merged
merged 2 commits into from
Mar 8, 2022

Conversation

max-nextcloud
Copy link
Collaborator

Rendering the menubar and menububble takes a significant amount of time.
First display the content and then render the menus.

Renders the content >500ms faster on my local dev setup.

Now the content is drawn (LCP) before the large computation load of rendering the menubar:
Bildschirmfoto von 2022-03-07 10-19-02

Rendering the menubar and menububble takes a significant amount of time.
First display the content and then render the menus.

Signed-off-by: Max <max@nextcloud.com>
@max-nextcloud
Copy link
Collaborator Author

max-nextcloud commented Mar 7, 2022

This should also speed up opening files but the content seems to render at the same time as the menubar there. Will need to investigate if it actually speeds up loading there as well or what is blocking it.

update: looks like the menubar is snappy if it has been rendered once. So when opening a file in a folder that has a Readme the menubar will show up right away. Same when opening a file again or another file without reloading the text app in between.
If the editor is rendered the first time this will also speed up rendering of the content in the viewer.

@vinicius73
Copy link
Member

We also can use window.requestAnimationFrame() to "delay" some stuff to create a more smooth experience.

<div id="editor">
<MenuBar v-if="tiptap && !syncError && !readOnly"
<div v-if="tiptap" id="editor">
<MenuBar v-if="initialLoading && !syncError && !readOnly"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be better to use a computed here?

Also rename `initialLoading` in `EditorWrapper` to `contentLoaded`.
This flag is set during the `initialLoading` state change.
It does indicates that the loading happened
Use the past tense to indicate that.

The editor wrapper is now loading in different steps.
The menus will load after the content.
So `content` seems more fitting then `initial`.

Signed-off-by: Max <max@nextcloud.com>
@max-nextcloud max-nextcloud force-pushed the performance/postpone/rendering-menubar branch from 337c2da to 3ca1038 Compare March 8, 2022 09:29
@max-nextcloud
Copy link
Collaborator Author

We also can use window.requestAnimationFrame() to "delay" some stuff to create a more smooth experience.

For now i am mostly trying to render the content as early as possible. In the rich workspaces in files the menubar will not show anyway. So we can easily speed up the loading of the text by postponing the menubar loading.
When opening a file to edit it would be nice if the menubar was snappy... however the content still seems more important.

I did read upon requestAnimationFrame but i am not sure how it would apply here. What's the effect you would want to achieve?

@vinicius73
Copy link
Member

I did read upon requestAnimationFrame but i am not sure how it would apply here. What's the effect you would want to achieve?

Nothing for now @max-nextcloud, maybe in new interactions about performance improvements.

@juliusknorr juliusknorr merged commit f04d31d into master Mar 8, 2022
@delete-merged-branch delete-merged-branch bot deleted the performance/postpone/rendering-menubar branch March 8, 2022 21:51
@max-nextcloud
Copy link
Collaborator Author

/backport to stable23

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Improve read only performance when just displaying rich workspace
3 participants