Serendipity Forums

hello,

valid (x)html-code is one of the famous things of s9y. But, testing a s9y-site, someone says to me that there are many error popups viewing the blog. no html-errors, but javascript:

I testet it with firefox and a look to the error console:
any idea for error solving?

Hi!

This plugin depends on serendipity_event_jquery. Did you remove that plugin maybe? It does not execute on your page.

Regards,
Garvin

Is the issue solved? I'd be interested in what caused this. Did you uninstall the jquery-Plugin because it seemed unnecessary? Didn't it install itself? Knowing that, maybe we/I could improve the system.
sincerely

PS: @garvin: Maybe it would help if it wasn't possible to remove the jQuery-Plugin at all if there is another one depending on it.

garvinhicking wrote:Hi!

This plugin depends on serendipity_event_jquery. Did you remove that plugin maybe? It does not execute on your page.

Indeed, I do not installed it - did I have overread some information to install it for the comment-plugin?

onli wrote:Is the issue solved?

partly:
and, more, extrem more important:

I notice that the comment-plugin doubles, sometime triples my page-load-time!
http://blog.stephan.manske-net.de is a slow site anyway. But with the plugin it is horrible!

Another site, very fast IMO:

http://www.sankt-joseph-siemensstadt.de/ (no plugin in the moment)

from 2 sec to 5 sec on statistical average

Indeed, I do not installed it - did I have overread some information to install it for the comment-plugin?

The jQuery-plugin should have installed itself automatically at the installation of the livecomment-plugin. Weird. You did use spartacus?

Code: Select all

Fehler: lcnewbase is not defined
Quelldatei: http://blog.stephan.manske-net.de/index.php?/plugin/requestMarkups.js
Zeile: 6

I noticed this at my tests, but it seemed like a harmless timing-error happen only occasionally, and I couldn't fix it. I see the specific function works anyway also on your site. I checked the logic once again, don't see an error. This should be harmless (but it's ugly).
edit: Think I got that one. lcnewbase is parsed after the javascript-files, so the first time it could be undefined. That should be easy to fix.

The performance-issues are really severe, your site is slow. Sure, the javascript-files are a few kb big, but they should load only once and remain in the cache thereafter. This shouldn't be the problem. Maybe it's the ajax-call, being executed every time a page is loaded. In fact, I thought that because it is executed parallel or even after the delivering of the page, it shouldn't have any noticeable impact on the page load time. But it could make a slow server slower and such behavior wouldn't be noticeable at my test-environment. While writing this I check the code from this perspective, the ajax-call is even called twice if the markup-buttons are enabled...

Let's try it that way: Could you please check if you gain a speed-improvement when disabling the markup-buttons of the editor? If it helps, clearly the Ajax-call is responsible for a part of the issues. Then I'd try to minimize the calls or offer an alternative.
sincerely

onli wrote:

Indeed, I do not installed it - did I have overread some information to install it for the comment-plugin?

The jQuery-plugin should have installed itself automatically at the installation of the livecomment-plugin. Weird. You did use spartacus?

yes. and now try to reinstall, jquery comes automaticaly. IIRC there was for some times another js-libs-plugin, and I tested both and deinstalled both, because I do not know the comment-dependency

onli wrote: Let's try it that way: Could you please check if you gain a speed-improvement when disabling the markup-buttons of the editor? If it helps, clearly the Ajax-call is responsible for a part of the issues. Then I'd try to minimize the calls or offer an alternative.
sincerely

my slow blog time fluctuates in the moment so I could not measure it now.

but on http://www.sankt-joseph-siemensstadt.de ... osovo.html

with buttons and elastic comment field: 9 sec
only buttons: 7 sec
no buttons, no elastic: 6 or 7 sec
no plugin: 2 sec(!)

to test it: now the config is "no buttons, no elastic"
to simulate "no plugin" disable javascript

Well, the dependency-system seems to need some improvements.

Regarding the performance, the difference is not that big when visiting your page right now. But the issues are existent, that's not solved nicely. I'll offer an option to submit the variables inline, thus deactivate the ajax-call, this should speed up the whole thing.
Because I dislike this method (that's why I used the ajax-call in the first place) I'll try to cache the call - tried it already with no success, but will continue on that. If anyone got experience with that, any help is appreciated.

But: Elastic really should make no noticeable difference. That's only one really small javascript-file loaded and executed. If that really slows down your site, that's certainly not caused server-side.

there is no difference between with and without javascript on your test of my site?

No, there is a difference. It was just not so clearly separated in 2 and 6 seconds.
sincerely

Think I made some progress.
There is now the "inline"-option to use inline-JavaScript for the parameters, deactivating the ajax-call. This should give the most performance. If the new option is not used it should anyway be faster, because the ajax-call is no longer executed twice and the JavaScript stops faster if no commentform is existent, like on the startpage. Also I could eliminate an event-hook which is probably always a good thing to do, regarding the performance.

Please give feedback if it helps, if not, there are still one or two improvements possible.
sincerely

ok ...

jquery-method, no buttons, no elastic field, inline: 6 sec
no preview: 4 sec
deinstalled plugin or disabled javascript: 2 sec

tested page: http://www.sankt-joseph-siemensstadt.de ... -2009.html
test-browser: opera which shows to me the load-time in the status-bar

all things: jquery, buttons, elastic - 9 sec, no difference for inline/no inline

status now: jquery-method, no buttons, no elastic field, inline

At the moment my browser (ff3) needs 3-3.5 seconds for normal load of http://www.sankt-joseph-siemensstadt.de ... -2009.html and 4 for a total refresh, with javascript. Without 1.2. The slowdown is big, but 3-4 seconds are almost acceptable. But hopefully we can improve speed a bit more.

Please try the attached versions of the plugins. The jQuery-Plugin now fetches the always up to date, minimized and gzipped version of jquery via the Google-API. This even resulted in a little improvement on my local installation.
Some more changes have been made to the livecomment-plugin. The size of the javascript-files got reduced, also the amount of http-requests. The scripts are positioned in the footer, which should decrease the load-time of the remaining page-elements. Code itself should get executed faster, too. Noticeable difference between having one option enabled or all of them should be minimal.

Note that the slowdown is in all likelihood not caused by some obscure javascript-operations slowing the client's browser, cause this would also be noticeable in the test-installation. So it is caused by the combination with the server. That's why I tried to minimize the file-size. I don't think that this is cpu-related, cause than the ajax-call would slow things down furthermore, on the other hand indicates the difference between the 4 seconds now and the reported 6 seconds that server-load plays a role. Anyway, it could help if you configure an expire-header to cache your javascript-files.
sincerely

Hi!

I think one of the reasons for the performance drop is the use of /plugin/blabla.js wrapper. This makes s9y to initiate the whole framework, with all login routines etc instead of just outputting a .js file. So in that case, allowing a straight HTTP call to where the .js file is stored, or emitting it inline, would speed it up...

HTH,
Garvin

Thanks Garvin, that's something I wasn't aware of. Am I right if I think that there is no simple possibility to compute the url-path to the js-file dynamically, so it also works if it's not located in the default /plugins/serendipity_event_livecomment? Think a config-option to specify the path should be the best option.

Hi!

Yeah, that's sadly true, one cannot easily "guess" or compute where the actual HTTP url is. That's why most plugins have a "HTTP path to file XXX" config option...

Regards,
Garvin