Google no longer requires AMP, but the replacement might be worse
1–10 of 238 posts
Re: Google no longer requires AMP, but the replacement might be worse
#2Yes, I was prompted to plan turning off AMP for next month, even given CWV weirdness in GSC...
http://www.earth.org.uk/note-on-site-technicals-49.html#2021...
Re: Google no longer requires AMP, but the replacement might be worse
#3So the problem is that “Google is in charge.”
Sorry but I don’t think that’s “worse” than AMP at all. Google was in charge of that and it hijacked URLs.
Clickbait.
Re: Google no longer requires AMP, but the replacement might be worse
#4The replacement they're whining about is "core web vitals" IE the metric you can view at[1]. This is what AMP should have been in the beginning and I was surprised they did something else, it made Google search unusable on mobile.
[1] https://support.google.com/webmasters/answer/9205520?hl=en
This means that your hand-coded-in-vim static pages will rank near the top.
Re: Google no longer requires AMP, but the replacement might be worse
#5I find "Web Core Vital" to be fairly useless (outside of trying appease Google.) I can make a page load slower and feel worse for anyone visiting the site...and the "Core Vitals" score will increase. So, how is this about the user experience? You can inline all of your CSS to increase your score, but what about users that visit more than one page? Now they have larger payloads per page. Then at that point what is the point of rewarding all inlining, but then throwing a fit about not using a CDN with a long caching parameter? It's not consistent.
Why not just use overall page size and ttfb instead of this nonsensical metric that isn't a great measurement, in my experience, of website performance/user experience; outside of keeping everyone guessing what Google might do next, what's the point? I also find it extremely ironic that many of Google's own products are complete failures on the metric.
I've even found that you can trick the metric by essentially loading a blank page where a browser will feel the page is fully loaded, then having a delay that loads the page.
Re: Google no longer requires AMP, but the replacement might be worse
#6I vehemently disagree that "Core Web Vitals" would be worse. I'm as wary of Google as the author, but Google's page performance tools have a reasonably good history of staying in their lane of just measuring performance.
Having "page performance" as a non-trivial weighted factor in how pages are ranked just makes sense to me.
Even if CWV is somewhat flawed, I'd much rather optimize for that than give control of my pages to Google ala AMP.
Re: Google no longer requires AMP, but the replacement might be worse
#7In case you're trying to find what the replacement is:
> Unfortunately, there are problems with AMP's replacement as well. And those problems go right back to what was wrong with AMP in the first place: Google is in charge of it.
So the problem isn't core web vitals nor AMP itself, but the fact that everyone uses Google and they control the results on google.com.
We can now go back to our regularly scheduled discussion about how this is bad.
Re: Google no longer requires AMP, but the replacement might be worse
#8So the problem is that “Google is in charge.” Sorry but I don’t think that’s “worse” than AMP at all. Google was in charge of that and it hijacked URLs. Clickbait.
It's not just Google, it doesn't matter if the company in change is all sunshine and rainbows today, who knows what they will do tomorrow (looking at you freenode). Centralized level of control like this is anathama to the whole future of the web.
Re: Google no longer requires AMP, but the replacement might be worse
#9The replacement they're whining about is "core web vitals" IE the metric you can view at[1]. This is what AMP should have been in the beginning and I was surprised they did something else, it made Google search unusable on mobile. [1] https://support.google.com/webmasters/answer/9205520?hl=en This means that your hand-coded-in-vim static pages will rank near the top.
There is one metric where hand-coded-in-vim pages tend to do poorly, and that's cumulative layout shift. If you have images on your page (a reasonable assumption) and just stick tags in there, you can get dinged on cumulative layout shift because the layout will shift as images get loaded.
I use a somewhat hand-coded-in-vim approach, but there's some post-processing that adds width/height attributes to tags which mitigates this particular problem.
Edit: Not sure why everyone is telling me to add "height" and "width" attributes, because that's what I wrote in the comment, above. Just to explain how this works--the width and height attributes describe the "intrinsic size" of the image.
Re: Google no longer requires AMP, but the replacement might be worse
#10The replacement they're whining about is "core web vitals" IE the metric you can view at[1]. This is what AMP should have been in the beginning and I was surprised they did something else, it made Google search unusable on mobile. [1] https://support.google.com/webmasters/answer/9205520?hl=en This means that your hand-coded-in-vim static pages will rank near the top.
There is one metric where hand-coded-in-vim pages tend to do poorly, and that's cumulative layout shift. If you have images on your page (a reasonable assumption) and just stick tags in there, you can get dinged on cumulative layout shift because the layout will shift as images get loaded. I use a somewhat hand-coded-in-vim approach, but there's some post-processing that adds width/height attributes to tags which mit…
I would imagine it's best practice to define height and width attributes for tags, no?