Reader: Use virtualized list to show the subscribed sites

[gabrielcaires]

Closes READ-206

Important

I plan to merge the changes introduced on the client/landing/subscriptions/components/site-subscriptions-list-v2 to the v1 version if we don't find regressions. For now, I am keeping both versions to simplify the testing

Proposed Changes

• Use a virtualized list to render the subscription list
• Temporary add client/landing/subscriptions/components/site-subscriptions-list-v2 component to enable us to test the performance differences
• Add a Temporary feature flag reader/site-subscriptions-list-v2 to simplify the comparative testing

Why are these changes being made?

• Users are experiencing significant performance issues on the reader/subscription page when they have many sites or RSS subscribers. Sometimes, this prevents users from managing their subscription list. After extensive testing and both frontend and backend adjustments, I found that the most impactful change was the virtualization list strategy. While not a perfect solution for supporting an infinite number of sites, it pushes our limits much further without requiring major UI changes.

Testing Instructions

Scenario: Performance

• Go to the linear task and start a support session (SU) using the user mentioned on the issue.

• Wait for the browser to load the SU session

• Using the SU session, go to /reader/subscriptions (Feature Disabled)

• Open the devtools and wait at least 10 calls to /rest/v1.2/read/following/mine

• Set a CPU throttle to 4x as the image bellow describes

• Try to make a search or a sorting, and check if the browser struggles to render. (You probably can see other moments when the browser is struggling to render the page)

• Using the SU session, go to /reader/subscriptions?flags=reader%2Fsite-subscriptions-list-v2 (Feature Enabled)

• Check if you can notice a performance improvement and if you are able to search and sort

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you tested accessibility for your changes? Ensure the feature remains usable with various user agents (e.g., browsers), interfaces (e.g., keyboard navigation), and assistive technologies (e.g., screen readers) (PCYsg-S3g-p2).
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
  • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-163658

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-163658&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-163658&env=a8c-for-agencies

Dashboard live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-163658&env=dashboard

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~957 bytes added 📈 [gzipped])

name                 parsed_size           gzip_size
entry-main               +3024 B  (+0.1%)      +40 B  (+0.0%)
entry-subscriptions       +789 B  (+0.0%)     +881 B  (+0.1%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~14863 bytes added 📈 [gzipped])

name    parsed_size           gzip_size
reader     +54594 B  (+1.1%)   +14863 B  (+1.2%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~11934 bytes removed 📉 [gzipped])

name                                                                              parsed_size            gzip_size
async-load-calypso-reader-site-subscriptions-manager-pending-subscriptions-ma...     -45292 B  (-76.3%)   -11934 B  (-74.2%)
async-load-calypso-reader-site-subscriptions-manager-comment-subscriptions-ma...     -45292 B  (-76.3%)   -11934 B  (-74.1%)
async-load-calypso-reader-search-stream                                              -43994 B  (-56.6%)   -11455 B  (-52.4%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[matticbot]

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

• blaze-dashboard
• help-center
• notifications
• wpcom-block-editor

To test WordPress.com changes, run install-plugin.sh $pluginSlug update/optimize-subscription-list on your sandbox.

[jeherve]

Check if you can notice a performance improvement

I'm afraid the experience is worse for me. The browser tab is unresponsive for about 80 seconds for me in Chrome, before I can launch a search. On production, it's about 30 seconds before I can launch a search.

I'll let others test, but for me the experience in production is better.

[gabrielcaires]

@jeherve Wow, it is surprising.
Can you confirm that when you tested it, you saw the green virtualized label