Troubleshooting very slow behavior for *some* web visitors

#1

I’m not sure where to start troubleshooting, because I can’t reproduce this problem on my own computers. But I’ve now had multiple students who report very laggy behavior (like typing in a search box and painfully waiting several seconds for letters to appear, or even a failure of the site to render at all within reasonable interval). This is in connection with tiddlyhost sites (two different ones, both 5.3.1 external-core sites) that I’ve set up as study resources.

Both of these students reported having generally “slow” older computers. But they’re getting a kind of deal-breaker molasses experience with my site that is worse than the ordinary slowness they’re used to.

With one of these students, I was able to briefly commandeer their laptop, and confirm that the sluggishness was much worse on Safari than on Chrome. (Behavior over Chrome was still not as responsive as I’d like, though.)

Question: Is there anything about either 5.3.1, OR anything about serving up external-core wikis, that might exacerbate responsiveness problems? (I’ve been sharing tiddlywiki stuff with students for years, and have never had this kind of report before this semester, and it’s odd that I’m now getting this feedback about two sites with very different content…)

I’m happy to ask these students to try again once I’ve made some changes. Alas, they’re not very tech-savvy students, so I don’t feel comfortable asking them to check repeatedly and to swap browsers, etc., until I have a good hypothesis and a strategy for fixing the problem.

