Page Experience/Core Web Vitals: Browser errors were logged to the console

[Bukashk0zzz]

Regarding the old issue #328 there is a problem that if the user is not logged in API responds with a 401 error.

Google uses a lot of metrics to range sites. And now, not only Page Speed matters, but also user experience. More info:

• https://developers.google.com/search/blog/2020/11/timing-for-page-experience
• https://developers.google.com/search/blog/2021/11/bringing-page-experience-to-desktop

Using https://web.dev you can check the issues you have on the page. That's the new google page speed. Logging errors to the console is one of the official issues.

Example for page https://radio-t.com/p/2021/11/30/prep-783/:

p.s. Also, some other console/SSL errors found on this site relates to not using GTM Server Side. Some of them you can fix with the correct policy headers, but not all of them.

[akellbl4]

I don't know what's wrong with the 401 code from the server. I mean it's a legitimate response that couldn't affect any metrics. Other errors are relative to the radio-t site.

[umputun]

401 is really strange one to penalize for. is it even smth we write to console? i thought this was reported by browser itself.

Theoretically we can provide some workaround if absolutely necessary. I'm not sure what call ui does to figure login status, but we can change /me method to always return 200 and "not logged in" in json body. To me it sounds kind of silly as I don't get what is wrong with the good old 401

[Bukashk0zzz]

I understand your feelings, but that's what we have. And it's hard to argue with SEO specialists as google tool explicitly shows a red warning regarding this.

Making /me endpoint always return 200, at least will save some of our colleagues from new tickets/discussions in Jira ;)

But mainly web.dev is an excellent resource and tool overall. It mutch better than old Google Page Speed and shows a lot of correct issues/suggestions for the site.

[akellbl4]

And it's hard to argue with SEO specialists as google tool explicitly shows a red warning regarding this

If it shows some warnings it doesn't mean that it affects any metrics. Now Google Chrome shows all of the console errors in the reports.

After a quick research, I haven't found any mention of status codes affecting performance or SEO optimizations.

P.S. If a SEO specialist shows any data to me I would like to have any confirmation about his statements about that data. Otherwise, we can identify any problem as a problem that affects SEO.

[akellbl4]

This is what is really important from the whole report for SEO

https://pagespeed.web.dev/report?url=https%3A%2F%2Fradio-t.com%2Fp%2F2021%2F12%2F04%2Fpodcast-783%2F

[umputun]

i have added /status method to go-pkgz/auth

regardless of what we do about this ticket, having a way to check logged in status this way (i.e. GET with 200 and a different "status" value in the json body) can be handy

[Bukashk0zzz]

This is what is really important from the whole report for SEO

That's was true for a while. But for mobile this changed year ago and for desktop users it will be changed in February, 2022. More info https://developers.google.com/search/blog/2021/11/bringing-page-experience-to-desktop And one more https://developers.google.com/search/docs/advanced/experience/page-experience

Basically, Core Web Vitals now is only part of the new Page Experience ranking.

However, after some research, I also can't find direct confirmation from Google that console errors relate to SEO ranking. In any way maybe make one issue less on the web.dev report is a good idea? There are no any drawbacks of this as from my point of view.

After a quick research, I haven't found any mention of status codes affecting performance or SEO optimizations. If a SEO specialist shows any data to me I would like to have any confirmation about his statements about that data. Otherwise, we can identify any problem as a problem that affects SEO.

I will ask about this for sure, but I think there will be no answer.

regardless of what we do about this ticket, having a way to check logged in status this way (i.e. GET with 200 and a different "status" value in the json body) can be handy

Thanks a lot. Now we need to do some small changes on the web and that's it :)

[paskal]

@akellbl4 since auth packages support checking the user with status code 200, let's switch to using it on the frontend side? It wouldn't hurt, and the 401 unauthorised error in the console is red herring I would like to get rid of.