Glancing at User_talk:EEng, I'll note that it's currently 7.9MB of HTML (725kB gzipped over the wire), containing 300 separate sections, with 2,633 comments between them. This isn't to say that there might not be ways to improve this, but we're very much starting from a place where it's going to be a painful page to view no matter what we do.

For parser-cache reasons it's a pain to work out what the actual rendering load of the added DT HTML is, but you can quite easily compare the added load of initializing DT by seeing the subjective experience of visiting https://en.wikipedia.org/wiki/User_talk:EEng?dtenable=0 vs https://en.wikipedia.org/wiki/User_talk:EEng?dtenable=1

I've done a quick Excimer run on a post-purge legacy parse (since parts of DT are cached on these parses) and on a Parsoid parse (where they're not yet).

Legacy: https://performance.wikimedia.org/excimer/profile/02a21b7f8b0ba8d4

• addDiscussionTools takes 1.37 seconds. This would normally be cached as part of the main parse in the legacy parser (but would be part of the page rendering time after edit)
• onOutputPageBeforeHtml hook takes 2.93 seconds. This is not cached.

Parsoid: https://performance.wikimedia.org/excimer/profile/3bd6fbb591c0efe4 - note that this only applies for people who have opted in for Parsoid read views on enwiki.

• addDiscussionTools takes 1.36 seconds. This is currently not cached on enwiki.
• onOutputPageBeforeHtml hook takes 3.07 seconds. This is not cached.

We may want to discuss if there's a way to add more things to the (caching-handling-in-progress) OutputTransform pipeline from onOutputPageBeforeHtml; that would help when displaying pages that are in the cache. It would not help with post-edit performance when the page is not cached yet (and for which the mere parsing time will also play a (significant) role).

Adding @EEng .

"don't worry about performance" is not a carte blanche to exploit the resources made available nor a directive that WMF has to fix a problem.

A 4th option is that we simply add a new requirement for pages in this category and they simply stop rendering. That's what limits are for; to set the boundary of what is acceptable from a technical perspective. If we define that talk pages should be parseable/renderable within 2 seconds, then this problem is also solved.

Sorry for the delay, I had quite a bit of government paperwork to do lately. I am testing all relevant configurations on Chromium and Firefox.

My computer is running on Intel i5-3550, GT 640 GPU, 8 GB DDR3 @ 1800 MHz RAM. So you can guess my computer is pretty old, about 13-14 years old. It was not particularly often used until like a year or two ago. I don't know what CPU is used in the CPU time usage metric mentioned in the OP, but it's clearly more powerful than what I have.

Chromium 144, Firefox 147 on Windows 10. The two browsers were used to show that it is not a browser engine issue.

I am not running any programs other than the Task Manager, Notepad++, one tab of Chromium to write this report on and the On-screen Keyboard, but even with 20-30 tabs and some with editing turned on, I was not running of CPU or RAM capacity in my normal usage, at least not according to the Task Manager. Even when loading huge pages, I don't see any sign suggesting that the RAM, GPU or CPU are somehow a bottleneck.

I tested both browsers on the current revision of User talk:Tryptofish, which is 2875 KB HTML size and 864 KB wikitext size, so far from EEng's 7.9MB of HTML but still butchering my computer. The testing consisted of loading the page, scrolling it for a little, trying to highlight text, interacting with links on the talk page, as well as opening the reply box and trying to type something, if that was possible at all. The first run is not cached, the second run is running cached.

Firefox while logged out:

https://profiler.firefox.com/from-browser/calltree/?globalTrackOrder=ef0d9ca6b2187534&hiddenGlobalTracks=1w8bc&hiddenLocalTracksByPid=7308-0w2~15820-0~1572-0~6588-0~15104-0~5744-0~7920-0~13692-0~3524-0~2272-0~9844-023~15256-0~7672-01&implementation=js&thread=l&v=13 - first run
https://profiler.firefox.com/from-browser/calltree/?globalTrackOrder=iwl0hdgcfb43a592e16w8&hiddenGlobalTracks=1wbdwg&hiddenLocalTracksByPid=7308-0w2~7920-0~7672-0~12440-01~10508-01~10312-0~6588-0~5744-0~15104-0~14792-0~11700-0~2272-0~9844-023~13692-0~15256-0~192-01~14728-01~16088-01&implementation=js&thread=o&v=13 - cached run

Chromium while logged out:

