Backend should also tell us if there is more comments and provide a way to fetch rest of it. We can even do pagination, like fetch 20-40 then 40-60 and so on. On the other hand we should also consider permalinked discussion. @DouweM WDYT?
If we're doing our job right, fetching 20 comments shouldn't be all that much slower than fetching 100. I would first focus on optimizing the profiles before concluding that reducing the number of notes will help: https://redash.gitlab.com/dashboard/gitlab-profiler-statistics
@stanhu The proposal seems to be to include the first 20 comments in the HTML response, and then fetch the rest, which would slow down the initial page load slightly, but will make the wait between page load and discussions.json loading less jarring. I don't think paginating discussions.json itself is a solution; we should improve its actual performance, as you say. "Bootstrapping" 20 (or 10, or whatever) comments would still be nice from a responsiveness perspective.
@fatihacet It's not trivial to load only a portion of discussions, because the 10 notes with the earliest created_at are not necessarily the first 10 notes displayed on the page, since the first created note may be the start of a discussion, the next 9 created notes may be simple individual notes, while the next 9 displayed notes may be replies to that first discussion. They are not part of the first 10 created notes, but they are displayed at the top of the discussion tab. We may be able to figure something out using something like GROUP BY type, discussion_id, though.