[HN Gopher] AMP pages no longer get preferential treatment in Go...
___________________________________________________________________
AMP pages no longer get preferential treatment in Google search
Author : ColinWright
Score : 368 points
Date : 2021-05-18 09:27 UTC (13 hours ago)
(HTM) web link (plausible.io)
(TXT) w3m dump (plausible.io)
| nindalf wrote:
| The article talks about Core Web Vitals in passing. That's the
| major change here. Two posts from May 2020 talk about them more
|
| - https://blog.chromium.org/2020/05/introducing-web-vitals-ess...
| introduces these metrics, what they mean and how to measure them.
|
| - https://developers.google.com/search/blog/2020/05/evaluating...
| talks about how the search engine experience will change
|
| > The change for non-AMP content to become eligible to appear in
| the mobile Top Stories feature in Search will also roll out in
| May 2021. Any page that meets the Google News content policies
| will be eligible and we will prioritize pages with great page
| experience, whether implemented using AMP or any other web
| technology, as we rank the results.
|
| > In addition to the timing updates described above, we plan to
| test a visual indicator that highlights pages in search results
| that have great page experience.
|
| Seems like a positive change. It will mean extra work as
| developers improve the performance of their sites. But having
| clear metrics to improve will make that work tractable. Also,
| advocating for that work to senior management will be easier when
| it's so clearly tied to SEO.
|
| The upshot is that ordinary users will experience a more
| performant web. Not overnight but over a few years, like the
| shift to HTTPS and supporting mobile web versions. Both of those
| changes were driven in part by the desire for better ranking on
| Google.
| donohoe wrote:
| Yeah, but in reality most news sites will fail Core Web Vitals
| in their current state.
|
| Out of 71 tracked articles on news sites, only 3 or 4 score 85
| or higher in overall Performance as tested by Google
| Lighthouse.
|
| _Article Performance Leaderboard:_ https://webperf.xyz/
| partiallypro wrote:
| Or just Google's own products/services. They usually fail.
| Same with Apple, Microsoft, everyone. I don't like the "Core
| Web Vital" metric because it is possible to make your site
| load slower or in a non-pleasing way for users and improve
| your score.
| littlestymaar wrote:
| But despite its name, AMP isn't much help to improve your
| website's speed though, for instance the new Reddit website
| uses APM and isn't faster[1] than the old one by lighthouse's
| metric (and I find it significantly slower from a user's
| perspective).
|
| Semi-unrelated trivia: Google lighthouse's own website is a
| disaster[3] by their own standards (with a score of 28),
| which I find pretty ironic.
|
| [1]: https://developers.google.com/speed/pagespeed/insights/?
| url=...
|
| [2]: https://developers.google.com/speed/pagespeed/insights/?
| url=...
|
| [3]: https://developers.google.com/speed/pagespeed/insights/?
| url=...
| SquareWheel wrote:
| > for instance the new Reddit website uses APM and isn't
| faster than the old one by lighthouse's metric
|
| The AMP page will still load faster because it conforms to
| a spec which is known to be preload-safe. This means it can
| be served by services like search engines without any
| additional network activity, and with minimal layout
| calculations needed.
|
| Ultimately that's what AMP was designed for. It's more than
| just a head-to-head speed comparison.
|
| As a sidenote though, reddit's AMP implementation is
| horrendous for a dozen reasons. It's almost impossible to
| escape loading the real site, which is not at all within
| AMP's design guidelines.
| dmitriid wrote:
| > preload-safe.
|
| > served by services like search engines without any
| additional network activity
|
| You mean AMP pages egt preferntial treatment by Google,
| and all AMP-related Javascript (IIRC, almost 1 MB of it)
| is loaded the moment you search anything through Google.
|
| When you hit an AMP page, that JS is already preloaded
| and, true, there's "no additional network activity".
|
| I'd love for Google to serve my pages' Javascript as well
| when I search something, and get preferencial treatment,
| but alas.
| SquareWheel wrote:
| > You mean AMP pages egt preferntial treatment by Google
|
| Promoting pages in a carousel above-the-fold is
| preferential treatment. Preloading Amp pages however is
| not. This capability works with any implementation of an
| Amp Cache, including the one used by Microsoft's Bing.
| dmitriid wrote:
| In which world is preloading javascript needed to run a
| proprietary superset of HTML when you search for
| something not preferential treatment?
|
| Ah, I guess preferential treatment by Bing makes it
| alright. If we forget for a moment that Google has 92%
| market share among search engines.
| notatoad wrote:
| good
|
| the amp detractors have always said that we don't need amp
| because authors can just make their websites faster instead.
| here's the chance to see whether or not that's true.
|
| news organizations have generally terrible performance and
| deserve to be punished for it in search rankings.
| jeffbee wrote:
| Most of the junk at the bottom of the list combines hostile
| web development practices with criminal negligence of good
| journalism. If nobody ever visits sfgate.com again, that
| will be a benefit to humanity.
| bryanrasmussen wrote:
| >news organizations have generally terrible performance and
| deserve to be punished for it in search rankings.
|
| I wonder how this affects that Australian law about having
| to tell news sites about algorithm changes, etc. or maybe
| is affected by.
| agogdog wrote:
| They won't be punished because relevance is still vastly
| more important. A news startup isn't going to eat the New
| York Times' lunch by beating them with performance. _Maybe_
| you 'll see a little competition at the top, but I'm
| skeptical... there's not much incentive to do so.
| topicseed wrote:
| It is very true! Giants might move slower (as always) but
| most ad-powered websites have been working like headless
| chicken to get these metrics in the green.
|
| Granted, it's hard so some may be satisfied with orange
| metrics.
|
| But I've seen on all publisher-friendly communities I am in
| how much of an Earthquake the CWV Google Update has been,
| even if it is now pushed back.
|
| Let's hope more and more follow that trend because nobody
| hate a fast-loading site with good content!
| nindalf wrote:
| > even if it is now pushed back
|
| It was pushed back by 6 months, but it's live now.
| topicseed wrote:
| I meant to say Google using CWV as a ranking signal being
| pushed back, apologies.
| [deleted]
| baybal2 wrote:
| A simpler explanation.
|
| Google will eventually ban any big enough ad vendor
| tinkering too much with delayed loading.
|
| They, obviously, cannot ban themselves.
| filoleg wrote:
| >Google will eventually ban any big enough ad vendor
| tinkering too much with delayed loading.
|
| Delayed/deferred loading is supposed to improve page
| performance metrics, not degrade them.
|
| In light of this, I fail to see how you arrive at this
| conclusion after an article that essentially says that
| Google decided to de-prioritize AMP in search results and
| instead give top spots to well-performing websites
| regardless of whether they are AMP or not.
|
| If anything, this move encourages delayed/deferred
| loading for all non-AMP websites, because that's one way
| to improve your website performance and get your search
| ranking higher.
| watwut wrote:
| I personally hated amp, because then I got version of page
| without dark mode and with limited content instead of real
| one.
|
| I am actually fine waiting 200ms longer to get those.
| dheera wrote:
| It was often 10000ms for me, and there would be popups
| and paywalls that AMP circumvents.
| chrisacky wrote:
| Is the suite that you use to manage these tests available on
| a git repo by chance?
|
| I really like how transparent you've made: https://docs.googl
| e.com/spreadsheets/d/1sGKmbnW74u9r1GOzAQcI...
|
| And I wanted to run something similar but for our own network
| of sites. (If so you can reach me on my email in profile).
| Have about 400 sites to access.
| fenomas wrote:
| How is that data compiled? Just poking around, the worst site
| in the list (SFGate) seems to have gotten a "1" for
| performance every time it's been tested, but when I try
| checking the same link in lighthouse (mobile mode) it scores
| 55~60.
| topicseed wrote:
| CWV metrics are gathered and aggregated from field data
| with the variety of devices and internet speeds you would
| expect in the wild.
| fenomas wrote:
| I was asking about the lighthouse results in the link in
| GP's post, is that what you're answering?
| topicseed wrote:
| Oh, my bad! Last time I checked, Lighthouse in Chromium
| used (by default) a Moto G4 on a mobile network
| simulation.
| donohoe wrote:
| Uses Google Lighthouse. Takes average of last 3 days worth
| of tests. Each site usually tested 1-2 times per day.
|
| All the data is here:
|
| https://docs.google.com/spreadsheets/d/1sGKmbnW74u9r1GOzAQc
| I...
| katzgrau wrote:
| Some of the metrics they judge are things that AMP basically
| implements for you, and are a pain to implement otherwise.
|
| Cumulative Layout Shift is one of those things. Content blocks
| on the page need to have a fixed height, not one that is
| dynamic (which might happen with lazy-loaded content).
|
| For some use cases, conditionally loading content (one of those
| being ads) becomes difficult/impossible if you're using a third
| party system and can't render server side.
| [deleted]
| [deleted]
| rado wrote:
| Good riddance.
| iou wrote:
| Is the AMP strategy to be that the internet dislikes it so much
| that we're willing to pay to not see it? :thinking:
| pwinnski wrote:
| The complaints of web users still have power for now.
|
| Slow, tracker-laden web pages are still terrible, AMP was just
| the wrong solution.
| ridaj wrote:
| It was the wrong long-term solution for sure. But I think it
| forced publishers to reevaluate their priorities with respect
| to bloat and loading times, whereas prior attempts at quietly
| calling attention to the problem apparently didn't make a shred
| of difference...
| criddell wrote:
| AMP pages no longer get preferential treatment explicitly,
| but I'm guessing time-to-load is still a signal that is used
| by the algorithm.
|
| I wonder if they have hard guidelines? Something like "your
| page should load and render in 1000 ms" on a broadband
| connection.
| hyperdimension wrote:
| 1000 ms for application/html. How far we have come...
| zentiggr wrote:
| When I remember getting BBS results faster... sigh.
| while (true) { Every available channel will
| fill with every available amount of content until the SNR
| gets so low that a different channel is created.
| }
| Fordec wrote:
| I get the sense that the only reason this happened is because
| amp sites were returning less advertising revenue for sites
| implementing it vs regular web. If the money was the same or
| better then I can't assume it would have ended up this way.
| kemonocode wrote:
| I agree, and whenever I bring up that web designers can do
| anything but wrong, I've been piled up on before.
|
| I'd still take a mildly broken AMP page to read an article over
| the "intended experience" with ads and trackers everywhere and
| any attempts to block them would break the page further.
| josefx wrote:
| > and any attempts to block them would break the page
| further.
|
| The fun part about ads and trackers is that they do not
| contribute anything functional to a page, so blocking them
| generally does not break anything.
| whoknowswhat11 wrote:
| Agreed - all the claims that AMP sites are slower / more
| bloated then non-AMP sites seemed like total nonsense to me.
| Maybe HN folks with blocking capabilities - but average folks
| like my mom, AMP was the place to be.
| mthoms wrote:
| I don't think that users complaints actually had any impact. It
| seems more likely that avoiding regulatory scrutiny was G's
| motivation in scrapping AMP.
| pydry wrote:
| User complaints do drive regulatory scrutiny, and Google will
| point to a lack of user complaints to try to justify its
| behavior.
| pwinnski wrote:
| Why not both?
|
| There are companies pushing the boundaries every day, with
| governments generally failing to even investigate unless
| there are enough complaints to raise attention.
|
| Complaints by themselves depend only on shame, which most
| companies seem to avoid easily. Complaints that catch the
| attention of governments, on the other hand...
| Angostura wrote:
| Perhaps, or they were seeing an uptick in DDG usage on
| mobile.
| MaxBarraclough wrote:
| As far as I can tell, Google have the power to essentially end
| web bloat at one stroke: introduce severe Google ranking
| penalties for bloated pages. Websites would soon get the
| message and cut down on bloat.
|
| Presumably the reason Google doesn't do this is that they'd
| have to punish many of the most popular websites, which might
| be seen as damaging the quality of their search results (at
| least in the short term).
| pwinnski wrote:
| Some of the bloat is very specifically Google's own ad and
| tracking code, so they are very much working at cross-
| purposes within Google.
| claudiulodro wrote:
| > introduce severe Google ranking penalties for bloated pages
|
| That's literally what they're doing with the AMP requirement
| change, no? Instead of giving priority to AMP pages, they're
| giving priority to any pages which have good performance.
| MaxBarraclough wrote:
| I'm not sure. The article does say:
|
| > _If you want higher rankings and more traffic from search
| engines, you need to optimize your site for a better, more
| performant and faster user experience._
|
| But wasn't this how things were meant to work _before_ AMP?
| Google search never had harsh enough penalties to seriously
| deter bloat, and I don 't know that they're going to change
| that, they're just going to remove the preferential
| treatment for AMP.
| kevin_thibedeau wrote:
| AMP pages are incredibly bloated with all the ad assets
| that slowly load in. Media sites browsed with aggressive
| JavaScript blocking are significantly faster.
| whoknowswhat11 wrote:
| I've repeatedly browsed AMP and non-AMP pages (without
| blocking as a normal user) - this is basically a total
| lie.
|
| The amount of crap on media pages (while they wail about
| privacy) is absolutely staggering. How many trackers do
| these folks need?
|
| I got to MSBNC - a place looking to take down this
| tracking panopticon system and they are shoving
|
| demdex taboola scorecardresearch tvpixel chartbeat sail-
| horizon condustrcts imrworldwide hotjar
| connect.facebook.net womanear.com mparticle.com
|
| etc.
|
| I mean, seriously - why not just use one (like google)
| and be done.
|
| Can anyone explain why the need so many beacons on a
| page?
| wilde wrote:
| I interpreted this as the downside of competition in the
| ad network space. Similar to "why do we need 4 cell
| towers on the top of this building" or "why does Boston
| have so many hospitals".
| adflux wrote:
| AMP was just a disingenious Google power grab all along...
| iandanforth wrote:
| I really really want this to be true. Unfortunately I can just
| see some ambitious PM picking this up again and trying to push it
| even harder. "The real reason the previous initiative failed to
| gain traction was insufficient market education."
| the_duke wrote:
| > There's been a lot of antitrust scrutiny on Google and it may
| have played a role in this change of heart.
|
| I'm pretty sure that's the primary reason, which won't change
| anytime soon.
|
| I'd also expect many publishers that adopted AMP to jump ship
| now, which means it will slowly die away.
| wkrsz wrote:
| I'd expect those ambitious PMs to pitch new projects that do
| the same thing under a new name.
| ikiris wrote:
| Always 2 there are: The not ready yet, and the deprecated.
| rodiger wrote:
| "This would be great as part of our new AMP Messenger!" Jokes
| aside, I wonder how one could measure above-average PM
| performance without tying it to product launches.
| whatshisface wrote:
| > _I wonder how one could measure above-average PM
| performance without tying it to product launches._
|
| By understanding the circumstances and work of the people
| you're managing, so that you can subtract confounding
| factors and separate their influence from everything else.
| There is absolutely no substitute for that, but because it
| takes actual work and attention, businesses the world over
| have been trying to replace it with paper thin metrics
| since time immemorial.
| bvanderveen wrote:
| Here's a non-AMP site that works great: https://text.npr.org/
|
| Speaking from experience, it loads lightning-fast even on an
| ancient Android device on nerfed 2G data roaming internationally.
| And the user experience can't be beaten.
|
| Make the web hypertext again!
| Dah00n wrote:
| Hmm, i seem to remember this being written by plausible before
| and posted here. Is this really an ad?
| amelius wrote:
| ... but we're still measuring page load speed, and hey, AMP is
| still faster in most cases.
| [deleted]
| rapnie wrote:
| AMP: The thing I wanted to go away like any other, but was never
| really exposed to with Firefox and DDG :)
| melomal wrote:
| Good riddance.
| joegahona wrote:
| This hasn't happened yet, so the title is misleading/clickbait.
| Also the notion that Google will (allegedly) no longer prefer AMP
| pages is old news.
| ec109685 wrote:
| "Your site can be faster than AMP without using AMP"
|
| That isn't true. Google is able to cache AMP pages in their CDN
| and preload and pre-render them in the browser or in Google News.
| You can't beat that with even the most optimized site.
|
| AMP, especially on iOS, is awkward for many reasons and having to
| support two formats by publishers isn't great, but it is
| unquestionably fast when rendered within a container that
| supports AMP.
| malinens wrote:
| you can easily beat downloading hundreds of kilobytes of amp JS
| stuff from supa-fast and mega-optimized google CDN by not
| downloading JS at all or using js very conservatively
| s17n wrote:
| That is not going to happen, though.
| ec109685 wrote:
| Google does all that in the background on the Google SERP
| page, so users don't feel that slowness at all.
| Seirdy wrote:
| The time to first paint for a smallish website from across the
| planet seldom crosses the two-second mark. I would happily take
| that over a website that fails to load from a server <100 miles
| from me because my packet loss is >40%.
| ec109685 wrote:
| Trick is that google w/ AMP does all the loading in the
| background, so it can hide hide the latency from you.
| heavyset_go wrote:
| Google should do the same for blog spam pages that are laden with
| AdSense ads.
| overcast wrote:
| First Flash, and now Amp. Sometimes good things do happen.
| king_magic wrote:
| AMP is web cancer. Looking forward to seeing it die.
| rchaud wrote:
| From the article:
|
| >> The Top Stories carousel feature on Google Search will be
| updated to include all news content. This means that using the
| AMP format is no longer required and that any page, irrespective
| of its Core Web Vitals score or page experience status, will be
| eligible to appear in the Top Stories carousel.
|
| It doesn't say AMP will not get preferential treatment, it just
| says your page doesn't have to be using AMP. Don't forget Google
| has Web Stories[0] to fill this gap as well.
|
| [0] https://stories.google/
| tyingq wrote:
| Unfortunately, AMP has a lot of inertia. I just tried a bunch of
| different queries on Chrome/Android, and all the carousel entries
| still have the AMP lighting bolt.
|
| Newspaper dev shops probably don't have the money to justify a
| standalone "get rid of AMP" project. So it will take a while to
| see some migration away.
|
| Anyone have a query that results in a carousel story that isn't
| an AMP one?
|
| Edit: Found one. "Biden Covid" results in an NPR story in the
| carousel that is not AMP.
| AS_of wrote:
| They say the update is coming in June.
| jepper wrote:
| Good riddance. A thinly veiled power grab to make the web a
| walled garden. Now lets do the obvious thing and just do
| preferential treatment for fast loading pages.
| petee wrote:
| Yes! I can't wait till its gone altogether. The whole AMP
| experience from an end user, really sucked. Pick a reason, but
| nearly every article always has something broken, missing, or
| misrepresented. Fifty percent of the time I would either need to
| click the original link, or give up on the content.
| kristopolous wrote:
| The pre-amp world was also completely utterly terrible though.
|
| Do you remember mobile news websites circa 2015? It was full of
| so much ad tech that if a site didn't make your phone hot and
| crash the browser the best experience you could possibly get
| would be a couple ad and email form click throughs, maybe a
| video fading in over the entire content like some trashy mobile
| app, followed by a scroll jack, a backbutton jacking, then more
| videos just magically appearing in between paragraphs pushing
| them apart like some kind of infestation, it was just utterly
| unusable.
|
| The text that you were lucky enough to catch would quickly fly
| up and down the screen as more ads start rendering and load in
| at every div tag with multiple jingles and voice-overs for car
| insurance and refinancing playing out of your phone all at
| once. You think "well maybe I really don't care that much about
| what that diplomat said after all". It was a complete waste of
| time. They were almost all like this as if there was some
| secret competition among the news sites, like as if some
| coveted award was at stake for the craziest most unusable
| experience.
| matsemann wrote:
| Until last year or so, Google intentionally gave a worse
| version of google search when using Firefox on Android. I
| installed a user-agent-spoofer to pretend to be Chrome, and I
| got the perfectly functioning page. But then I also got results
| including AMP links, so quickly disabled the extension and went
| back to the old ugly result page...
|
| 9 out of 10 times AMP pages in Firefox failed to be scrollable.
| Like the static/fixed top and bottom banner somehow screwed up
| scroll behavior.
| EForEndeavour wrote:
| I used to Google things on mobile and append `site:reddit.com`
| to filter out SEO-laden blogspam and zero in on the familiar
| confirmation bias of other reddit addicts. Then I had to
| tolerate the following antipattern of the modern web:
|
| 1. tap a Google search result link
|
| 2. tap the tiny "i" icon on the left side of the stupid AMP
| page header to display the actual URL of the page I'm trying to
| navigate to
|
| 3. tap the displayed URL itself in the AMP header
|
| 4. close reddit's "this looks better in the app!" bottom banner
|
| 5. scroll down and tap "VIEW ALL X COMMENTS"
|
| So fast. So _usable._
|
| On the bright side, this rigmarole has really done wonders for
| my productivity because I've simply stopped bothering.
| raldi wrote:
| I don't go anywhere without my "turn off AMP" and "kill
| dickbars" bookmarklets.
| acqq wrote:
| Can you publish them please?
| kevin_thibedeau wrote:
| You could've just used Firefox and old Reddit.
| mwaitjmp wrote:
| Very true.... I've suffered the exact same process for years.
| Step 2 is the worst, not sure why but sometimes it's
| incredibly hard to tap the i button.
|
| New reddit is is a very strange design. I always thought the
| way it hides comment threads as a link to a new page was just
| a mobile thing, but no, that's the design.
|
| The old site is so so much better. Trying to get to it from a
| google search is infuriating, especially if you are trying to
| view multiple results. Imagine doing the above steps 5 times
| for 5 different results!
| GuB-42 wrote:
| Reddit mobile is deliberately terrible, amp or not. They want
| you to use their app.
|
| Use "old.reddit.com" (old style, best on desktop but ok on
| mobile) or "i.reddit.com" (minimalist, for mobile) if you
| want something usable.
| kevincox wrote:
| If you log into Reddit you can configure reddit.com to use
| the old interface. (at least for now).
| Stratoscope wrote:
| That works on desktop, not on mobile.
| ewindal wrote:
| Sure it does. I'm defaulting to old reddit without old in
| the url while browsing on mobile.
| p49k wrote:
| Yes, but every couple days it switches back and you have
| to "request desktop site".
| saagarjha wrote:
| Sadly Reddit has been A/B testing changes where they decide
| to hide the X button in that banner.
| OJFord wrote:
| > close reddit's "this looks better in the app!" bottom
| banner
|
| I hate that. It's self-fulfulling really isn't it, may as
| well simply read 'this banner not present in the app'.
|
| A bit like those joke signs warning you not to steal/deface
| the sign.
| cube00 wrote:
| At least they stopped with the "you deserve the best"
| mhh__ wrote:
| It is better in the app, just usually not one of their
| creation...
| clydethefrog wrote:
| I am also happy the AMP reddit links are gone - because it
| was a way to bypass my reddit block on my phone.
|
| To get a quick readable version you always add a i. to the
| URL, so i.reddit.com. I am afraid of the day they will remove
| that.
| Tsarbomb wrote:
| Thank goodness.
___________________________________________________________________
(page generated 2021-05-18 23:01 UTC)