Change Details

//Background// One 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, 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. 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//

//Background// One 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-June 2021 as the 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 [citation needed]. 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). These new metrics measure real problems with Web sites including ours. The content shift due to banner injection (the "banner bump") is a known usability problem, and causes measurable annoyance to people worldwide every day. See {T138177} and its subtasks. 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 [[ 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". 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). - Make a private deal with Google to "give us an exception" to their new metrics, for all of Wikimedia's web properties. But this might be impossible after recent antitrust legislation? - Show spiders a special version of each page, with no banners. But 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. 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!//

//Background// One 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,May-June 2021 as thate 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 [citation needed]. 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 tThese new Google metrics do measure real problems with Web sites, including ours. including ours.The content shift due to banner injection (the "banner bump") is a known usability problem, 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 dayand causes measurable annoyance to people worldwide every day. See {T138177} and its subtasks. 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 [[ 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 oOther 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). - Make a private deal with Google to "give us an exception" to their new metrics, for all of Wikimedia's web properties. But this might be impossible after recent antitrust legislation? - Show spiders a special version of each page, with no banners. But 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. 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//