Slow wiki loading time

[docentYT]

I would like to report that the pages on the osm wiki are loading slowly. This is not a fault on my side as other pages are running faster.

[Firefishy]

Any particular pages? I will look into it.

[docentYT]

Any particular pages?

No. I've checked and it happens on various pages.

[matkoniecz]

I observed in general that OSM Wiki is really slow compared to other websites that I am using. It appears to be not limited to specific pages, or pages with multiple images (#466) or targeting specific pages.

Just overall slowness.

I considered making some identical test pages on OSM Wiki and in userspace of Wikipedia and running some performance-measuring script to get hard data over "oh dear, it is sooooo slooooow" but have not done it so far.

Though I reported some cases where OSM Wiki got from "irritatingly slow" to "unusuably slow" (#640 #627 for example)

I can confirm that "OSM Wiki pages are slowly loading" is a common complaint. To the point that someone made https://lgms.nl/p/osm/cached-wiki/?page=Main_Page

[tomhughes]

That's mostly because our wiki is full of insane pages that are orders of magnitude outside mediawiki's basic design parameters in terms of the template transclusions, number of images, etc.

[matkoniecz]

I run into it also on pages with no clear insanity and in search. Is there some way to measure insanity level of a given page? Especially if that can be compared across wikis?

Is there a way to profile resource use?

Wikipedia pages often also appear to be going extremely far in terms of template use.

[Firefishy]

I have enabled QuickInstantCommons which helps relieve some of the problems with https://www.mediawiki.org/wiki/InstantCommons

[1ec5]

As I mentioned in https://github.com/openstreetmap/operations/issues/466#issuecomment-1204657000, QuickInstantCommons seems to have resulted in a night-and-day difference in page load times for the pages with the heaviest Commons usage. However, I’ve personally experienced and received feedback about plenty of non-Commons-heavy pages also taking longer to load than expected – not necessarily an inordinate amount of time, but sort of in the range of “a thousand papercuts” for someone who browses the wiki a lot.

The static page content actually loads reasonably fast. Template transclusion is generally not a problem after some spring cleaning in 2019. But anything relying on JavaScript takes much longer, even on special pages that don’t contain any page content. For example, the Special:Search landing page typically fires the DOMContentLoaded event within 2 seconds, but the load event doesn’t fire for another 3–6 seconds. (Everything between the two events is waiting for the JavaScript that gets loaded in DOMContentLoaded hooks.) By comparison, on Wikipedia, DOMContentLoaded fires well within a second and load fires within 1–2 seconds of that.

From cursory looks at my browser’s Web inspector, ResourceLoader dominates the profile. ResourceLoader is what loads all the site JavaScript, such as the toolbar for the legacy edit page or the expand/collapse buttons in various navigation boxes. On Special:Search, you can bonk the All and None buttons all you want but they do nothing until the page finishes loading. The one exception is integration with taginfo’s taglists feature. taglists.js is loaded directly from taginfo.openstreetmap.org using jQuery, which seems suboptimal. The server responds quickly, but setting up the secure connection to this server adds some overhead, and there’s no opportunity for ResourceLoader to cache or minify the response.

Another thing I’ve noticed is that ResourceLoader doesn’t seem to cache as aggressively as I’m accustomed to. As an administrator on several Wikimedia wikis, I’ll make changes to a gadget or site stylesheet but then have to append ?debug=true to see my changes, and it can take an hour of hard-refreshing to see the changes without that flag. But on the OSM Wiki, changes to gadgets and site stylesheets take effect immediately with just a refresh, without needing to enable debug mode. I don’t know if that’s because of ResourceLoader itself or some other kind of caching that should be taking place.

[Firefishy]

I think wiki is back to full performance after: https://github.com/openstreetmap/chef/commit/abe750320d58b744400f97161741e4ab26711034

[Firefishy]

Oh and enabling QuickInstantCommons

[lgommans]

I can confirm that "OSM Wiki pages are slowly loading" is a common complaint. To the point that someone made https://lgms.nl/p/osm/cached-wiki/?page=Main_Page

I only just saw that this was mentioned here, that 'someone' was me :wave:   Found this thread via the wiki homepage news section, which links to 'speed improvements' near the top of that section, which links here.

I'm a bit late to the party, but will say that the official wiki's speed has been better for a long time now! Thanks for all the efforts :smiley:

There is not really a need for my proxy anymore and I rarely use it now, not sure if anyone else still does. It is still a bit faster by virtue of being a super dumb system, but not enough for a raison d'être. The wiki html changed at some point and that broke injecting the notice that it's a cached copy and how old the copy is, I could fix it but...

Wondering whether to take the proxy down, or to make it 301/302 to the wiki. At the time that I made it, the official wiki was also down on occasion. That hasn't happened in a while anymore, but I'm considering leaving it online for that because it doesn't cost anything either. A downside is that the pages will be old because there's no active fetching (only lazy reloading the copy, if it's old enough, after someone's visit). Do you think it makes sense to keep this as a backup?

_{For the record, a better link is not to the main page but just to the directory: https://lgms.nl/p/osm/cached-wiki/. That has more info and a source code link as well as linking to the main page.}