Sorry I should have said “skinny” version, not skeleton version.
Lazy Load Mechanism
The permalink is to a tiddler in the full wiki.
<flux.wvwlogs.com> is an example of one of the wikis in lazy-all mode. Patience required, the tiddlers will load…
and a permalink as well: https://flux.wvwlogs.com/#20221202-WvW-Log-Review
Ah Ha,
Caveat: I do not use skinny tiddlers, but have a theoretical understanding.
On a related note we recently discussed;
Others may help more if you detail your host server details.
[edited] Post Script: If the tiddler you display is a compound tiddler drawing on many other tiddlers to generate its content, it may need to load all related skinny tiddlers and again the value of skinny tiddlers is less. Either,
It seems there is something loaded as a raw-markup library. I did open the browser dev-tools and this library did throw errors.
Did you try it without this library. Especially this comment would worry me. If a library has this type of comment I’d not use it.
// sort is super fast, even with huge tables, so that is probably not the issue
// Not solved with documentFragment, same issue... :(
// My guess is that it is simply too much to hold in memory, since
// it freezes even before sortable is called if the table is too big in index.html
That would be the sortable.js I added based on a thread here. It did not impacted stand alone wikis served on tiddlyhost. I’ll remove it and see how it performs.
The wiki is currently 70Mbs uncompressed and would be larger if not pruned. As data ages it becomes less relevant until a new patch releases, then everyone wants to compare prior periods to current. I thought switching to a nodejs version with lazy-all would provide ability to maintain all the data in separate tiddlers and push only when needed, thus reducing the bandwidth on each serve.
This would be due to the credentials required, the server restricts you to reader only.
I think going with skinny tiddlers for a wiki like that is the right way to go. …
I thin I did spot something. …
The permalink you gave us is loaded immediately, because it points to a skinny tiddler. When TW sees it, it knows to show the text content. … So it loads the body and shows it. Flux Capacity — WVW Log Review
The Network dev-tools say it’s about 400 kByte . That’s reasonably fast (for me). …
When I click a filter on that tiddler content is loaded on demand, as expected eg: lots of icons.
then ---------------
I close this tiddler. It seems the background shows an overview of the last 8 days. … Which then seems to request all that info. … with the next 1 minute default poll … that seems to be OK
BUT ---------------
if I open a new tiddler from the sidebar it opens the skinny tiddler … and also waits until the next 1 minute tick comes up.
So worst case users have to wait 1 minute … Best case 1 second … It depends, when the timeout is over.
So the question is: Do you “block” the request for the tiddler content by accident or by intention.
My guess. It’s an accident … may be a timeout setting somewhere.
I don’t use lazy loading, so I don’t know all the options that are possible.
So “lazy loading users” are requested here.
-mario
by accident, I’m doing good to get the nodejs version up and serving in lazy-all mode. Learning as I go.
This is a function of the Mono theme tweaks “Use timeline grid when story river is empty (grid preview of 10 recent dates for modified tiddlers)”
I’ll turn that off and see if it changes anything.
I wouldn’t turn it off. … Most of the time, when usrers close everything, they are searching in the sidebar. So the attention is at the sidebar. So imo it’s good, if the wiki would load the last 10 results. …
I actually did like that feature. …
I think it’s not a performance problem. At least not with my internet connection. IMO it’s a timing problem. So we need to find out, what causes the delay if a still skinny-tiddler is selected from the sidebar.
I turned off the mono tweak timeline grid and things are working much faster
Well, maybe i spoke to soon. when i tested on laptop i got the same delay problem.
Yea, I was testing it too and also made an unlucky hit. It needed about 30 seconds. So it still depends on the timeout. …
I did debug the source code and there seems to be a problem. … But I’m not 100% sure, because I don’t know that code very well. … I’ll create a GitHub issue. … I’ll post a link when that’s done.
The issue is at: [BUG] Lazy-loading seems to wait for the 1 minute timeout when tiddler is shown in story-river · Issue #7138 · Jermolene/TiddlyWiki5 · GitHub
So we’ll need to wait a bit. @john.edw_gmail.com … It would be good if you wouldn’t mess with the system at the moment. I think as it is it’s OK to test it.
Leaving it be, I’ll work on another subdomain.
I knew I could not save, I just thought I could test it in memory.
Perhaps experiment with the following;
Here is the package which still seems to work in the latest version. Install then click the camera Icon snapshot.json (6.2 KB) no reload needed.
It may prove of use.
@john.edw_gmail.com … Have a look at [BUG] Lazy-loading seems to wait for the 1 minute timeout when tiddler is shown in story-river · Issue #7138 · Jermolene/TiddlyWiki5 · GitHub
It seems Jeremy has fixed the problem with that commit. You’d need to run your server with the latest master-branch to test this. … If your server, with the links you provided, is a production server, you should first test it on a test-system.
If there are some more questions, just let us know. May be GitHub [BUG] Lazy-loading seems to wait for the 1 minute timeout when tiddler is shown in story-river · Issue #7138 · Jermolene/TiddlyWiki5 · GitHub may be a better place to discuss technical details.
Thanks @pmario! I have a stupid question, on how to proceed. If I installed globally via npm package, can i just reinstall direct from the master without messing up future npm package installs?
npm install https://github.com/Jermolene/TiddlyWiki5.git
Thankfully, I have been keeping the tiddlyhost version and an offline version since you said to leave the other configuration alone. I have added new tiddlers for summaries and echarts but they are backed up.
You can use/modify your online version again. We don’t need it anymore for testing.
I personally use the development version as my global version.
I do use IIS with a Node.js setup but it uses a local install. So I can’t mess it up accidentally.
I think it would be the best way to create a new server configuration with the existing installation. Then cd into the new directory and install TW from GitHub locally into that dir. As you suggested. Then you should be able to start from that dir with the latest master. … For testing the fix.
Upgraded by installing directly from the master branch. Initial testing has all wiki’s working as expected, no more delays in loading under lazy-all start up.
Thank you!
Images are also loading much faster with the fix. I can avoid my attempts at writing a new core-save.
Excellent, thank you.