https://va.cat/link/TXpJMk1qUTNOemM9OjpoYXNoOjowLjQ3NTk4NDAwIDE3NzAzODI0Nzk-/ (file-sharing link good for 15 days)

More to come in later posts

Heads up to @Quiddity.

^^ To the above Chromium run, browsers based on Chromium have some local metrics available in performance. Largest Contentful Paint is variously from 1.5 s to 3.2 s on different runs (<2.5 s - good, >4 s - poor). Cumulative Layout Shift had one run of 0.91 and others very close to 0 (<0.1 - good, >0.25 - poor). Interaction to Next Paint consistently had values above 2,500 ms, once spiking to 4,144 ms (<200 ms - good, >500 ms - poor). The page was totally unresponsive for a while and, although the browser window was not dimmed due to lack of responsiveness, you could not interact not only with the page but with the browser as well.

Oh, and yes, I'm running on the default skin, Vector 2022.

Now comes the logged-in part. Note: I am always running these scripts. Of those, I suppose that only unreliable.js may impact performance substantially because it scans the whole page for links; other scripts seem to be deployed only on explicit request.

There are going to be three options: one on Convenient Discussions, the other on DiscussionTools and the third on both options disabled.

First on Chromium (all runs cached):

Convenient Discussions off, DIscussionTools off: LCP 3.02 s/2.89s, CLS 0.07/0.96, INP 2,848 ms/2,460 ms, After the first test, the top bar became unresponsive to any clicks until I rewound the page to the very top.
Convenient Discussions on, DIscussionTools off: LCP 2.67 s/3.44 s, CLS 0.02/0, INP 31,980 ms. On the second run, my mouse got stuck due to the load and was scrolling all the time. Despite clicking like 100 times to exit the scrolling mode, it simply wouldn't listen. There was a blank screen for like 30 s, constantly slowly scrolling downwards. Generally my experience is that the page does load and you can see what is written there but you cannot interact with it in any way until the Convenient Discussions script reformatted all comments on the page.
Convenient Discussions off, DIscussionTools on: LCP 3.58 s/4.12 s, CLS 0.07/0.09, INP 2,824 ms/2,656 ms. The lag between copying a comment by clicking on timestamp and the notification was about 25 seconds (!)

Links to all Chromium runs here: https://va.cat/link/TXpRd05qVXlOems1OjpoYXNoOjowLjczNTY1NjAwIDE3NzAzODc1MjQ-/ (link good for 15 days)

Firefox runs:

https://profiler.firefox.com/from-browser/calltree/?globalTrackOrder=e0dc8b72a196w3&hiddenGlobalTracks=1w79wc&hiddenLocalTracksByPid=7792-0w2~15688-0~380-0~15056-0~3740-0~5752-0~2632-0~10648-0~12824-023~11960-0~1612-0~13520-01~10060-01~10380-0w2&implementation=js&thread=k&v=13 - Convenient Discussions. Super long waiting even for the standards of this thread. Creates some weird spacing at the end of the page for no apparent reason.
https://profiler.firefox.com/from-browser/calltree/?globalTrackOrder=ef0dc986a5b741w3&hiddenGlobalTracks=1w8ab&hiddenLocalTracksByPid=7792-0w3~3740-0~5752-0~15056-0~9412-0~2632-0~11964-0~1060-0~10648-0~12824-023~11960-0~11516-0~13904-01&implementation=js&thread=l&v=13 - no discussion tools enabled. Actually relatively snappy page.
https://profiler.firefox.com/from-browser/calltree/?globalTrackOrder=e0d983a5cb74126&hiddenGlobalTracks=1w8awc&hiddenLocalTracksByPid=7792-0w2~5752-0~3740-0~11516-0~6972-0~11964-0~15056-0~14456-0~10648-0~12824-023~11960-0~2632-0~9412-0~13904-01&implementation=js&thread=k&v=13 - DiscussionTools enabled.

But this is only about the reading part.
The editing part without syntax highlighting is not terrible. https://profiler.firefox.com/from-browser/calltree/?globalTrackOrder=h0g8f4da76b5ec1w39&hiddenGlobalTracks=1w79wf&hiddenLocalTracksByPid=7792-0w2~15056-0~3740-0~5752-0~10648-0~13004-0~6860-0~15672-0~12824-023~2632-0~11960-0~11516-0~9412-0~11964-0~6972-0~13028-0~13904-01&implementation=js&thread=n&v=13. After all, loading text is in itself not too big of a deal.

