Page MenuHomePhabricator

Server-side survey configuration filtering
Open, LowestPublic


Survey configuration and message payload delivers approximately 2 kB per survey, after minification. There is a lot to gain by optimizing the payload or even suppressing surveys which cannot be displayed, e.g. to an anonymous user because the survey audience must have an edit count.

The server has access to almost all of the information used to filter so in theory could take over all filtering up to some random sampling, but there's a trade-off between varying over more specific profiles, and efficiency losses due to cache fragmentation.

Server filtering can be introduced incrementally, a few fields at a time. This lets us monitor for performance regression.

Migration is only safe if we include filters on both server and client during the cutover. Client-side filters can be removed after waiting for some window of time in case of potential reverts.

Event Timeline

awight updated the task description. (Show Details)
Jdlrobson moved this task from Bugs to Feature requests on the QuickSurveys board.
Jdlrobson triaged this task as Medium priority.Jun 2 2021, 8:17 PM
Jdlrobson added a subscriber: ovasileva.

@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"):

PropertyCan be removed?What do we need to know?
audienceIf the user is logged in or not
platformsIf the MobileFrontend extension is loaded and thinks the user has requested the mobile site

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?

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.

ovasileva lowered the priority of this task from Medium to Low.Jun 23 2021, 4:56 PM
ovasileva moved this task from Incoming to Triaged but Future on the Web-Team-Backlog board.
ovasileva edited projects, added Web-Team-Backlog (Tracking); removed Web-Team-Backlog.
Jdlrobson lowered the priority of this task from Low to Lowest.Jun 23 2021, 4:58 PM