Help with performance debugging

[Bob_Jansen]

With my gun wiki, I have uploaded 152 guns from South Australia and now am noticing a slow response time showing the first gun I click on. Once the first gun has been displayed, subsequent displays work satisfactorily. The issue exists whether loading from a local copy or a server copy (Memorial Guns Australia — © Royal Australian Artillery History Company, 2025). Let the wiki load, then open the South Australian toc entry and click on one of the links.

I have looked at Firefox’s developer tools and it reports a ‘JANK Error’ which according to the description indicates a performance issue of 5 seconds that may be worth investigating. The time of 5 seconds seems about right for the delay in displaying the first gun entry.

I know nothing about TW’s technical internals and so am in the hands of the technical team with this. If you need an editable copy of the wiki, click this link wiki in dropbox

I attach copy of the developer tools window if anyone knows what all this means.

All advice and guidance appreciated.

bobj

[Bob_Jansen]

(post deleted by author)

[Bob_Jansen]

Sorry people, uploaded the wrong screengrabs and do not have access to my computer tonite. Will upload tomorrow. However, the problem area DuckDuckGo identified was a timer in the loading process.

Bobj

[TW_Tones]

Bob, to my knowledge there is not timer applied to a standard empty wiki, have you installed any plugins with a delay or saver timer etc…?

I believe the word jank may refer to Janky, which just means suboptimal. It clearly seems to be when accessing a file:// address which may refer to your local machine, and here I see to a subfolder that is also synced with dropbox. As a result is it accessing an external resource like an image? It seems that a direct to dropbox file reference could add a lay of complexity, such as if a local copy is not present it (the file system) would go to the dropbox server even if only to check its current.

[Edited] I see now that you are relying on Geocities, which could be part of the delay on your first external image.

I found the above link load much quicker than I expected including having an unreliable internet link here.

I see the delay you spoke of but don’t have sufficient access with your UI impediments in place (not yet hacked it) to look more closely eg edit the tiddler, review plugins and search JS.

The link on the tiddler I tried is https://cultconv.neocities.org/ArtilleryRegister/ArtilleryRegisterPilot20260206_SA#MGA0612644_LandingPage but the address bar shows only https://cultconv.neocities.org/ArtilleryRegister/ArtilleryRegisterPilot20260206_SA

There is a message There are no links to this record but I presume this is no backlinks internally.

[Bob_Jansen]

@TW_Tones , the issue is not related to neocities nor Dropbox because the delay is present when loading from local file store as well as from the server. My only thought after pondering the issue for some hours is the mapping plugin and tomorrow, my first task will be to remove that plugin. I have been concerned about this plugin in any case as i wonder what its performance would be wit many tiddlers having the geomap tag and this being scanned to extract longitude and latitude information. I have been arguing for the use of a static map for the gun’s location as they are not very ‘active’

Also, the issue is not the initial load of the wiki but the rendering of the first gun tiddler from the South Australian set. After the first, subsequent renderings of other gun tiddlers is ok.

Bobj

[Xyvir]

One thing to lookout for is overuse of regex matching in a plugin.

While extending the TiddlyStudy edition I had to remove it’s ‘Freelink’ footer backlink pill detection as it was actually running regex matching every Tiddler Title against every Tiddler Body on every keystroke.

Using the native Tiddlywiki Filters is much more performant as my understand is it runs of a small cache/index instead of just manually matching all tiddlers all the time.

-Xyvir