Page MenuHomePhabricator

SEO impact and major changes to serving banners
Open, In Progress, Needs TriagePublic

Description

Instructions

  1. Define the problem or opportunity (WHAT).
  2. Outline the importance of addressing the problem or opportunity (WHY).

What?

Write your problem statement using layperson's terminology.
In one sentence, what is the problem or opportunity?

Moving forward Google will be using Cumulative Layout Shift in their SEO calculations (sometimes referred to as “banner bump” at WMF). This occurs when a banner loads into the top of the page and shifts content down. This is noticeable on all CentralNotice (CN) banners. Even small community banners have some impact on this calculation. There is no concrete evidence that this is impacting our pageviews at the moment. However this impact is expected to increase over time.

What does the future look like if this is achieved?

  • We can continue running fundraising and community banners, meeting our revenue targets and maintaining an informed and engaged community without negatively impacting our search ranking.

What happens if we do nothing?

  • Site traffic will continue to suffer due to the increasingly poor search rankings. Revenue targets will get increasingly harder to reach. Overall popularity of the site will suffer.
  • In the event this has a low or slowly increasing negative effect, this will pull multiple teams into lengthy investigations multiple times a year. If we don’t work to solve this, we will be constantly distracted trying to evaluate its impact.
  • If this has a sudden and severe negative impact, multiple teams will have to stop what they are doing and address this asap.

Why?

Identify the value(s) this problem/opportunity provides. Add links to relevant OKRs.
Rank values in order of importance and be explicit about who this benefits and where the value is.

User Value/Organization Value AND Objective it supports and How

  1. This represents an existential threat to the movement. All OKRs are affected in some way
  2. maintains or increases readership
  3. maintains the ability to raise money through banners and communicate to the community
  4. maintains or increases our SEO

Why are you bringing this decision to the Technical Forum?
What about the scope of this problem led you and your team to seek input across departments/organizations?

This issue would be best described as complex and involves many teams. With that, we need to give all involved teams the chance to consider the problem and constraints. They need time to research solutions as well as assessing budgeting/schedule impact. This needs to happen as soon as possible to be incorporated into annual planning.

Event Timeline

(removing Alex as a subscriber because the herald rule for TWL just matched on the gdoc url)

Hey thanks so so much for this!! Some quick initial notes... I would like to suggest that the best option here would be to remove the banner bump entirely by injecting banners directly at the Varnish layer. I believe this is completely feasible without showing any less banners than we currently do, and without impacting site performance. Here's an initial discussion of how it could work: T283521: Proposal: Fix banner bump with server-side cache-layer banner selection

Even if it were found that the banner bump provides some Fundraising benefit (though I don't know if there's empirical evidence for this) we could still add in its stead a different eye-catching animation that doesn't impact the reading experience or CLS scores.

I would like to respectfully recommend against two options mentioned in the Google doc:

  • "I recommend that we investigate ways of reserving space for a banner as the content loads." While this is technically possible, it would place significant constraints on site design and possible banner sizes. Since injecting banners at the cache layer has neither of those disadvantages, I'd suggest that studying that option could be the top priority.
  • "I strongly recommend that we look to replace CentralNotice." None of the alternate libraries I looked at provide features that would help us with CLS. I might well have missed something, but at least as a starting point, I don't think we can assume that replacing CN would help address the issues described here. In addition, I think it would be a much, much bigger engineering project than adapting CN to inject banners without the bump. (Nonetheless, I'd still agree that a review of CN alternatives would be worthwhile.)

I would also like to throw my support several million % behind the more general proposal to expand engineering resources for CentralNotice (or whatever banner system we use, if we do switch). It's a fundamental, complex part of our sites, and it absolutely needs this investment. Thanks so so much for highlighting this, hugely appreciated.

Thanks again!! :) :)

The document being discussed is private—is it possible to share publicly?

The doc I had was mostly a draft of this process and some of my own notes. I was unfamiliar with this process. I'm letting the discussion happen here and in the tech decisions making process.