However, syntax highlight causes major issues.
https://profiler.firefox.com/from-browser/calltree/?globalTrackOrder=c0b98a1657423&hiddenGlobalTracks=1w8a&hiddenLocalTracksByPid=11436-01~11692-0~11912-0~14524-0~9116-0~12600-0~10108-0~12384-0~5792-0~6052-023~12256-0~4592-01&implementation=js&thread=h&v=13 On Firefox, it takes >30 s to edit anything but typing text is relatively straightforward.

On the other hand, typing on Chromium is somewhat difficult. It becomes extremely difficult on pages like EEng's, where there is a huge amount of custom formatting that needs to be highlighted (in this respect, Tryptofish's talk page is relatively light on that). This causes the edit page to freeze for a couple seconds upon typing anything - so basically technically editable but in reality impossible. To a lesser extent, this applies to large articles, which tend to have many references, templates and some formatting, all of which also require highlighting. Highlighting is an option in, among others, the accessibility settings: "Enable colorblind-friendly scheme for syntax highlighting when editing wikitext"
https://va.cat/link/TVRZd01EWTJNakU1TXc9OjpoYXNoOjowLjAxMjQyOTAwIDE3NzA0MDA3NTY-/ - link to Chromium 2017 wikitext editor trace with syntax highlight on.

In any case, my point is that comments such as this one

Can't load their user talk page? Don't want to wait 30 seconds? Then don't talk to that user. Can't post an ANI notice on their page? Fine, then they don't get an ANI notice on their page. That's their problem.

may probably be accepted by the community - although they shouldn't - but shouldn't be at all accepted on the side of the developers. It's not a user's duty to figure out why something doesn't work - they expect something to work from the start.

Did you refresh the page before every measurement you did? because otherwise you can't know if your numbers are effected by cache or not.

All pages are cached except those explicitly marked as non-cached (i.e. I did not refresh the browser or delete the cache after each measurement

If you need non-cached performance I can run this for you, but I think there's already a lot of good data to work on.

Two weeks have gone by, how this is going?

In T416247#11635809, @Szmenderowiecki wrote:

Two weeks have gone by, how this is going?

This is unscheduled work, and ppl already have planned work to do. So count on this probably taking quite a while.

When editing a long page with syntax highlighting, it is recommended to use WTE 2010 instead of WTE 2017 because the latter is known to be slow (T184857).

And how is that related to the present task, which is about reading rather than editing?

I am addressing the comments in T416247#11592528.

I see. Next time, please make explicit what you’re referring to, e.g. by quoting the sentences you’re addressing, or just by linking to the comment – a comment several comments (and weeks) back is not obvious at first as the referred-to thing (the latest comment or the description would be obvious).

Change #1294970 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/DiscussionTools@master] Performance optimization for ThreadItem: preload all markers

https://gerrit.wikimedia.org/r/1294970

Change #1294971 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/DiscussionTools@master] Performance optimization for ReplyLinksController: defer initial infuse

https://gerrit.wikimedia.org/r/1294971

Change #1294972 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/DiscussionTools@master] Performance optimization for overflowMenu: defer infusion until interact

https://gerrit.wikimedia.org/r/1294972

^ those patches take a local clone I made of the currently very-busy Village_Pump_(WMF), and reduce the time-cost of these areas of DiscussionTools during the initial page load from 176ms to 25ms. (On my high-spec macbook, so we can expect that to be more significant for many users.)

@Polygnotus had run some informal tests on an older machine that did not suffer excessive slowness, iirc, and may be able to provide those stats, or something similar if they feel like commenting.

Change #1294970 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Performance optimization for ThreadItem: preload all markers

https://gerrit.wikimedia.org/r/1294970

Change #1294971 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Performance optimization for ReplyLinksController: defer initial infuse

https://gerrit.wikimedia.org/r/1294971

Change #1294972 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Performance optimization for overflowMenu: defer infusion until interact

https://gerrit.wikimedia.org/r/1294972

Now those are merged, with the train timing, they'll be out on all wikis by the 25th. If anyone wants to give subjective reports, they'll make it to beta much quicker.

Very fuzzy QA requirements: "go to big talk pages on slow devices and see if they seem quicker to load now".

Well, and more pragmatically, is anything about the reply button and overflow menu broken?