XF 2.2 xF2.2 and Mobile Usability in Google Search Console

Anatoliy

Well-known member
xf.webp

1. Jul 27 - upgraded to xF 2.2 Beta 1.
2. Aug 3 - removed data-app="public" from PAGE_CONTAINER.
3. Aug 6 - upgraded to xF 2.2 Beta 2, reverted PAGE_CONTAINER.
4. Aug 13 - upgraded to xF 2.2 Beta 3.
5. Aug 15 - removed data-app="public" from PAGE_CONTAINER.
 
Solution
The issue still exists and will continue to exist until the aforementioned Chromium bug is resolved. It is possible for some internal tools to not flag themselves as a web driver properly (thanks for that @Kirby) and it's possible for Google's tools to be using a custom user agent that we're not yet detecting.

But for now we've worked-around it and hopefully that solves the bulk of the issues arising from it.
The issue with data-app="public" was because removing that prevented some PWA related code from running. The PWA related code is something that triggered a very specific bug in the version of headless Chromium that is run by Lighthouse.

If you're running Beta 3 and Lighthouse is now working, there is no reason to remove data-app="public". It has no effect on its own and has been part of the PAGE_CONTAINER template I think since the release of XF 2.0.0.

You reported this as a bug but without any actual issues to report we're unable to help. If you can use your search console to drill down as to why certain pages once were "valid" and now aren't then that would be useful but without that we have no further insights.
 
If you're running Beta 3 and Lighthouse is now working, there is no reason to remove data-app="public". It has no effect on its own and has been part of the PAGE_CONTAINER template I think since the release of XF 2.0.0.
I don't have any problems neither with lighthouse nor with pagespeed insights since ungraded to Beta 2.
And I'm sorry, but I can't agree that to have 0 pages listed as mobile friendly instead of 2k is 'no reason to remove...'.
You reported this as a bug but without any actual issues to report we're unable to help.
I just shared info that I thought you might find useful.
If you can use your search console to drill down as to why certain pages once were "valid" and now aren't then that would be useful but without that we have no further insights.
I have no idea how to do that.
 
So, valid mobile pages came back to 2k. Today I upgraded to Beta 4 and put back data-app="public" in hope that this "not a bug" is fixed in Beta 4 and there will be no drop down.

2k.webp
 
Nothing was changed in Beta 4 which simply further goes to demonstrate there was never a bug to start with.

A couple of things:

1. When we say a release is unsupported and we recommend not to run it in production, we hope that you will heed that valuable advice in the future.

2. The only bug has ever been with Lighthouse itself, as we stated from the start, but I am glad we were able to workaround it.
 
Nothing was changed in Beta 4 which simply further goes to demonstrate there was never a bug to start with.
so the 3rd dropdown after I put data-app="public" and the 3rd raise after I remove it will not ring any bell?
ok, no prob. I'll just wait when you release gold (or how you call it) and people start inform you about this bug, that "was never a bug".
1. When we say a release is unsupported and we recommend not to run it in production, we hope that you will heed that valuable advice in the future.
I understand that a model "I'm OK he's not OK" is comfortable. But "not recommended" is not "prohibited".
And I have no problems with running my production forum on 2.2. Beta - traffic the same, earnings the same, no complains from members.

If you are not interested to see this type of information about your software performance, I will not show it further.
 
Valid mobile friendly pages went from 2.02k to 1.6k in 2 days. I know that it means nothing to you, so here's another one.
I go to Seach Console/ URL inspection/Test live url and I get "Something went wrong. If the issue persists, try again in a few hours" error for any my forum page (pages from my other sites are tested just fine). I deleted data-app="public" and url testing started to work without errors.

I already know the answer: "nothing wrong with xF2.2, it's Google's problems", but you already applied a fix for lighthouse requests, may be you could also apply a fix for google mobile crawler reguests?
 
Valid mobile friendly pages went from 2.02k to 1.6k in 2 days. I know that it means nothing to you, so here's another one.
I go to Seach Console/ URL inspection/Test live url and I get "Something went wrong. If the issue persists, try again in a few hours" error for any my forum page (pages from my other sites are tested just fine). I deleted data-app="public" and url testing started to work without errors.

I already know the answer: "nothing wrong with xF2.2, it's Google's problems", but you already applied a fix for lighthouse requests, may be you could also apply a fix for google mobile crawler reguests?

Similar issue with a workaround:

There is no doubt Google currently has an issue with this line in the the PAGE_CONTAINER template:
Code:
data-app="public"
 
It still isn't a bug in our code. I will continue to say it.

As has been posted elsewhere this is the bug that is tripping Lighthouse and other Google tools up:

Anything that uses "Headless Chromium" can crash if the application attempts to access the Badging API. Removing that data-app="public" line prevents XF from using the Badging API that crashes Google's internal tool browser instance.

If you want to do something productive, I suggest posting on the link above and not here. This cannot be completely fixed until they fix it.

If, in the meantime, you want to workaround it, indeed you may wish to remove that line from the template. We may be able to workaround the issue further if we can conclusively ascertain which user agents are relevant and we will do that if we can as we did for Lighthouse but we're very much at their mercy otherwise.
 
I noticed something weird today. Google Search Console shows an error when you submit a URL manually for indexing. This was not happening on 2.1. So I am guessing the same bug is affecting Google Search Console as well. Indexing is happening as usual (slow but pages do get indexed in 24 hours) so it's not like indexing is not happening otherwise. This is a minor annoyance as I like getting important new threads indexed manually (coz automatic takes time) but not a big deal.
 

Attachments

  • Staid Squamata.webp
    Staid Squamata.webp
    5.8 KB · Views: 14
It still isn't a bug in our code. I will continue to say it.
While this is definitly true, I do understand the concerns about headless chormium crashing.
If Google does use this internally (apart from things like Lighthouse/PageSpeed Insights, etc.), it might indeed be a bigger issue (for indexing).

Maybe it might be a good idea to no only disable the triggering code for specific user-agents but for all crawlers/bots and clients with navigator.webdriver being true.
 
It still isn't a bug in our code. I will continue to say it.
As a forum owner, I am not interested to find out who's the fault is it, but rather how to fix it. Bearing in mind that your one-month-old message still got no answer on that bugs.chromium page, here is my question: maybe to leave the idea to turn xF into PWA for now?
Or as an option to place in ACP a big switch "Turn PWA OFF". )
 
It seems to be a good idea to remove data-app = "public" even under XF 2.1.x. (If Google services have to be used)
Since I did this today under 2.1.x, the number of visitors has increased dramatically again.

Thanks @Anatoliy :D
 
There are no code paths in XF 2.1 that would be affected by removing that in the context of this issue.

This issue is caused exclusively by the Badge API (introduced in XF 2.2) and an issue with the headless Chromium Google uses for many of its internal tools.
 
The issue still exists and will continue to exist until the aforementioned Chromium bug is resolved. It is possible for some internal tools to not flag themselves as a web driver properly (thanks for that @Kirby) and it's possible for Google's tools to be using a custom user agent that we're not yet detecting.

But for now we've worked-around it and hopefully that solves the bulk of the issues arising from it.
 
Solution
Top Bottom