Yeah, that one that David just removed is a bit premature for this part of the conversation/process. I asked him to start this here/via the Tech Decision Forum for one primary reason: to ensure we get all the right folks/teams in the conversation so we can be sure we have the right problem definition and then figure out the RACI for working on it. Apologies for any false start feelings that (may have) created.

Thanks so much @greg, @DStrine, @awight! aaaah and apologies for starting to discuss too early...

Just in case it's useful, some context and details about the SEO changes can be found here: T280476. Also, regarding possible changes to banner formats for this issue, see T280477.

Worth noting that fixing the "banner bump" has been a longstanding request, even before the potential for SEO impact T52865: CentralNotice shifts down page content on load (causes mis-clicks)

January 19, 2022 Tech Steering Committee:

  • Greg C: few options to move forward that would require other teams to support
    • could align to parser content fragments work
    • could align to logged in user penalty (which could mitigate this and parser content fragments) and relies on some middleware solution
  • Logged in users get worst performance because their skin at minimum shows their web name username at the top, so they don't get a cached hit and their request goes back to the app server. The idea is that using some solution.
      • Mark B. - realize we are talking about content composition at the edge here and is related to the performance OKR work and would require a large amount of work
      • Kate C. - it seems as if this is a capability that is missing, not an individual feature
    • Greg G: there is a potential short-term fix involving traffic and FR-tech
  • Desiree A.: should we look at this for APP given that it needs a more comprehensive solution

Action Items:

  • Have Andy submit short-term solution to tech forum
  • Greg to loop Andy, Brandon (and Traffic EM?), Moriel, Timo to discuss short-term solution
  • Long-term capability: look at how we pull together an ask for APP
  • DA to check with Linda Lenrow Lopez (Enterprise Risk Management Principal)

There was a meeting this morning with folks from Performance (Timo), Traffic (Brandon), and Architecture (Moriel) (with Kate C and Mark B as Directors) along with David, myself, and Andrew Green.

Next steps:

  • Moriel: Set up a use-case modeling session with us.
  • Greg: Asynchronously develop the set of options/solutions and what the cost/benefit analysis is of each, with all options on the table.

As a reference point @jwang worked on this question in T297213: Analyze impact of page experience metrics on French Wikipedia during campaign (perhaps this is the work referenced by the statement "There is no concrete evidence that this is impacting our pageviews at the moment.")

As a reference point @jwang worked on this question in T297213: Analyze impact of page experience metrics on French Wikipedia during campaign (perhaps this is the work referenced by the statement "There is no concrete evidence that this is impacting our pageviews at the moment.")

Thanks, @mpopov, that's really important to note! I guess that might be one of a few investigation that folks were thinking of? (And also thanks so so much @jwang, @Mayakp.wiki, @kzimmerman and others for all your incredible work on this topic, it's hugely appreciated!!)

Just to add some more notes, from what I've seen, and also given the very directed focus of that investigation (about France), I feel there is still tons of digging to do before we can reach a global, "There is concrete evidence that this is not impacting our pageviews"?

(See this comment from @Mayakp.wiki about the upcoming study of referrer and access method dimensions.)

These investigations have a moving target, since other web sites may well also be in the process of optimizing for CWV, which could make our poor CLS scores impact our rankings more than they do now. Plus, Google may well have made, or may plan to make, other simultaneous changes to search that we don't know about, which complicates all investigations. Finally, I fear all studies that included pageview data from users in the Americas will have to be redone, since the pageview data loss for this region over the past 7 months was likely quite substantial.

April 13, 2022 Update

  • Several options have been evaluated, some short-term (immediate fixes) and other longer-term solutions that would benefit multiple areas and needs
  • Based on discussions, we will continue to monitor for potential impact and make judgement call on next step from there.
DAbad changed the task status from Open to In Progress.Apr 13 2022, 2:49 PM

August 3, 2022

  • status is traffic team not yet done with experiment to see feasibility of ESI solution
  • originally hoping to do in Q4, still need to complete
  • Next step: engage with FR-tech on more real-world experiment