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

Researching/Discussing web UI speed optimization/tweaks #3790

Closed
5 of 7 tasks
sphrak opened this issue Mar 9, 2017 · 9 comments
Closed
5 of 7 tasks

Researching/Discussing web UI speed optimization/tweaks #3790

sphrak opened this issue Mar 9, 2017 · 9 comments
Labels

Comments

@sphrak
Copy link

sphrak commented Mar 9, 2017

By curiosity I checked my nextcloud instance on Google PageSpeed Insights and was a bit sad when I realized it didnt even score above 10/100 (actually got 2/100), Dropbox scores 52/100. Now I realize its hard to optimize a system like nextcloud since the data stored there should never be touched, or changed. However there are assets which could be tweaked, compressed and what not. At least thats what I think. So I want us to discuss what can be done and what cant be done here and plan a roadmap for delivering blazing fast UI.

Examples given by GPSI:

  • Minify CSS
  • Optimizing thumbnails
  • Enable compression
  • Eliminate render-blocking javascript and CSS in above-the-fold content
  • Leverage browser caching (not sure how much sense this makes)
  • Avoid landing page redirects
  • Prioritize visisble content

Ongoing:

Research

Goal

Beat dropbox's score of course and develop ideas for how to improve speed and responsivness on the web ui.

@ChristophWurst
Copy link
Member

Also related: #3385

@benediktg
Copy link
Member

Dealing with enabling compression – special for nginx and nextcloud documentation but maybe worth noting here: nextcloud/documentation#325

@sphrak
Copy link
Author

sphrak commented Mar 9, 2017

I've updated the post to reflect the comments so far.
@benediktg I am gonna checkout that and do some benchmarks, since im running nginx aswell.

@ChristophWurst
Copy link
Member

@rullzer is also working on combining vendor scripts: #3795

@MorrisJobke
Copy link
Member

I added checkboxes to the ongoing items and added some more of them. 😉

@MorrisJobke
Copy link
Member

Deferred script loading #4854 (13)

Will come with 13: #4854

@nachoparker
Copy link
Member

nachoparker commented Jul 26, 2017

Hi,

To complement my message on the other post I would like to suggest that some sort of HTTP2 server push is implemented on the server side.

This will allow HTTP2 enabled servers to push assets to the browser even before it fully computes index.php and requests them. Note that assets can be preloaded or prefetched, and we can even preconnect to the server to save TCP connection time.

Also, it should be quite simple to implement. In the case of the NextCloudPi web interface (quite a simple example), it amounts to one line

header("Link: </minified.js>; rel=preload; as=script;,</ncp.js>; rel=preload; as=script;,</ncp.css>; rel=preload; as=style;,</ncp-logo.png>; rel=preload; as=image;, </loading-small.gif>; rel=preload; as=image;, rel=preconnect href=ncp-launcher.php;");

, and the result on a very slow QEMU ARM instance ( gray ball means pushed )

web-push

There's some informative links at the bottom of the blog post.

Should I open a new issue for this "feature request"?

@nextcloud-bot nextcloud-bot added the stale Ticket or PR with no recent activity label Jun 20, 2018
@skjnldsv skjnldsv added the 1. to develop Accepted and waiting to be taken care of label Jun 12, 2019
@ghost ghost removed the stale Ticket or PR with no recent activity label Jun 12, 2019
@szaimen
Copy link
Contributor

szaimen commented May 21, 2021

I suppose this issue is still valid? If not, please close this issue!

@joshtrichards
Copy link
Member

All of the items in the original issue have been addressed. And numerous unmentioned follow-up PRs have been merged.

Closing this issue for the following reasons:

  • hasn't seen any further comments in 6 years
  • any spin-off work is already covered elsewhere
  • other performance work that is frontend related is already covered in other issues or in progress PRs
  • any related future work is better covered elsewhere when someone decides it's important enough

TLDR: This issue has served its useful life. Closing. :)

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

No branches or pull requests

9 participants