the first item of that list might be reasonably cache-friendly

AIUI we want a new task presented on each homepage visit. So if we get a set of 200 tasks back from the API, maybe we pick one at random (not the one currently being shown) and put it in the cache to render on server side for the next homepage visit.

Or maybe we can cache the full result list. Perhaps best to consider it after topic matching is done, when it will be clearer where we want to be on the random - per-user pseudorandom - personalised - non-random scale.

@MMiller_WMF @RHo I think we should consider this task for 1.0 or at least put it on the backlog of items to ship shortly after 1.0 is released. It will make the loading time needed to query for tasks much less noticeable, because the user will already have one task to look at when the page first loads.

@kostajh -- that sounds good to me. I'm marking it as 1.0 and putting it in Ready for Development. But since I don't 100% understand the amount of work involved, I'll rely on you to point out if it seems higher priority than the other 1.0 things we're working on. We'll also know some more when we see the actual speed in production.

I made this a subtask of T238171: Newcomer tasks: slow loading time for suggested edit module, since that task describes the problem in general (which may end up needing multiple solutions).

Moving off sprint board in favor of Newcomer Tasks V1.0 tasks.

AIUI we want a new task presented on each homepage visit. So if we get a set of 200 tasks back from the API, maybe we pick one at random (not the one currently being shown) and put it in the cache to render on server side for the next homepage visit.

Rather than caching, now that we use local config and search (T235717), I think it would be better on page load to perform a search request with limit 1 using the user's stored preferences for task types, then render that card (along with the difficulty filter button widget, the task explanation widget, and the previous/next arrows) on the server side. When the suggested edit module JS initializes, it would infuse the various components on the page and fetch tasks in the background (but not replace the server-side rendered card).

Change 631987 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] [WIP] Homepage: Render filter buttons on server-side

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

Proposing this as a leftovers task. We are not too far from being able to render almost everything on the server-side now.

Adding to current sprint for visibility.

Change 635366 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] ConfigurationLoader: Add getTopics convenience method

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

Change 635366 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] ConfigurationLoader: Add getTopics convenience method

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

Change 635381 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Suggested Edits: Render pager widget on server-side

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

Change 631987 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Homepage: Render filter buttons on server-side

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

Change 635381 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Suggested Edits: Render pager widget on server-side

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

Change 635818 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] [WIP]: Server-side rendered card wrapper

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

Change 635839 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Suggested Edits: Server-side rendering of task explanation widget

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

Test wiki created on Patch Demo by KHarlan (WMF) using patch(es) linked to this task:

http://patchdemo.wmflabs.org/wikis/0f28ca3e302c5a3ddd0990e2fbb6e726/w/

In T236738#6571595, @PatchDemoBot wrote:

Test wiki created on Patch Demo by KHarlan (WMF) using patch(es) linked to this task:

http://patchdemo.wmflabs.org/wikis/0f28ca3e302c5a3ddd0990e2fbb6e726/w/