Any ideas? (One of the sites is on a privately shared tiddlyhost account, but the other is a public site I’ve shared here before, so if anyone is inclined to load it and poke around, here’s a link: https://ethicsatwes.tiddlyhost.com )

-Springer

#2

I had no speed issues with the ethicsatwes site. Unrelated, tiddler process for diagram@1095 has a missing image: [img[draft|http://d.pr/i/p69G+]]

#3

Impressive site, you linked to!
I had no problems reading or searching on your site. Using a 12 year old laptop bought second hand 4 years ago, after the previous owner had dropped it on the floor. Tried your site in Chromium and Firefox - no difference and no problem. I am using Linux and believe this is why this old laptop behaves so well for my daily use.

#4

Heh, that site has so many back-room tiddlers that are just hanging out… process for diagram@1095 was created in… 2013! :wink:

I did go through and remove “heavy” old tiddlers (using some filter shared here by someone to check for large tiddlers), but I haven’t bothered with some of the lint between the cushions. :slight_smile:

Glad it was responsive for you!

#5

@Springer I wonder if browser extensions could be interfering and causing slowdowns.

My trusty old Macbook Air from 2011 has no problems with the site in Chrome, a bit slower in Safari but still reasonable.

#6

9.3 Megs is getting close to the edge on some devices.

Are there other apps open? Other tabs open?

As an alternative, I was able to bring it up on my aging phone. Took a minute to load, which is a long time. Seemed to navigate OK, but apparently when you bring it up on a small screen you can’t access the sidebar, so I wasn’t able to try searching. Anyway, it’s possible your students have better phones than laptops these days.

#7

@Springer As @Mark_S suggests I expect the main place for performance issue to arise may be that which all computers could face, Browser Memory (too many tabs and windows), Total System Memory (thus less for browser), insufficient free local ssd/hdd storage (disk swapping).

  • Perhaps see if at the same time your wiki is performing poorly, if at the same time, a smaller or empty wikis is also performing poorly. It will suggest if you need to focus on the specific wiki or the capacity of the machine.

Of course there is an art and science in making larger tiddlywikis higher performance, but a quick test includes with the sidebar closed and only a few tiddlers open.

  • My expierence is a wiki slows down the more you ask it to display and maintain upto date on the screen at the one time. Reduce this and if it performs better then the wiki design can help, if not it may be total size (unlikely - keep in mind 10mb is getting smaller every day :nerd_face: ) or the browser/machine it is running on.
#8

Try using Performance tab in browser developer tools. Like in

(BTW, it was caused by kin-filter and tw-locator, so I’m using in-tagtree-of filter from CPL now)

1 Like
#9

I did not have any problems with my laptop, which runs ubuntu 22.04 with FireFox. After the initial download delay, everything worked fine.

As Saq wrote. I would have a closer look, at browser AddOns, that may be installed.

#10

I played with the public site and I cannot see any noticeable lag. The searchbox works. Closing and opening tiddlers are reasonably fast.

By the way I may recommend to put less material in landing page (I mean the main page has many tiddlers, some of them has to extract data from other tiddlers). A single tiddler story river may be helpful here.

I noted, the site has rather small numbers of tiddlers:

Number of tiddlers 1356
Number of tags 325
Number of system tiddlers 753
Number of shadow tiddlers 3099
Number of overridden shadow tiddlers 92

So the site is not a heavy one at all.

1 Like
#11

I just went to the site as given, it took a long time to load with no splashscreen in use.

While I was waiting I noticed a message as the bottom left of the chrome browser, on the left and later on the right a message I could not capture but from memory read Waiting for fonts.googleapis.com...

Without hacking the site too much, to look behind the scenes, this is all I can see that may be contributing to issues, however it works fine for me.

Nice resource.

  • I am preparing a talk for my Philosophy group in a few weeks, I want to look into the idea of immortality. We are not professionals.
  • I am looking for speakers to present on a philosophical subject, however in the +11 UTC time zone.
#12

Not in tiddler count. But 9.3mb download. I find ~10mb the cut-off where you have performance problems on poorer performing devices.

1 Like
#13

Thanks for this!

Hm… It’s very plausible that Chrome would handshake more efficiently with google fonts than Safari does! I do have some strong reasons to prefer the fonts I use, but I’ll try serving up a variant without any google fonts, and see whether these students have a better experience.

Thanks, Mark. I’ll also poke around for more unnecessarily heavy tiddlers.

I’ve also been slowly converting some images to .webp format, and that may help cut down the required bandwidth.

I think I also at some point was using some <$reveal> widgets, and recall someone pointing out that they create DOM-related burdens (not sure I’m explaining it well). I removed at least some, but may still have some in there. So I’ll do a check for those as well.

Thanks, all, for devoting some attention to helping me brainstorm on things to experiment with.

-Springer

#14

An old tip I forgot. When you’re having trouble typing, you can change the value of tiddler:

$:/config/Drafts/TypingTimeout

to something higher. You’d have to make this setting available to students that need it.

#15

Alas, some of the students in question (including intro students with whom I rarely get to interact one-on-one) need “plug-and-play” access, and have little motivation for any extra fiddling. But I’m grateful to know one more backstage setting that might make a difference!

#16

If the students aren’t into fiddling, why is it locked down like Fort Knox? Seems like more than one level of read-only is being applied. But I digress.

You could always make the setting a “TurboBoost” button. Everyone likes Turbo Boost.

It’s not a one-to-one relationship, but in my experience the more plugins you have, the more performance problems you’re likely to have. Because many of those plugins are called during rendering, even if their services aren’t required at the moment. I lost count around 40 plugins. I think some of them are disabled, so maybe they’re not necessary?

Edit: Maybe for the student release you could disable things like “relink”, if you’re not doing so already.

#17

pinboard is from @Mohammad: Pinboard 1.1.1 — create sticky notice board

I’ve done some cleaning-up, but of course trimming back on plugins that are no longer central is a perennial task (for a wiki that’s as lived-in as this one).

I think you missed the word “some” in my post. SOME students are students I can’t ask to fiddle with settings and browser configurations. :slight_smile: OTHER students may be curious folks who would dig into the back rooms much more than I’d like. (Of course, any “locking down” is a matter of relative deterrence, so I also refrain from having anything at the site that would terribly upsetting if published openly. Most of my read-only interventions are actually about removing distractions related to editing, so that the GUI – for all but myself when I’m logged in over tiddlyhost – is streamlined for browsing.)

:slight_smile:

#18

You’re probably replying from email, so I’ll repeat the edited part:

Edit: Maybe for the student release you could disable things like “relink”, if you’re not doing so already.

It’s a really amazing site, BTW.

2 Likes
#19

The reveal-widget only creates invisible DOM elements if you set retain: yes, which is needed if you want to animate:yes popups.

So If animate is set to yes but retain is not there or set to no there should be no extra hidden DOM elements, while the popup is closed.

1 Like
#20

You may be careful here. … The relink-plugin adds some filter operators, which are handy to get extra info about back-references.

If you use them you cannot remove relink without side effects.