An example from me: I can see the button and notes at https://commons.wikimedia.org/wiki/File:Vegetation_at_Honningsvag_September_2016.jpg but not at https://commons.wikimedia.org/wiki/File:SR_Technics_hangar_at_Zurich_International_Airport.jpg although an image note exists there (both the button as well as the note are not displayed).

I also was able to upload a different, smaller JPEG file (5 MB) with the Upload Wizard right now; but normally, 18 MB shouldn't be an unreasonable size for the wizard that is supposed to handle much larger files easily...

I've now managed to upload that image quickly using the old ("classic") form at https://commons.wikimedia.org/wiki/Commons:Upload - it's File:Amanz Gressly plaque Laufen.jpg -, after the Upload Wizard still responded with a timeout ("The server did not respond within the expected time") when I tried it again, so it does look Upload Wizard specific to me, or specific to the way the Wizard is using for uploads.

@JMinor From the popularity of a feature doesn't automatically follow that it is a desirable feature. For example, if we had sensational, tabloid-style headlines in the app, these surely would generate many clicks - but Wikipedia isn't about clickbaiting. Of course users who wish to "browse and explore" should be able to do so, but we have many better starting points for this than raw popularity of articles IMHO. For example the manually curated "did you know?" section which has the advantage of bringing lesser known topics into the spotlight, which maybe broadens the knowledge of readers more than reading about topics that are already popular and often searched for. As I see it, if a topic is already in the news or popular for another reason, we don't need to point readers additionally to it, "hey, this topic is popular!"-style.

Seems to be better. Solved by the rebooting mentioned by @ema ? I don't experience that slowness anymore.

I honestly do not think that the issue is connected to my computer, my browser or my internet connection, as the slowness is Wikipedia-specific, other sites load fine, and every speed and connectivity test gives good results. The traceroute I posted above also looks fine, I'd say? It's a "gut feeling", but as a longtime Wikipedia user, to me the symptoms really "feel" like they're on the Wikipedia side. For what it's worth, I'm in Switzerland.

The slowness persists today. Still similar experience.

Loading the same page twice in a row: Yes, there are often differences. It's an overall slow experience, but pages often load faster when loading a second time (not always). Everything seems to be faster now, but not blindingly fast. Safemode: I'm now using https://de.wikipedia.org/wiki/Arbeitermuseum for testing and it loads consistently with loading times between 250 and 300 ms, with and without safemode, no difference. I'm not on a Linux or Mac device, but Traceroute is also available under windows ("tracert" command), this is the result:

Some random examples: https://de.wikipedia.org/wiki/Fu%C3%9Fball-Weltmeisterschaft_2022 right now had a loading time of 152158 ms and didn't load completely. The main text of the article is there, but the Wikipedia logo and navigation to the left are missing. The short article https://de.wikipedia.org/wiki/Alkuin_Stillhart did load in 438 ms, which also seems to be pretty slow to me. Some articles did load without the style sheets.

For what it's worth, I can confirm that there are currently often slow loading times in German-language Wikipedia (using Firefox 67.0.3 and previously 67.0.2). But it's intermittent. And not for other websites, but specifically Wikipedia.

In T221892#5138827, @matmarex wrote:

I suspect I broke this by fixing T219457 – if you had new wikitext editor enabled, such links would open the visual editor's HTML in the wikitext editor, which was crazy.

If the visual editor is expected to be available in the project namespace ("Wikipedia"), perhaps it would be better to just enable it there? It is enabled on other wikis, e.g. pl.wp.