https://tidgi.fun , created by @dongrentianyu on tiddly-gittly/TidGi-Official-Website
With nodejs lazy-loading, so some content may wait a while to load from my mini server.
Thanks, let me see which plugin causes this…
@saqimtiaz I can’t reproduce on my side, can you open developer tool - console to see which plugin cause error?
I’m getting an error also on my browser (Chrome for macOS). Console shows lots of error sequences like this:
Uncaught DOMException: Failed to execute 'insertBefore' on 'Node': The node before which the new node is to be inserted is not a child of this node.
at ImageWidget.render ($:/core/modules/widgets/image.js:131:9)
at Widget.refreshSelf ($:/core/modules/widgets/widget.js:695:7)
at ImageWidget.refresh ($:/core/modules/widgets/image.js:155:8)
at Widget.refreshChildren ($:/core/modules/widgets/widget.js:705:27)
at ElementWidget.refresh ($:/core/modules/widgets/element.js:103:14)
at Widget.refreshChildren ($:/core/modules/widgets/widget.js:705:27)
at ElementWidget.refresh ($:/core/modules/widgets/element.js:103:14)
at Widget.refreshChildren ($:/core/modules/widgets/widget.js:705:27)
at TranscludeWidget.refresh ($:/core/modules/widgets/transclude.js:431:15)
at Widget.refreshChildren ($:/core/modules/widgets/widget.js:705:27)
Sadly I can’t reproduce it on Windows or Mac. But I can add some check to the core. This maybe a but with lazy-loading + image.
I don’t know, maybe this only happened when an image fails loading.
I have to switch to use lazy-image insteade of lazy-all until we fix this in the core.
hmmm, It needed about 3 seconds to show the splash-screen. It did not open within 20seconds?! Luckily I did wait 40seconds, which I never would for a normal web page. It did not stop loading images up to 1min 20seconds 
I did have a look at main image. It’s a png with 2694x1924 px and a size of ~700kByte. IMO the resolution is way out of a screen size, what most users can natively watch on their screens.
So IMO an initial size of 1920x1080 should be good enough for most users.
With a bit of tweaking I got the image down to 82kByte AVIF format
- I scaled it down to 1520x1080 in PNG format
- IMO the initial size should be defined by your screenshot already, which will avoid quality loss caused by the resizing algorithm.
- Converted it to AVIF with Quality: 40 and Effort: 6 to 82kByte
- using: Squoosh editor, which offers a nice UI to compare between old and new
- Even WebP with Quality: 80 and Effort: 4 got ~120kByte
IMO it should be easier to handle, even if transferred as a JSON. Images should be served with _canonical_uri from their own “files” directory from the proxy server and server side compression switched off.
Images usually cannot be compressed anymore. So compressing them server side will only waste performance.
There have been at least 2 other PNGs with almost 2MByte in size, which IMO can easily be scaled down.
It seems you do not use a proxy server, because caching is switched off. So visiting the site will not use the browser cache for images and the wiki itself.
Just some thoughts.
I think text come out fast, and you are waiting for images to loaded? Thanks for your suggestion, i will compress the images on the repo. Previously they were used in the github readme, where github has a larger bandwidth.
I think if text also load so slow, I have to take a look at what it is wasting time for…
I’m using tidgi to start a nodejs wiki directly, so I would expect tiddlywiki can provide etag based caching (seem to already exist?) I will check it out.
2 Likes