[HN Gopher] AMP pages no longer get preferential treatment in Go...
___________________________________________________________________
AMP pages no longer get preferential treatment in Google search
Author : ColinWright
Score : 610 points
Date : 2021-05-18 09:27 UTC (1 days 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.
| piva00 wrote:
| I don't understand how this isn't a rehash of Google's
| PageSpeed push during early 2010s. I do remember having to do
| the same kind of procedure to get better SEO: measure against
| PageSpeed's metrics set and optimise the bad results.
|
| This looks just the next step after PageSpeed and I have no
| idea why Google didn't push this before the whole debacle with
| AMP, such stupidity but expected nowadays from the tech
| giants...
| jefftk wrote:
| In the 2010s, PageSpeed Insights' metrics compared to your
| site to how it could be if it was delivered optimally. Did
| you compress your images? Have you combined your CSS files?
| Are your static resources longcached? A huge site perfectly
| delivered would score high, while a tiny site sloppily
| delivered would score low. They represented how much room for
| improvement your site had if you didn't want to make deep
| changes.
|
| Search was doing its own thing, and they didn't ever have any
| public speed metrics.
|
| Core Web Vitals is a different approach: pages are compared
| to thresholds. A huge site perfectly delivered now likely
| scores _lower_ than a tiny site sloppily delivered.
| (PageSpeed Insights now reports CWV metrics.) These are the
| kind of metrics you can use for search ranking, because they
| are about user experience instead of developer room for
| improvement (low-hanging fruit).
|
| (I used to work on mod_pagespeed, which would automatically
| optimize sites, and I still work for Google. Speaking only
| for myself.)
| michaelbuckbee wrote:
| Thanks for the clarification here, but I wanted to confirm
| that when you're talking "huge site" and "tiny site" that
| this referring to the overall page load size and not the
| number of pages on the site?
| jefftk wrote:
| Yes, sorry, I should've said "page" instead of "site"
| michaelbuckbee wrote:
| Awesome. Thank you!
| mattmanser wrote:
| They've done a stunt like AMP before too, when they tried to
| get everyone to use their hashbang standard.
| r00fus wrote:
| s/stupidity/greed/
|
| You know it's true.
| 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=...
| ehsankia wrote:
| Everyone always brings up Reddits shitty implementation
| whenever they want to complain about AMP. AMP was never
| made for the kind of content reddit serves, it's more for
| static content like news articles. Reddit's mobile web
| version is shit in all sorts of way, and it's clear that's
| intentional to push people towards the app. You can tell by
| the huge damn banners that show up every single time
| blocking the content, no matter how many times you dismiss
| them.
| josefx wrote:
| reddit lets you choose freely between various frontends,
| I only ever use old.reddit.com, there is also
| i.reddit.com which as far as I understand is an
| alternative mobile frontend.
| 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.
| some_random wrote:
| As much as I hate AMP (well, google specifically), you're
| right. News orgs will never, ever fix their heavy ass
| webpages unless they're forced to.
| 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.
| lrem wrote:
| Is that law in? Being a Googler I kind of can't imagine
| search working well under it. Would be an absolute
| spamfest.
| ehnto wrote:
| It is in place I believe, Google made some concessions
| and workarounds.
|
| https://www.legislation.gov.au/Details/C2021A00021
|
| https://about.google/google-in-australia/an-open-letter/
|
| Everyone loses, frankly. It was one monopoly versus
| another, and the Australian people were never a concern.
| lrem wrote:
| That reads as "we agreed to send some money", not "we
| agreed to delay ranking changes by 4 weeks". The latter
| is the interesting part, as it is incompatible with the
| reality of needing thousands of algorithm updates per
| year.
|
| Edit: ah, there's now a provision for this:
|
| > (ii) if the change relates to a matter of urgent public
| interest--no later than 48 hours after the change is
| made; and
| ehnto wrote:
| With AMP they just offload their concerns to Google, and I
| assume they will stay doing that. They have no alternative
| to their ridiculous ad-tech burderns so I can't see it
| changing.
|
| But who this does help is websites who are capable of
| producing a fast experience and don't rely on a dozen ad-
| tech companies snippets, which will tend to be the smaller
| sites.
| donohoe wrote:
| There is still an incentive for publishers. AMP typically
| showed lower CPMs on ads, and it is possible to have
| faster loading pages than AMP with ads. Just look at
| DotDash and their range of verticals.
| 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.
| thatwasunusual wrote:
| > news organizations have generally terrible performance
| and deserve to be punished for it in search rankings.
|
| Shouldn't the quality of a site's _content_ count more than
| its performance?
| ehsankia wrote:
| Obviously Google search isn't going to give you an
| article about Oranges when you query for Apples, but when
| there's a ton of articles about Apples, having a website
| with better performance will rank higher. It's unclear
| how the knobs are tuned, Google's ranking algorithm
| definitely has a lot to it.
|
| All that is a bit irrelevant, this whole thing is about
| the news carousel specifically, which is basically
| showing a bunch of articles in a carousel at the top of
| search results. Previously only AMP articles showed, now
| I'm guessing you need some minimum threshold of
| performance. Seems reasonable, you don't want really slow
| pages that would push away users.
| betenoire wrote:
| All else equal, it should. Delivery matters too though,
| since inaccessible content isn't really useful content
| [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.
| baybal2 wrote:
| I my experience google habitually bans just anything
| seemingly tinkering with ad loading code
| 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.
| missblit wrote:
| AMP actually supports paywalls:
| https://amp.dev/documentation/components/amp-access/
|
| This extension is also actually kinda interesting in that
| it embeds a small domain specific language [1] that's
| interpreted with a lex-style parser in JavaScript.
|
| This can itself be a bit heavy on the CPU if a website
| uses it too judiciously!
|
| [1] https://github.com/ampproject/amphtml/blob/main/exten
| sions/a...
| goodcanadian wrote:
| It's fascinating to me as I moved away from Chrome on
| mobile specifically because amp caused me so many
| problems. The solution to page load failures was always
| editing the URL to give me the original which worked so
| much better.
|
| Hear that Google? The experience was so bad that I
| changed browsers to avoid it.
| 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.
| mfontani wrote:
| Would it be possible to add tech news sites to the list? I
| see you've the onion, but no engadget or ElReg.
| 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...
| fenomas wrote:
| That's the data I asked about. That data shows SFGate
| repeatedly getting a 1, but when I try the same test it
| gets 55-60?
| p49k wrote:
| There is no one lighthouse number. The site is likely
| using their own scores that are based on (but not direct
| averages of) lighthouse. Perhaps they give a score of 1
| to the lowest site and scale up.
| fenomas wrote:
| We're talking about the numbers that show up in the
| results of a lighthouse "performance" test. The overall
| score, total blocking time, time to interactive, etc. The
| spreadsheet has columns for all those values, and it
| shows SFGate consistently getting a "1" as its overall
| score.
|
| (It's "0.01" in the sheet, as I guess it considers the
| scores percentages.)
| [deleted]
| [deleted]
| 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]
| amcoastal wrote:
| Am I the only person who experiences longer load time on amp
| pages? I literally have to click the little paperclip at the top
| of an amp page to go to the regular one to load in like 50% of
| the time. Is it because I use Firefox or something?
| contriban wrote:
| I hope newspapers actually look at the alternative though. Some
| websites are so poor that I preferred sharing the AMP page
| instead of the original page since the article was not readable
| on the latter. That's right. It was so ad- and popup-infested
| that it was literally useless.
|
| AMP wasn't cancer; The web itself is. Visit some non-major or
| local website and you'll see they're absolute rubbish, especially
| those that work on the web, like news agencies.
| [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:
| Causality1 wrote:
| Great. Next can they no longer get preferential treatment in
| Chrome Mobile? By that I mean the way they hijack and hide your
| browser bar and stop you from accessing the tab manager unless
| you scroll all the back to the top of the page.
| 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.
| sellyme wrote:
| Google's ad/tracking code is generally measured in the tens
| of kilobytes. Compare that to e.g., the tens of _megabytes_
| that news sites routinely waste autoplaying videos on
| completely different stories to the one you clicked on.
|
| Google clearly already knows whether a website is primarily
| a text-based site or a video-based site, as it displays the
| two differently in search results. If they immediately
| blacklisted any text-based site with autoplay video from
| ever appearing on the first page of search results it would
| cut about 50% of web bloat overnight.
|
| Yeah they have competing interests when it comes to truly
| minimising unnecessary resource usage, but there's so much
| good that they could do without going anywhere near cutting
| into their own analytics.
| 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?
| s_fischer wrote:
| The biggest reason is that google doesn't provide the
| utility that each of these individual libraries brings to
| the table. Even if they did, there's nothing that says
| the total "omega tracking bundle" that you'd be
| downloading from Google would be any smaller than the
| aggregated total of these libraries. You'd definitely
| have fewer network requests but I'm not sure that would
| really move the needle as much as you'd want.
|
| While there is probably a bit of overlap, many of the
| above tools have very different use cases. For example,
| chartbeat is commonly used more on the editorial side for
| writers to track article performance but imrworldwide is
| a subdomain own by Neilson that they use to serve their
| sdk which offers metrics for preroll video ads. Hotjar
| provides user heat maps but sail-horizon is part of
| sailthru and used for email marketing.
| 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!
| aero-glide2 wrote:
| Nice web design. Now talking about the headlines itself, each
| and every headline is about a negative news story. If you only
| read npr you would think the world is on flames.
| r00fus wrote:
| https://text.npr.org/998241894
|
| That's good news.
| sellyme wrote:
| Possibly this was not there when you looked at it, but right
| now as I view the third headline in the list is as follows:
|
| > Congress Passes Bill To Counter The Rise In Anti-Asian Hate
| Crimes
|
| ...which despite the negative language is definitely a
| positive news story.
| SV_BubbleTime wrote:
| Is it a positive story? Sounds it!
|
| But... aren't hate crimes already illegal? Was there some
| Asian Exclusion that is being removed? Is this feel good
| legislation? Or is this also an example of "world on fire"
| narrative?
| sellyme wrote:
| The bill is providing more funding to prevention measures
| and resources for victims.
| myphs wrote:
| Wow! But what's up with the whitespace? Remove the max-width
| from body and it'll become the perfect website.
| ehsankia wrote:
| Great, you found one site that works great. Here's a million
| others that don't and take 10s+ to load on mobile. I'm not sure
| what your point is.
|
| The day every website out there makes fast and performant
| websites like the above without any stick or carrot, then you
| will have a point, but unfortunately we don't live in such a
| world.
| birdyrooster wrote:
| I missed the source to a million others. I haven't noticed
| this problem. AMP always seemed like a solution in search of
| a problem.
| Booligoosh wrote:
| Wow, I didn't know this existed! It seems way nicer than the
| "full site", I think even your average user would probably
| agree. The "full site" feels like nothing but a downgrade, it
| doesn't really add anything useful.
| aww_dang wrote:
| I wish they would look at the bloat in some of their own
| services. Analytics would be a good place to start.
|
| The team(s) attempting to incentivize page speed in the SERPS
| often seem to be working at cross purposes to other Google
| projects.
| 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.
| lmm wrote:
| > 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.
|
| Surely you can do that same pre-rendering yourself, and serve
| the result of it?
| playpause wrote:
| When you click an AMP result, your browser does not actually
| navigate away from Google's search result page. The search
| result page just dynamically updates its own DOM to show the
| AMP page content inline.
|
| Depending on how confident they are that you are going to tap
| a given result, they can even preload the actual content and
| render it as hidden DOM so it can be displayed the moment you
| release your finger.
|
| There is literally no possible way that a 'real' navigation
| (to a new page on a different domain) can compete with a
| simple DOM update.
| 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.
| willhinsa wrote:
| X to doubt
| king_magic wrote:
| AMP is web cancer. Looking forward to seeing it die.
| sharken wrote:
| To me AMP is a way of accessing news that would otherwise be
| blocked off.
|
| Other than that i have no real interest in AMP as an end-user.
| 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.
| petee wrote:
| I do recall, but the problem is the of the list of prior-
| issues you present, half those issues still persist in AMP,
| minus motion/fading effects. There are still so many ads it
| bogs down; ads break up content; there are articles indicated
| as text but masquerading as videos surrounded by ads. Alot of
| AMP articles are simply a link telling you to continue to the
| full page! All seems like new forms of the same old.
|
| I'm not sure how its even possible, but I encountered one
| page I swear hijacked the back button.
| kristopolous wrote:
| The back button hijacking is easy. You can "push" something
| into the "navigation stack" and then detect the "state
| change" of the back button. There's a few pretty simple
| ways to do this without magic.
|
| The website you're thinking of that does it is slashdot,
| sorry for the bad news. It's long been merely a shadow of
| the past.
|
| Amp initially didn't allow JavaScript. It had a bunch of
| restrictions.
|
| I honestly think it was good people doing it for a good
| cause but then the corporate meat grinding machine had to
| process it and they turned it into a power play and data
| mining operation.
|
| Once again, the solution is inescapable both for /. and the
| goog; take big money out of tech. Every significant
| computer revolution basically started on that premise. Time
| to roll it again. Consolidated power breeds incompetency.
|
| Our most noble task in life is to make the necessary
| possible and then inevitable
| alisonkisk wrote:
| It's not AMP's fault that some sites refuse to limit
| themselves to AMP's good practices.
| 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.
| enos_feedler wrote:
| Isn't this just your average news site on the web though?
| 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?
| skunkworker wrote:
| On my iPhone I setup a shortcut that will take a reddit url
| and open it natively in Narwhal. It's very handy and I'm not
| a huge fan of the official reddit app.
| kevin_thibedeau wrote:
| You could've just used Firefox and old Reddit.
| nonpolitic wrote:
| To be fair, Reddit itself is mostly to blame for the UX
| hellhole it's become. AMP certainly doesn't help but they
| have made so many shortsighted decisions recently wrt app
| nags etc completely of their own accord in their ongoing
| weird push towards engagement/monetisation.
| 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!
| DocG wrote:
| I changed to FF mobile just because of amp..
|
| Ain't going back either, the URL bar is at the bottom. It's
| magical ^^
| 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).
| lmm wrote:
| No you can't, it will pretend to accept your preference
| and then randomly reset it after a few days.
| kevincox wrote:
| Weird. I've been using it for months with non-issue.
| Another comment suggested that maybe it doesn't last on
| mobile?
| wutbrodo wrote:
| I've used it for a couple of years without it resetting
| leviathant wrote:
| Anecdotally, that has not been the case for me. Logged in
| from any device, I see the old reddit.
| SV_BubbleTime wrote:
| For me on Safari, if I leave that tab open, ok, old for
| awhile. But if I open a new tab, I get the new garbage
| regardless of my "settings".
|
| Only option left is to find a content blocker for iPhone
| that auto-redirects www to old.
|
| It's really awful, but I'm hopeful these anti-patterns
| and other Reddit issues (because what is a preference
| cookie anyhow!?) accelerate alternatives.
| 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".
| alisonkisk wrote:
| And it forces a super wide layout that requires either
| zooming out microscopic font size or scrolling
| horizontally for every line of text.
| 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...
| SV_BubbleTime wrote:
| I wish people understood how much power and information
| apps installed on phones had compared to websites.
|
| "Nudging" to install an app you use to collect a ton more
| data because you intentionally broke the website is fucking
| evil.
|
| Maybe someone has a Reddit app that isn't a data mining
| jerk. IDK. But if not, I still prefer to give no one extra
| data over just not giving it to Reddit.
| 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-19 23:01 UTC)