//Background//
Over a year ago, Google introduced [[ https://web.dev/vitals/ | Web Vitals ]], a set of measures of a Web site's usability. In November, 2020, Google [[ https://developers.google.com/search/blog/2020/11/timing-for-page-experience | announced ]] May 1, 2021 as that date that Web Vitals will be taken into account in search result rankings.
Currently, the banner system deployed on all Wikipedias, and nearly all WMF Wikis, impacts negatively on our Web Vitals scores. Banners are added to pages after initial page display, causing content to shift downwards. This affects our score on the [[ https://web.dev/cls/ | Cumulative Layout Shift ]] (CLS) metric. Also, another metric that Google is rolling out at the same time, [[ https://web.dev/lcp/ | Largest Contentful Paint ]] (LCP) significantly limits our options for switching to a different banner design (such as overlays).
Note that these new Google metrics do measure real problems with Web sites, including ours. The content shift due to banner injection (the "banner bump") is undoubtedly a usability problem, and probably causes a few second of annoyance to thousands of people worldwide every day.
While it's not known exactly how much our search rankings will decline due to this problem, //it is known that they will decline//, and the impact will probably be more severe for small language wikis, and in regions where connectivity is worse and people use slower devices. This is exactly where the movement is [[ https://strategy.wikimedia.org/wiki/Wikimedia_Movement_Strategic_Plan_Summary/Increase_Participation | seeking to grow communities ]].
//Overview of options//
Two main sets of options exist for addressing this issue:
- Change banner designs (for example, to small overlays, sticky headers or footers, or animated nags) so banners don't affect search rankings. Options here are limited, but not non-existent, though most, if not all, have other problems. T280477 explores these options.
- Change the system that displays banners ([[ https://meta.wikimedia.org/wiki/CentralNotice | CentralNotice ]]) so that banners display right away, rather than after the page loads. This is a challenging engineering problem, because of how we choose which banners to show to users, and how our data centers are set up. However, I believe that a solution is almost certainly possible, at least in the medium term. This would make changing banner designs unnecessary. T279034 is about what I think is the most promising engineering solution, called "pageview+1".
Two other courses of action, which do not address the issue, have also been suggested:
- Do nothing for now, and just monitor search rankings to see if they really decline.
- Shut down banners (completely or in part).
Combinations of, or temporarily falling back to, various options, should probably also be considered.
//Areas involved and balancing considerations//
This problem cuts across concerns, teams and domains of expertise. It touches design, usability, reading, site reachability, movement growth, community campaigns, fundraising, performance and datacenter architecture.
This makes evaluating costs and benefits of different options difficult. How much engineering effort is it worth to prevent a likely decline in search rankings in places prioritized for movement growth? How much design work is it worth? Or, how much user annoyance (from Google-metric-friendly-but-flashy-and-annoying banners)?
Personally, I strongly favour an engineering solution, that is, fixing the system that displays banners, since that approach (1) solves a real usability problem without creating new ones, and (2) gives us the freedom to design usable, beautiful banners without concern for Google metrics or possible SEO impact.
Thanks!!
//Note 1: I hope this task can provide a space for constructive discussion about an important, complex problem, and I hope this is the right place for it. Thanks so so much in advance for sharing your thoughts.//
//Note 2: I am working on this on my own time, so, not as part of my work as an FR-Tech engineer. Unless otherwise noted, this task is not included in planned work by FR-Tech.//
//Thanks again!//
//- @AndyRussG//