Open nekodex opened 4 years ago
Adding to current month milestone since that seems pretty serious.
I tried using the page without javascript and it's still slow in chrome :thinking:
Looks like css/layout problem (and page large size).
Why does typing cause so much layout ಠ_ಠ
@nekodex, can you check this again? Some improvements have been made. It's still rather slow but should be way more usable now.
See if it still needs high priority and milestone labels.
Initial page loading has definitely improved a lot and typing no longer triggers reflows, however switching between tabs (e.g. from "General (All difficulties)" to "Timeline" or vice versa) is still pretty bad... 3-4 seconds with no feedback in the case of the discussion linked in OP
Profiling seems to suggest about a third of the time is spent on style recalculation and layout reflow, with the rest being react rendering... so we can probably improve things further?
Removing all those causing style recalculation and layout ends up with... style recalculation and layout task at the end of process (which takes roughly the same amount of time) because it still needs to be done regardless...? :shrug:
Unmilestoning as it's not as slow anymore.
This discussion with 1.6k comments takes about 10 seconds to load on my PC. I don't think that's optimal. I think it would be better if it loaded 50 comments initially, then more as you scroll.
https://osu.ppy.sh/beatmapsets/1200218/discussion/-/generalAll
It seems to load pretty fast if you filter away from "all". I guess the issue is that the page loads to all by default?
Loading as you scroll makes searching hard, and generally increases the complexity of the (already complex) system.
Page loading defaulting to all is not the issue. I am just surprised the web page is requested to spend seconds to load 1000+ comments in one go. You can't view the praises for that beatmap without doing so.
If you switch to praise or pending, you'll note that it's actually quite a lot faster. The overhead is mostly from layout when viewing all, I believe.
Switching to pending takes 1 second. Switching to praise takes around 10 seconds according to profiling:
Gif showing replay of the transition: https://i.imgur.com/b7vBLai.gif
(sorry for necropost)
I'm suffering with the same issue with this map https://osu.ppy.sh/beatmapsets/1237505/discussion/ where when I switch to General (all difficulties) tabs the sites becomes laggy and takes a lot of times to load (about 6 seconds on my computer). Because this section is almost full of praises, showing praises only doesn't really decreases the load time. It's even worse on mobile, when it's pain in the ass or almost impossible to read.
Will bump this in priority. The linked page is pretty bad for me too.
Has there been any progress on this or is this blocked for some reason? It seems like the above map still gets a noticable amount of traffic.
Although this example isn't as egregious, a single posts receiving many replies is also a thing that happens occasionally.
On discussion-heavy beatmaps, performance degrades to the point where even typing in certain input boxes results in 1fps updates, even after the page has taken a significant amount of time to load.
For example: https://osu.ppy.sh/beatmapsets/970063/discussion
Page takes 15s+ to load, and even after waiting for CPU load to drop, typing in the "New Discussion" box under either the "General (All Difficulties)" or "Timeline" tabs results in updates of 1fps or so (quick profiling suggests forced reflow when typing??).
Also hovering over the timeline markers in the top section results in delays before hover feedback and tooltips are displayed... plus delays in switching tabs, and other performance issues...
A quick profile of page load seems to suggest excessive calls to
shouldStick()
heavily impacting the initial page load time:and a quick profile of typing in the "New Discussion" box suggests each character input triggers a forced reflow...
(I would have sworn we already had an issue for performance on the discussions page, but I can't find it 🤷♂️)
(edit: Should also add that this behaviour occurs in Safari and Chrome, while apparently it's not as bad in Firefox according to @nanaya)