@eranroz, are you sure it's Recent Changes where the slowdown occurred? Hebrew beta users have been looking at that for months and reported no slowdowns.

On the other hand, we just launched the New Filters beta to Watchlist today. Is that the slowdown you've seen reports about?

I think he likely did mean RC, because he's a hewiki user and we launched RCFilters as a default there today.

Change 379117 had a related patch set uploaded (by Eranroz; owner: Eranroz):
[mediawiki/core@master] Lazy creation for heavy menu

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

It looks like the RC sometimes very slow to load.

1. The above patch address only some of the slowness (the hidden UI creation can take ~1sec)
2. Ideally there should be a performance metrics for RCFilters. How long does it take till the RC is fully loaded before this change and after this change?

<s>3. This could be also a operation issue: There are some requests with 404 response during load:
https://he.wikipedia.org/wiki/%D7%9E%D7%99%D7%95%D7%97%D7%93:%D7%A9%D7%99%D7%A0%D7%95%D7%99%D7%99%D7%9D_%D7%90%D7%97%D7%A8%D7%95%D7%A0%D7%99%D7%9D?hidebots=1&hidecategorization=1&hideWikibase=1&limit=1&days=7&urlversion=2&from=20170919220833&action=render&enhanced=0

Bad response from the following servers:
mw1216.eqiad.wmnet
mw1265
mw1241
mw1269
mw1245

Good response from:
mw1238
</s>

I am looking at he.wiki Recent Changes page. With default filters but set to return 500 results from 30 days, I see delay of about 3-4 seconds. Which is to say virtually identical to what I see when I test the old UX.

@eranroz, what combinations are giving you a 404? (The link you provide takes me to a version of the page that I don't recognize.)

In T176250#3619723, @eranroz wrote:

It looks like the RC sometimes very slow to load.

1. The above patch address only some of the slowness (the hidden UI creation can take ~1sec)

Thanks! It looks good to me but I'll let @Mooeypoo make the final call, she wrote most of that code.

2. Ideally there should be a performance metrics for RCFilters. How long does it take till the RC is fully loaded before this change and after this change?

Yes, there should be.

<s>3. This could be also a operation issue: There are some requests with 404 response during load:

For some strange reason, 404s are "expected behavior" when there are no results to your RC query.

In T176250#3619801, @jmatazzoni wrote:

I am looking at he.wiki Recent Changes page. With default filters but set to return 500 results from 30 days, I see delay of about 3-4 seconds. Which is to say virtually identical to what I see when I test the old UX.

@eranroz, what combinations are giving you a 404? (The link you provide takes me to a version of the page that I don't recognize.)

Please ignore the above comment about 404. (there is a periodic query on the recent changes with "from" parameter from last load, giving all the changes since then, and when there are no changes it returns 404 - this is valid behaviour)

There's another area for improvement that @Mooeypoo has been working on: T173533: No longer block user from clicking results when page is loading.. Currently, we show a loading animation and an overlay over the results while the UI is loading, but we should really just let the user interact with the results list right away. The reason we currently do this is because in some cases (if the user has a saved query that they've made default), we may need to reload the result list and replace it with the result of a different query, because default saved queries are handled entirely client-side. Moriel is working on moving this server-side (T166908: ChangesListSpecialPage backend: Respect saved query if no parameters) and after that's done we can remove the loading thing from the results list.

However, we could expedite this by optimizing for the most common case: if the user doesn't have a default saved query (which is probably the most common case), add (or don't add) a CSS class that causes the loading effect not to appear, and if they do, add a different CSS class. That way we don't have to wait for T173533 to be done before improving the experience for most people.

In T176250#3619877, @Catrope wrote:

There's another area for improvement that @Mooeypoo has been working on: T173533: No longer block user from clicking results when page is loading.. Currently, we show a loading animation and an overlay over the results while the UI is loading, but we should really just let the user interact with the results list right away. The reason we currently do this is because in some cases (if the user has a saved query that they've made default), we may need to reload the result list and replace it with the result of a different query, because default saved queries are handled entirely client-side. Moriel is working on moving this server-side (T166908: ChangesListSpecialPage backend: Respect saved query if no parameters) and after that's done we can remove the loading thing from the results list.

However, we could expedite this by optimizing for the most common case: if the user doesn't have a default saved query (which is probably the most common case), add (or don't add) a CSS class that causes the loading effect not to appear, and if they do, add a different CSS class. That way we don't have to wait for T173533 to be done before improving the experience for most people.

Thanks for pointing out to these these tasks - very good ideas and will solve the slowness issues much better than what I suggested (I was lucky to avoid edit conflict here :))

I am looking at he.wiki Recent Changes page. With default filters but set to return 500 results from 30 days, I see delay of about 3-4 seconds. Which is to say virtually identical to what I see when I test the old UX.

@jmatazzoni : FYI, on en.wp.org,

• full refresh page load time with JS disabled for the watchlist is 2.2 seconds [old UI loaded]
• full refresh page time load with JS enabled is 6.02 seconds
• normal refresh page time load with JS enabled is 4.34 seconds.

India/Chrome/Linux.

T176250: Defer building new filters menu to speed up performance

Change 379117 merged by jenkins-bot:
[mediawiki/core@master] Lazy creation for heavy menu

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

Change 379431 had a related patch set uploaded (by Catrope; owner: Eranroz):
[mediawiki/core@wmf/1.30.0-wmf.19] Lazy creation for heavy menu

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

Change 379431 merged by jenkins-bot:
[mediawiki/core@wmf/1.30.0-wmf.19] Lazy creation for heavy menu

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

Mentioned in SAL (#wikimedia-operations) [2017-09-21T00:02:29Z] <catrope@tin> Synchronized php-1.30.0-wmf.19/resources/src/mediawiki.rcfilters/: Lazy-load the RCFilters menu (T176250) (duration: 00m 48s)

Checked RC page load time (and Watchlist page) in betalabs and testwiki (1.31.0-wmf.1 ). The load time is from 2s to 4.40s (testwiki).

The extreme load times (7s - 18s) were not observed. The task required re-checking in production on enwiki. I saved several tests done on www.webpagetest.org to compare with production data.

Re-checked in 1.31.0-wmf.1 - the performance for RC and Watchlist pages seem to be improved.