One year ago, Google introduced Web Vitals, a set of measures of a Web site's usability. In November, 2020, Google announced that Web Vitals would be taken into account in search result rankings as of May 1, 2021, though the change was recently postponed to mid-June, 2021.
Currently, the banner system deployed on all Wikipedias, and nearly all WMF Wikis, impacts negatively on our Web Vitals scores (clearly demonstrated by declines in scores where banner campaigns are active). Banners are added to pages after initial page display, causing content to shift downwards. This affects our score on the Cumulative Layout Shift (CLS) metric. Also, another metric that Google is rolling out at the same time, Largest Contentful Paint (LCP) significantly limits our options for switching to a different banner design (such as overlays).
While it's not yet 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 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 (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. T283521 and T279034 are about possible technical solutions.
Other courses of action, which do not address the issue in a sustainable way, 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).
- Show spiders a special version of each page, with no banners. (This wouldn't work, though, since Google will be taking measurements directly from Chrome user data. Also, this is explicitly not allowed, see T252200.)
Combinations of, or temporarily falling back to, multiple 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.
Here are some of our current scores for the Cumulative Layout Shift (CLS) metric, with and without banners. Data from Google's PageSpeed Insights. The recommended maximum score for CLS is 0.1.
|Article||Platform||CLS no banner||CLS field data||CLS large FR||CLS small FR||CLS community|
|Barack Obama||Desktop||0.009 ✅||0.01 ✅||0.284 ❌||0.171 ❌||0.749 ❌|
|Barack Obama||Mobile||0.106 ❌||0.19 ❌||1.022 ❌||0.497 ❌||0.365 ❌|
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.