-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Make page loading faster, deferred script loading, now switchable: #4854
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
Make page loading faster, deferred script loading, now switchable: #4854
Conversation
|
@michaelletzgus, thanks for your PR! By analyzing the history of the files in this pull request, we identified @jancborchardt, @LukasReschke and @rullzer to be potential reviewers. |
9a197ab to
90d89e4
Compare
|
Default page load (file manager): 23 sec Enabled Apps: |
Codecov Report
@@ Coverage Diff @@
## master #4854 +/- ##
============================================
+ Coverage 54.16% 54.16% +<.01%
- Complexity 22276 22278 +2
============================================
Files 1379 1379
Lines 85301 85308 +7
Branches 1322 1322
============================================
+ Hits 46203 46208 +5
- Misses 39098 39100 +2
|
03ba956 to
4424990
Compare
I really don't like such kind of things. If we think this is the way to go: we should do it. If not: then not. But we should definitely not offload this to administrators. That is a bad excuse for developers about being not sure about the outcome of a change and being able to blame the admin then if something breaks. :/ I would go for adding this by default right after we branched of stable12 and are heading to the 13 release. |
Makes a lot of sense. Deferred loading makes a huge difference on FF page loaded, even cached assets are loaded faster it seems and I don't see blank pages when switching apps – which is pretty cool :) |
|
Agreed. Lets do it early for 13! |
4424990 to
698bca2
Compare
|
It's now enabled by default - but can still be disabled with |
698bca2 to
b2519c7
Compare
Kill it. Less options means less code that can break and less permutations of possible configurations. |
|
stable12 is branched of. So I'm now fine with this, once my comment is addressed :) |
b2519c7 to
ba10d7b
Compare
|
Done! |
MorrisJobke
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works here 👍 (even in IE and Edge ;))
|
Ignore CI - the tests failures are unrelated. |
* Create generalized function for emmitting <script defer src=""> tags to templates * Remove type attribute from inline_js * Add defer attribute to external <script> tags Signed-off-by: Michael Letzgus <michaelletzgus@users.noreply.github.com>
ba10d7b to
fb9f13d
Compare
|
Didn't dig into this very far yet but I tested this patch in my NC v12.0.3 instance where it seemed to break OnlyOffice integration. I notice NC v13 milestone on this patch and I have not tested against that version to confirm if the issue persists. Browser debug console indicates a "reference error: OCA is not defined" ( across all browsers, including mobile). No error is logged in nextcloud.log. Removed with patch -p1 -R < 4854.patch -- error went away immediately and integration resumed working as expected. That issue aside I saw a very big improvement in the load times. Let me know if you need more info to reproduce integration issue. |
|
Please open a new issue. Thanks. |
|
@ChristophWurst After a little debugging I came to find 100% of my performance issue ( and evidently a javascript issue for jsxc.xmpp... CAPS error and jsxc.xmpp failed to load settings error ) were all resolved by configuring the site to use php-fpm. Hard to believe I overlooked that configuration. Speaking in terms of the compatibility of this fix with NCv12/13 as I posted in my previous message, I havent had a moment to go back and test things out since configuring fpm for the site. I went back through the NCv12 guide and searched for FPM\FCGI to check best practice and all I really found was this:
I cannot speak on behalf of nginx however under apache2 I find this software only performs well using fpm. Testing with a single user connected you would never notice a difference, but when you get 15 or 20 users connected it's a difference of minutes for TTFB just to bring up the login page. eta, that on Ubuntu16.04 / Apache 2.4.29 the FcgidMaxProcesses setting in the apache directives was causinig apache2 to fail startup, so there may have been another underlying issue that I'm not willing to investigate. |
Deferred script loading can not be turnes on/off via config.php:
'deferred_script_loading' => true,