This looks good on mobile and desktop (see https://imgur.com/a/lkYAxu5), however, one weird thing is that on Desktop the 1st suggestion's image takes a long time to load – in the Desktop example, "Danny Ferry" was taking so long (on 3G speed but still), that I stopped recording, but does definitely have an image. Another strange thing is that when I went to the second and third articles suggested, the images on those articles loaded but when going back to the first article the Danny Ferry image still had not finished loading.

In T236738#6571626, @RHo wrote:

In T236738#6571595, @PatchDemoBot wrote:

Test wiki created on Patch Demo by KHarlan (WMF) using patch(es) linked to this task:

http://patchdemo.wmflabs.org/wikis/0f28ca3e302c5a3ddd0990e2fbb6e726/w/

This looks good on mobile and desktop (see https://imgur.com/a/lkYAxu5), however, one weird thing is that on Desktop the 1st suggestion's image takes a long time to load – in the Desktop example, "Danny Ferry" was taking so long (on 3G speed but still), that I stopped recording, but does definitely have an image. Another strange thing is that when I went to the second and third articles suggested, the images on those articles loaded but when going back to the first article the Danny Ferry image still had not finished loading.

That is probably from a network request timing out, it shouldn't be a side effect of anything introduced in this patch. This patch doesn't attempt any image rendering (since we don't know the image source yet), and once the client-side JavaScript knows the thumbnail to use, it will update the image placeholder. If the request to fetch the thumbnail fails, we don't currently attempt to retry.

In T236738#6571815, @kostajh wrote:

In T236738#6571626, @RHo wrote:

In T236738#6571595, @PatchDemoBot wrote:

Test wiki created on Patch Demo by KHarlan (WMF) using patch(es) linked to this task:

http://patchdemo.wmflabs.org/wikis/0f28ca3e302c5a3ddd0990e2fbb6e726/w/

This looks good on mobile and desktop (see https://imgur.com/a/lkYAxu5), however, one weird thing is that on Desktop the 1st suggestion's image takes a long time to load – in the Desktop example, "Danny Ferry" was taking so long (on 3G speed but still), that I stopped recording, but does definitely have an image. Another strange thing is that when I went to the second and third articles suggested, the images on those articles loaded but when going back to the first article the Danny Ferry image still had not finished loading.

That is probably from a network request timing out, it shouldn't be a side effect of anything introduced in this patch. This patch doesn't attempt any image rendering (since we don't know the image source yet), and once the client-side JavaScript knows the thumbnail to use, it will update the image placeholder. If the request to fetch the thumbnail fails, we don't currently attempt to retry.

Ah OK, but to clarify, the first image does eventually load, it just takes ages. Is that possible if the network request times out – does it just run do it again until the image is fetched?

Change 635818 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Suggested Edits: Server-side rendered card wrapper

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

Change 635839 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Suggested Edits: Server-side rendering of task explanation widget

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

Checked on betalabs desktop and mobile - generally works fine; ocassionally (non-reproducible though) the initial card load takes a long time as mentioned in this comment. Another curious (and a really edge case) - when "Restore all default settings" option is used, there will be a mismatch between SE cards displayed on the Homepage and on SE overlay.

Here is the animated gifs for @RHo review (the issue with overflowing pageview placeholder is reported as T267166)

Desktop:

Mobile

In T236738#6601566, @Etonkovidova wrote:

Checked on betalabs desktop and mobile - generally works fine; ocassionally (non-reproducible though) the initial card load takes a long time as mentioned in this comment. Another curious (and a really edge case) - when "Restore all default settings" option is used, there will be a mismatch between SE cards displayed on the Homepage and on SE overlay.

Here is the animated gifs for @RHo review (the issue with overflowing pageview placeholder is reported as T267166)

Desktop:

Mobile

Just to clarify, the server-side rendered version of the module happens /after/ you've activated it, when you come back to Special:Homepage a second time in variant D. Or if you are in variant C, it should be there the first time since the module is pre-activated.

In T236738#6571836, @RHo wrote:

In T236738#6571815, @kostajh wrote:

In T236738#6571626, @RHo wrote:

In T236738#6571595, @PatchDemoBot wrote:

Test wiki created on Patch Demo by KHarlan (WMF) using patch(es) linked to this task:

http://patchdemo.wmflabs.org/wikis/0f28ca3e302c5a3ddd0990e2fbb6e726/w/

This looks good on mobile and desktop (see https://imgur.com/a/lkYAxu5), however, one weird thing is that on Desktop the 1st suggestion's image takes a long time to load – in the Desktop example, "Danny Ferry" was taking so long (on 3G speed but still), that I stopped recording, but does definitely have an image. Another strange thing is that when I went to the second and third articles suggested, the images on those articles loaded but when going back to the first article the Danny Ferry image still had not finished loading.

That is probably from a network request timing out, it shouldn't be a side effect of anything introduced in this patch. This patch doesn't attempt any image rendering (since we don't know the image source yet), and once the client-side JavaScript knows the thumbnail to use, it will update the image placeholder. If the request to fetch the thumbnail fails, we don't currently attempt to retry.

Ah OK, but to clarify, the first image does eventually load, it just takes ages. Is that possible if the network request times out – does it just run do it again until the image is fetched?

Sorry I missed this comment @RHo . If it does eventually load, then that is just a slow network request. We don't 'have code to retry on failures as far as I recall. Have you seen also this in production or just in beta/patchdemo land?

In T236738#6602236, @kostajh wrote:

In T236738#6571836, @RHo wrote:

In T236738#6571815, @kostajh wrote:

In T236738#6571626, @RHo wrote:

In T236738#6571595, @PatchDemoBot wrote:

Test wiki created on Patch Demo by KHarlan (WMF) using patch(es) linked to this task:

http://patchdemo.wmflabs.org/wikis/0f28ca3e302c5a3ddd0990e2fbb6e726/w/

This looks good on mobile and desktop (see https://imgur.com/a/lkYAxu5), however, one weird thing is that on Desktop the 1st suggestion's image takes a long time to load – in the Desktop example, "Danny Ferry" was taking so long (on 3G speed but still), that I stopped recording, but does definitely have an image. Another strange thing is that when I went to the second and third articles suggested, the images on those articles loaded but when going back to the first article the Danny Ferry image still had not finished loading.

That is probably from a network request timing out, it shouldn't be a side effect of anything introduced in this patch. This patch doesn't attempt any image rendering (since we don't know the image source yet), and once the client-side JavaScript knows the thumbnail to use, it will update the image placeholder. If the request to fetch the thumbnail fails, we don't currently attempt to retry.

Ah OK, but to clarify, the first image does eventually load, it just takes ages. Is that possible if the network request times out – does it just run do it again until the image is fetched?

Sorry I missed this comment @RHo . If it does eventually load, then that is just a slow network request. We don't 'have code to retry on failures as far as I recall. Have you seen also this in production or just in beta/patchdemo land?

It's was in the patchdemo. I just now tried in CS Beta and it takes a 3-5secs on the Slow 3G speed, which is expected, so maybe this is actually fine.

In T236738#6601566, @Etonkovidova wrote:

Another curious (and a really edge case) - when "Restore all default settings" option is used, there will be a mismatch between SE cards displayed on the Homepage and on SE overlay.

The reset clears the filter settings of the user; I suppose we have different fallback logic on the server and client side when the user option is missing?