@phuedx would you be able to analyze this one?

Firstly, let's address what we need to know in order to remove certain parts of the survey config payload ("the payload"):

AFAICT we can remove survey.isEnabled and survey.audience.pageIds without any additional changes.

Now let's address when/how we filter surveys and how we deliver the payload…

Status quo

Survey filtering is done when:

1. We decide whether to send the init module to the client;
2. Whether to send the lib module to the client; and # We define the wgEnabledQuickSurveys config variable in the ResourceLoaderGetConfigVars hook

Note well that #2 is done as part of the definition of the init module. Thus, there is more information available to filter out surveys in #1 than in #2 and #3 because Resource Loader modules are session-independent. Further, in #1 the list of modules sent to the client is cached at the edge for up to one day whereas the results of #2 and #3 are cached at the edge for up to five minutes.

This approach has the following desirable properties:

• wgEnabledQuickSurveys is sent to the client off of the critical path
• If we disable a survey, then it's disabled within five minutes and is no longer included in wgEnabledQuickSurveys

and the undesirable property that we have very little information to filter out surveys when defining wgEnabledQuickSurveys – we could use the Resource Loader target but that's being dismantled (see T127268).

Alternatives to the status quo

Define wgEnabledQuickSurveys in the OnBeforePageDisplay hook

Survey filtering can be done once and the config can be sent to the client with OutputPage::addJsConfigVar(). We have access to the user in the OnBeforePageDisplay hook and also to the MobileFrontend.Context service and can therefore remove all properties that can possibly be removed. However, this approach would require that we define wgEnabledQuickSurveys on the critical path whenever a survey is enabled.

An API call

We could add an API that returns surveys available to the user. Provided that all information required for filtering is passed via parameters, the API can be cached at the edge regardless of whether or not the user is logged in but that cache might be overly fragmented. This approach keeps the desirable properties stated above but would introduce an additional request per pageview when at least one survey is enabled, thereby increasing load and the time to the user seeing a survey.

@phuedx does T245292 impact your analysis in any way?

In T254977#7168282, @Jdlrobson wrote:

@phuedx does T245292 impact your analysis in any way?

The changes described in T245292: Don't lazily load messages when showing a survey do reduce the amount of data sent to all clients and also will improve the UX for users with poor connections. Further, those changes would be effective in all scenarios I've listed above. Thinking about it, I would recommend that we do T245292: Don't lazily load messages when showing a survey before broaching the topic of declaring $wgEnabledQuickSurveys in the critical path.