[HN Gopher] Ignore AMP
___________________________________________________________________
Ignore AMP
Author : adamhearn
Score : 316 points
Date : 2020-12-21 19:09 UTC (3 hours ago)
(HTM) web link (meiert.com)
(TXT) w3m dump (meiert.com)
| evanb wrote:
| 3 days ago on a different thread I asked HN for a way to avoid
| AMP. [ https://news.ycombinator.com/item?id=25467112 ]
|
| User coldpie recommended [
| https://news.ycombinator.com/item?id=25467438 ] the firefox
| extension https://addons.mozilla.org/en-
| US/firefox/addon/amp2html/
| lwansbrough wrote:
| The answer is Core Web Vitals.
|
| I have spent countless hours doing real optimizations on a
| website with real traffic, without submitting to AMP (which I
| view as a disgusting move by Google and everyone involved with
| it.) (Traffic which, by the way, does not reflect the device
| profiles of what Google considers the "average" user, based on
| real vs. lab results in Lighthouse -- which is forcing us to work
| on issues that are not proportionally relevant to our business,
| though I will concede it's a positive improvement for us overall.
| But still an unwanted Google influence, like most SEO.. but
| moreso.)
|
| Core Web Vitals should render AMP irrelevant, and thus seeing as
| both projects are being pushed by Google, it's time Google takes
| AMP behind the barn. Unfortunately Core Web Vitals takes a pretty
| hard stance against bleeding edge technology like (Vue/React)
| server side rendering with client hydration. Anything beyond a
| todo app starts to see considerable main thread time during
| hydration which obliterates the Core Web Vitals scores. I predict
| with continued focus on CWV we will see: much greater focus on
| startup times for client side apps (including better hydration
| strategies), and maybe even some server-side only JS front end
| frameworks -- more aligned with the JAMstack idea (everything old
| is new again, yay.)
|
| As much grief as CWV has caused me, it is the correct solution to
| the problem of slow websites and its impending inclusion in
| Google's page rankings should have a positive impact on the
| overall health of the web.
|
| Why people who aren't being paid by Google continue to defend AMP
| absolutely baffles me.
| s17n wrote:
| > I have spent countless hours doing real optimizations
|
| > As much grief as CWV has caused me, it is the correct
| solution to the problem of slow websites
|
| Maybe core web vitals will succeed but I'm skeptical. A big
| part of AMP's success was ease of implementation. Sites with
| skilled, motivated, and empowered developers are going to be
| fine regardless of what technology Google tries to push. It's
| the other sites (ie, most sites) that I worry about.
| detaro wrote:
| AMP with a few tweaks as "here's a Google recommended ready-
| to-roll framework for doing fast mobile sites" is mostly
| fine, and as easy to implement technically. But probably hard
| to get companies to use if not "strongly motivated".
| bjt2n3904 wrote:
| > In 2018, my recommendation was to avoid AMP, to use AMP for the
| most relevant pages, or to use AMP only.
|
| What an excellent, mediocre, and/or bad recommendation!
| corytheboyd wrote:
| I'd rate them excellent, nightmare hellscape, and bad.
|
| The amount of work required to efficiently deliver a second
| version of your content sounds like such a horrible terrible
| idea. HN mindset about Google aside, something strictly AMP
| would likely be a easier to replace than the mess that tries to
| do both.
| tyingq wrote:
| Heh, yes. Recommended you use none, some, or all. That's, uh,
| all possibilities.
| pvorb wrote:
| It's not the same as all possibilities. It's just arguing
| that you should avoid having an AMP and a regular version of
| every piece of content on your site. You should either go all
| in or avoid it entirely. And if you must provide an AMP
| version along with the regular one, only do it for the most
| important pages.
|
| The sentence is formulated really unfortunate, though. I also
| wouldn't approve it.
| edoceo wrote:
| It's the lawyer answer: "it depends...". Some of this "advice"
| takes a long time to say nothing.
| digdigdag wrote:
| Oh, besides the back-end technical mess that is AMP, just from
| the standpoint of a user, one can encounter catastrophic faults
| with its design:
|
| - can't share articles using android's builtin share widgets
| because it points to the amp pages
|
| - Navigating away using "Open in $BROWSER" option from the Google
| app in Android opens up the amp page again instead of the source
| page.
|
| - can't see embedded article widgets like tweet blocks, maps,
| overlays, animations
|
| - Attempting to do things like Comment on an article triggers
| navigation away from the AMP page to the actual site, forcing you
| to then scroll down once more
|
| I've become accustomed to opening AMP pages and looking for "View
| article on actual site" link as a matter of course. It's just so
| horrible.
| peanut_worm wrote:
| I don't even understand how AMP is legal or how they could
| possibly argue it gives any benefit to the user. Every single AMP
| page i've used has broken CSS and often broken content.
|
| The speed boost is negligible if it even exists and all it serves
| to do is add an additional stupid pop up I have to click out of
| to read a web page.
|
| I really wish I could switch to DDG but queries related to
| anything technical, like biology or programming, usually fail to
| turn up any relevant results.
| crazygringo wrote:
| I've literally never seen broken CSS or content.
|
| I'm assuming you must be running some kind of extension or
| blocker that is interfering?
|
| There are plenty of criticisms of AMP but failing to load
| content isn't really one of them. Also the speed boost is
| massive. AMP pages usually show content instantaneously due to
| precaching, while a new site takes 5-7 seconds to load.
| plorkyeran wrote:
| My typical experience with AMP on an iPhone SE2 running iOS
| 14 has been that it either takes 10+ seconds to load or
| simply never does. I am not using any sort of ad blocker.
|
| This obviously isn't the typical experience with AMP, but
| they clearly have something broken somewhere.
| mickael-kerjean wrote:
| That happens when you block AMP related resources from
| loading. When doing so, AMP makes the content of the page
| visible after 8s [1].
|
| source:
|
| 1. https://amp.dev/documentation/guides-and-
| tutorials/start/cre...
| mrtranscendence wrote:
| That's not my experience at all, at least on iOS. I notice
| essentially no performance improvement when accessing AMP vs
| when I inevitably choose to load the non-AMP site because AMP
| sucks terribly.
| lern_too_spel wrote:
| It's more likely that mobile Safari sucks terribly. On
| Android, loading an AMP page from a Google or Bing results
| page is instant.
| crazygringo wrote:
| So which is your experience? I'm quite curious.
|
| Is it that AMP sites also take 5-7 seconds to load?
|
| Or that native sites load instantaneously?
| kall wrote:
| You must not be using iOS.
| crazygringo wrote:
| I am using iOS.
| stetrain wrote:
| Why wouldn't it be legal? Every site that uses it has to
| specifically add it and opt-in. Sites are willingly
| implementing AMP pages and telling Google etc. that the page
| exists and can be cached/served as an alternative to the
| original page link.
| tristan957 wrote:
| Google _was_ pushing sites that used AMP higher in search
| results.
|
| They are currently facing lawsuits in court in both the US
| and EU I believe for anti-competitive practices, AMP being
| one of them.
|
| * Google no longer treats AMP pages as special as of a few
| weeks ago.
| mkl wrote:
| It looks like Google still treats AMP pages as special, and
| will for a few more months, as _announced_ a few weeks ago:
| https://developers.google.com/search/blog/2020/11/timing-
| for... https://searchengineland.com/amp-wont-be-required-
| for-google... https://themarkup.org/google-the-
| giant/2020/11/19/as-antitru...
| stetrain wrote:
| Yes, the favoritism in search results for sites using your
| own tech could definitely be an antitrust issue.
| creato wrote:
| I get that there are philosophical issues with AMP and respect
| and agree with many of those, but I don't understand how people
| claim with a straight face that it's worse from an end user
| perspective. Even setting aside load speed, it fixes my top two
| pet peeves:
|
| - Content moving around for a few seconds after the page loads
| (and of course right when I go to click on something).
|
| - No auto-playing audio.
| nr2x wrote:
| I'm curious what types of programming questions you can't get
| via DDG? I use it exclusively and very rarely have to look to
| Google (as in <1x month). Really the only time I revert to
| Google is if the issue is very fresh (eg some new iOS bug from
| the past 24hr). Also, you can prepend search with "!so" on DDG
| and go straight to Stack Overflow.
| coldpie wrote:
| It's pretty bad at stuff like symbols. Searching "c ++
| operator" in DDG returns a bunch of "operators in C" results
| like [1]. On Google, the first two results are pages about
| increment and decrement operators.
|
| [1] https://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B
| nr2x wrote:
| Thanks, that's a helpful example, may be most of my
| programming questions don't involve C++. ;-)
| spijdar wrote:
| For a contrasting anecdote, when I'm traveling abroad and
| sometimes get stuck with 20-50 kb/s transfer speeds, AMP is the
| difference between waiting an incessant amount of time and
| getting pretty instantaneous loading.
|
| On fast internet? Yeah, negligible. On non US/European
| internet, though, it's very tangible.
|
| Just my experience, though.
| peanut_worm wrote:
| What websites are you noticing better performance? I usually
| encounter AMP on reddit and, at least on my phone, it seems
| to make the page load even slower.
| lern_too_spel wrote:
| Reddit doesn't have its own AMP cache, so you won't get any
| prerendering benefit.
| spijdar wrote:
| On basically anything that uses it. I'll give an example
| from the google feed on my phone, now. Some article on
| zdnet about RedHat discontinuing CentOS in favor of stream.
|
| If I open the AMP link [0] in Firefox and measure the
| bandwidth used, it's around 685 kilobytes transferred in
| 1.32 seconds. The original article transfers almost 3.6
| megabytes over 3.89 seconds, with the page taking almost 9
| seconds total to load in, vs only 1.43 seconds total on the
| AMP page.
|
| This is on my residential internet on an 8 core, 32 thread
| POWER9 workstation. My internet isn't great, but it's a
| heck of a lot better than the 15-40 kb/s I got overseas.
| There, that full page would take almost 2 whole minutes to
| load, versus only 20 seconds.
|
| Obviously, there's more to this -- the non-AMP page loads
| its text before the other elements, so it's not like you'd
| have to wait the entire 2 minutes to begin reading. And
| beyond the technology, there are other reasons to not use
| AMP.
|
| But suggesting we shouldn't use AMP because it's bad
| technology or broken isn't really telling the whole story.
| There are plenty of people who will get much better
| experiences with AMP than whatever fat pages would
| otherwise get shoved their way.
|
| We shouldn't become dependent on google for this, but we
| also shouldn't pretend like there isn't a need for AMP, at
| least for some people.
|
| [0] https://www-zdnet-
| com.cdn.ampproject.org/v/s/www.zdnet.com/g...
|
| [1] https://www.zdnet.com/article/why-red-hat-dumped-
| centos-for-...
| jbman223 wrote:
| It's easy to say "Ignore Amp" when you're not a content site that
| depends on Google Search to stay alive. Sadly, for a large amount
| of sites on the web, what Google says is what goes. Chasing a #1
| keyword ranking puts food on people's tables. It's not always as
| easy as "this thing is bad: stop using it!"
|
| There will need to be a bigger driving force to get amp out of
| popularity. As long as AMP pages unlock preferential treatment in
| search results (mobile carousels), sites that want to compete
| will be forced to use them.
| notahacker wrote:
| Maybe take a leaf from Google's history (the campaign against
| IE6) and ensure every AMP page includes a recommendation to
| switch search engine as Google is 'phasing out the ability to
| find webpages'. I'm only half joking...
| [deleted]
| mateus1 wrote:
| AMP is an anti-competitive abortion that should just die.
|
| It's Google throwing its weight to force websites into dubious
| practices all in favor of an alleged performance. Users also get
| the short end by being served low quality pages instead of the
| full experiences they expect.
|
| I have this extension [1] to make sure I never visit an AMP page
| again.
|
| [1] https://addons.mozilla.org/en-US/firefox/addon/amp2html/
| numpad0 wrote:
| AMP is WAP with flips
| emayljames wrote:
| The mobile web standard of old, not the CardyB version.
| GuB-42 wrote:
| It actually forces websites into _good_ practices. Maybe not
| the absolute best, but most of the times, the AMP site is just
| better, or at least, faster.
|
| People usually don't want a "full experience" when reading
| news. Especially when the "full experience" is pop-up ads and
| autoplaying video.
|
| The bad part about AMP is that it is tied to Google services.
| But once de-Googled, AMP is really good 99% of the times, I
| leave 1% for those web designers who really use their skills to
| provide a better user experience, and do it right.
| aardvark179 wrote:
| It appears to consistently break zooming and reader mode for
| me on iOS. From an accessory view point I cannot wait for it
| to just die.
| MrStonedOne wrote:
| > People usually don't want a "full experience" when reading
| news.
|
| But the question is do they want news sites to get promoted
| over the actual content they were looking for because news
| sites can be amped and dynamic content sites can not be
| amped?
| [deleted]
| sam_goody wrote:
| Anecdotally, I disagree.
|
| Considering all the extra JS it requires to preload, I also
| question it from a practical standpoint.
|
| Of course, if you are otherwise including 3MB of JS for no
| reason, and it isn't cached, and you aren't using a CDN,
| maybe, perhaps, Google's CDN might serve it faster..
|
| Though to be fair, I use FF, so AMP is hostile to it, and
| anyways FF has this great reader mode..
|
| But do you have any numbers to back up the claims that any
| AMP pages are _ever_ better?
| stetrain wrote:
| Yep, I actually like the idea of a narrow standard like AMP
| for fast loading content pages.
|
| The hosting/caching of those pages on outside caches is a bit
| more problematic, especially when it gets used by Google to
| de-emphasize the destination site in favor of flicking
| through Google results.
|
| I think the same idea implemented as a browser standard would
| have much better reception.
| Kalium wrote:
| > The hosting/caching of those pages on outside caches is a
| bit more problematic, especially when it gets used by
| Google to de-emphasize the destination site in favor of
| flicking through Google results.
|
| I think this gets at a core tension - there are _three_
| parties involved in a search results page. The search
| engine, the destination site, and the user. Each has its
| own set of incentives. Both search engine and destination
| site have this bizarre idea that they have some kind of
| root-given right to the user 's undivided attention for as
| long as they like.
|
| The user's interests are frequently poorly represented.
| They rarely include giving either search engine or
| destination site the amount of engagement each feels they
| deserve. Often, but not always, the search engine is
| somewhat better aligned with the user.
|
| > I think the same idea implemented as a browser standard
| would have much better reception.
|
| I personally have quite deep doubts. A standard like AMP
| works only because it can require adhering very strictly to
| a tightly written specification that blocks a lot of the
| things website authors want to do. I suspect AMP as a
| browser standard would produce a vast amount of forever
| broken webpages before publishers ditched it due to poor ad
| revenues and went back to their crappy, bloated, slow, ad-
| laden pages.
|
| The ability to load it into a CDN controlled by someone
| else - kind of a huge deal for performance reasons - is
| exactly the key feature that's user-friendly and hated by
| publishers. It's the kind of thing that would be cut out of
| a browser standard or just ignored by publishers.
| ryandrake wrote:
| > The user's interests are frequently poorly represented.
|
| The user's interests _should_ be looked after by the
| browser. A true "user agent" should act on behalf of the
| user's preferences, fetching only what the user says they
| need, and rendering it in a manner that the user wants,
| not necessarily how the web developer wants. We've gotten
| far away from this ideal over the years, with browsers
| ceding more and more control to web developers. Users
| have lesser and lesser say as to how their browsers
| render web sites, to the point where we now just have
| super-blunt instruments like ad blockers and "Disable
| javascript".
|
| If a web site is too slow, or choked with ads, or doesn't
| use an accessible color scheme, or uses a font too small,
| I want _my browser_ to do something about it. I don 't
| want to have to rely on the web developer (or Google) to
| adopt my own preferences. And if my browser even allows
| this, the function should be easy to use, not buried deep
| in Settings.
| Kalium wrote:
| I think there's a mismatch here that only becomes
| apparent when you consider what level each web service
| and the browser are operating on. Search engines and
| publishers are considering _intent_ - which is relatively
| easy because they have a small area over which to infer
| it. Browsers are operating as smart tools capable of
| interfacing but not capable of understanding intent
| because the scope of possibility is so broad.
|
| You're right. User agents should be _for the user_. They
| should expose options and controls _for the user_. They
| should tune and change and transform things _for the
| user_. They should understand what the user wants and
| make life easier _for the user_.
|
| I am just skeptical that browsers are ever going to be
| true user agents and capable of fully representing the
| user's interests and intent.
| lern_too_spel wrote:
| What is anticompetitive about AMP? Publishers publish in one
| format, and it is picked up by multiple link aggregators. It is
| the opposite of anticompetitive.
| LoSboccacc wrote:
| > Users also get the short end by being served low quality
| pages instead of the full experiences they expect.
|
| exactly this, it's WAP/WML all over again
| recursive wrote:
| In my experience, as a user, the performance improvement was
| more than "alleged".
| sequoia wrote:
| Isn't this at least in part because google was caching the
| pages & serving them (possibly pre-loading them, I don't
| know) from their own Google CDN? So comparing the speed of
| loading a performant page _from google 's CDN_ from a SERP
| click vs. loading the page from the origin is not really a
| fair comparison. My website would be faster if it were in a
| warm google CDN cache as well :)
|
| https://developers.google.com/amp/cache
| HALtheWise wrote:
| Yeah, but the only reason that AMP is able to preload the
| page from Google's (or Cloudflare's) CDN cache without
| leaking your information to the website is because of all
| the other design decisions.
| Drew_ wrote:
| This is another purported benefit of serving AMP pages but
| doesn't this imply publications weren't already using CDN's
| previously or that Google's CDN is much faster than
| competitors? I would guess neither of those are true.
| joshuamorton wrote:
| The entire design of AMP is such that amp links can be
| safely preloaded by the browser, making effective load
| times 0ms, dinner the content is already on your device
| when your click the link.
| wil421 wrote:
| Performance only improved for sites that have 5 or 6 ads
| going across your screen as you scroll and an autoplaying ad
| video taking up a good potion of the actual content.
| recursive wrote:
| In my anecdotal experience, non-AMP pages are/were strongly
| correlated with the type of ads you're describing.
| vineyardmike wrote:
| There was a recent article on HN that alleged that google
| slowed down non-amp pages (by delaying the execution of the
| link-click) in order to further amp's perceived improvement.
| selsta wrote:
| In my experience AMP website would always be missing features
| like comments or be bugged in other ways so I usually have to
| load the full website anyway. It just wastes my time and is
| one of the reasons why I switched away from Google search.
| admax88q wrote:
| 99% of the time I didn't want comments, I just wanted the
| content.
|
| AMP performance was a huge win for me as a user.
|
| I almost never wanted the "full experience" of a page. I
| wanted its core content, quickly.
|
| I agree AMP is anti-competitive, but if publishers made
| their default pages as lightweight as an AMP page _felt_
| then they would have far more of a leg to stand on with
| users in regards to it being anti-competitive.
| dbt00 wrote:
| That's all well and good when you're browsing search
| results, but then people copy and paste shitty amp links
| all over the place when they no longer have any
| advantages (because they're not precached).
| p49k wrote:
| Publishers can't make their default pages feel as
| lightweight as AMP pages because Google won't preload
| their content like they do with AMP pages.
| three_seagrass wrote:
| Both Bing and Google support preloading and prefetching
| HTML5 specs, independent of AMP.
| bradgessler wrote:
| I'll never understand why a search engine doesn't just adjust
| its ranking algorithms to penalize websites that load slowly
| and perform poorly.
|
| For example, why not rank https://lite.cnn.com/en above
| https://cnn.com/?
| colejohnson66 wrote:
| Supposedly, Google _does_ do that. It doesn't work that well
| when everyone is bloated though.
| impalallama wrote:
| It's also straight up bad for what it does. Like whenever I end
| up viewing an amp article on mobile half the time rather than
| scrolling down the page I accidentally swipe to the next
| article interrupting my reading.
| 8note wrote:
| Not to mention, only half the article is even visible, since
| anything paywalled doesn't have you logged in
| Causality1 wrote:
| Also AMP pages hijack Chrome Mobile's menu bar so you can't
| close the tab or switch to another one without scrolling
| all the way to the top of the page. That's straight up
| malicious.
| abhinavsharma wrote:
| For those of you on iOS, you can also disable AMP in Kiwi
| Browser (https://kiwibrowser.com/features/).
|
| But if you're looking for something more generally extensible
| to work around AMP and other things that make the modern mobile
| internet frustrating, we've been working on a browser for iOS
| that's extensible with low code/no-code extensions as well as
| JS.
|
| We're still beta testing (and launching early next year) but
| you can get the testflight beta from here
| https://insightbrowser.com/ and the AMP disabling extension
| here http://share.insightbrowser.com/8
|
| Would love feedback or any changes you'd like to make. Feel
| free to respond here or abhinav@insightbrowser.com
| rekabis wrote:
| The Kiwi browser does not exist in the App Store for iOS 14.
| abhinavsharma wrote:
| Good excuse to try the Insight beta instead :)
| chuckSu wrote:
| Agreed
| Triv888 wrote:
| Gmail should probably use amp because it is slow
| jimmar wrote:
| Before I even knew what AMP was, I saw the lightning bolt next to
| search results and I quickly realized that the lightning bolt
| mean that the site would load fast on my phone. I loved it. So
| many modern sites are hostile to usability, that part of me is
| sad to see AMP being attacked. I don't want Google to own the
| web, but I don't trust that web developers can stand up for sane
| usability practices anymore.
| tomgp wrote:
| In my experience it's generally not that web developers won't
| stand up for sane usability practices but (in most cases) they
| lack the political clout within organisations for their
| standing up for sane usability pracatice to have any impact on
| policy.
| AstroJetson wrote:
| I get 99% of my news from sites like these
|
| text.npr.org and lite.cnn.com
|
| Just plain text, if I want more, then I go look at the ad revenue
| site and I'm good to go. More news should be available to the
| public. And since you asked, I do send an annual donation to NPR
| to cover the usage of the text site.
| dmix wrote:
| Interesting he mentions both Baidu and Yandex have competing
| products to AMP:
|
| https://www.mipengine.org/
|
| https://yandex.com/dev/turbo/doc/concepts/index.html/
|
| They seem to work on similar principles.
|
| China and Russia will still have this issue as well.
| z3t4 wrote:
| Google could use dns-prefetch to tell the browser to to pre-fetch
| the DNS records for the domains in the top search results... That
| would decrease page load time up to one second! (the caching
| being the main advantage of AMP - it would make AMP unnecessary)
| Really, why are not browsers pre-fetching DNS records
| automatically for all links visible on the screen!?
| franze wrote:
| Why AMP exists?
|
| A website I consult in a popular sports niche and has a slow,
| broken, ad-infested main website grew its traffic 500% with AMP.
|
| On the main website, it's still broken. On AMP it's... AMP. So
| Google thinks it's fast enough/good enough.
|
| On AMP we implemented a lot of annoying CTAs to go to the main
| website. "Read Full Article here" "Read more" "Details at..."
|
| In the past this website would have needed to optimize its real
| website to gain this much visibility in the search engines. Now
| they just AMP, then they optimize their AMP to real-world-website
| CTR, and can continue to have a... sub ideal.... website.
|
| AMP is whitelisted cloaking for slow websites. And a burden on
| webmasters and developers.
|
| I always say AMP is the internet if germans (most AMP leads were
| at one point germans) would have invented it (I am Austrian, we
| always joke about Germans ): Efficient, mostly boring and long
| term innovation harmful.
|
| I am rooting for AMP to die. Sadly it will still be around for
| about 5 years until the "what a great journey" blogpost.
| adventured wrote:
| > Why AMP exists?
|
| So Google can push through a gatekeeping approach to further
| controlling online content. After you take hostages, then you
| decide what kind of ransom you want. It's how every monopoly
| tends to behave, they push outward leveraging their position
| and try to put as many defensive moats into place as they can.
|
| If speed was actually their concern, they happen to control a
| search monopoly that pretends to very much care about
| performance and speed. If any of that were really true, they
| can practically flip a switch and smash every slow site on the
| Web. Aggressively turn up the penalty on such terrible sites.
| In less than a year they'd all jump to and get in line, or they
| would die, banished from _all_ search results (sorry, your site
| sucks so bad we 're not even going to index that garbage).
| Google is happy to banish sites for political-ideological
| reasons based on the bias of their employees, but they can't be
| bothered for performance reasons? It reveals a lot as Google
| knows it would be easy to fix without AMP. Speed is not the
| primary agenda of AMP, control is; speed is an excellent cover
| story.
| echelon wrote:
| > So Google can push through a gatekeeping approach to
| further controlling online content. After you take hostages,
| then you decide what kind of ransom you want.
|
| Just like Apple.
|
| Fuck all of these companies. The DOJ needs to split them at
| the seams.
|
| Edit: damn these downvotes. I typed out an essay as a
| response to someone asking about the _Great Filter_ in
| another thread, and now HN is blocking me for posting due to
| getting so many downvotes.
|
| I hate the Apple users censoring everyone that disagrees with
| them or points out negative things about their company. It's
| a huge problem.
|
| The perfect analogy for Apple is the CCP. Developers have to
| behave exactly like Apple wants to distribute software, or
| they're toast. And Apple users rush to defend this. They're
| _" protected"_ by big Papa Bear Apple. They don't see this as
| a reduction of freedoms or strong arming. They got what they
| wanted and they're fervent about it, and they don't see the
| bigger picture.
|
| Apple isn't even protecting people. They're protecting their
| market lead. Apple users mean shit to them. They'd let us
| repair and install on our own if otherwise. The brand goes to
| people's heads just like other luxury brands (BMW, Dior,
| Gucci, etc.) - it's _a lifestyle_ that needs to be signaled
| and defended.
|
| Isn't it obvious that they're bad for the world?
|
| Liberty or death. When did we forget that?
|
| I really like Nintendo. I grew up with them. Zelda is the
| best thing ever. It's the Miyazaki of gaming. But you know
| what? They're fucking assholes to fans. They take down
| artistic endeavors that companies like Square Enix and Sega
| encourage. They're shutting down the vibrant Melee tournament
| scene. And for that, they've earned my scorn.
|
| You can like something your favorite company makes but also
| hate their actions.
|
| Apple isn't a loving mother. It's an enterprise and we're
| just users. They shouldn't have such power at their disposal.
| It's bad for all of us.
|
| The computing sector shouldn't be Apple's own private
| fiefdom.
|
| Exit since I still can't post responses:
|
| I'm taking this up with Lucy McBath (D-GA) instead. I hope
| that everyone else that sees the incredible harm Apple is
| doing takes an hour to write their legislators as well. Spell
| out the problem so they can understand it. Arguing with
| people online isn't as effective as getting the DOJ to
| address the problem.
| abestic9 wrote:
| That's a terrible analogy. Apple offers products and
| services to customers who with to pay for them. The CCP
| controls a region.
|
| With respect to the rest of your shotgun-spray of a
| commend, a similar argument could be made against people
| who hate on a company with no real measure of substance.
| f6v wrote:
| Does Google rank you better if you have AMP though?
| asab wrote:
| Google can't say this directly; forcing people to use your
| upsell for preferential treatment is likely anti-competitive.
| Instead, Google ranks on page speed (among many many factors),
| and then offer a proprietary tool (AMP) that promises to help.
| input_sh wrote:
| It still doesn't rank on page speed (it will start in May
| next year), and it's not _that_ hard to make your website
| faster than it would be with AMP.
| DeathRay2K wrote:
| It's similarly easy to make your website slower than it
| would be with AMP. Absent a performance advocate in the
| development team, the features that reduce performance are
| much more apparent and valuable to most businesses.
| [deleted]
| lern_too_spel wrote:
| > it's not that hard to make your website faster than it
| would be with AMP.
|
| How do you beat prerendered? Your definition of not that
| hard seems to match my definition of impossible.
| wazoox wrote:
| Yes they do. But monopolies suck and must be dismantled,
| anyway.
| [deleted]
| pvorb wrote:
| Yes, they give AMP content a dedicated area above regular
| search results on mobile.
| willio58 wrote:
| I work at a digital marketing agency and can confirm that just
| enabling amp on a site will increase SEO value significantly.
| DeathRay2K wrote:
| My conversations with Google reps and experience at an agency
| differ from this. My experience has been and Google reps have
| confirmed to me that a performant enough site will not
| benefit from enabling amp.
|
| It seems like they do assume amp pages are high-performance,
| but they're not the only way to achieve high performance.
| maxwell wrote:
| Any sources or data you can share on that?
| thrwn_frthr_awy wrote:
| Aren't AMP results above the traditional search results on
| mobile?
| dazc wrote:
| Yes, AMP alone will not improve your organic search
| results but why should you care when those results come
| after AMP.
| joegahona wrote:
| "Rank"? They claim no. But the mobile carousel is available
| only for AMP content, and that's actually _above_ the rankings.
| So it depends how you spin it.
| [deleted]
| [deleted]
| ldjb wrote:
| "When an AMP page is available, it can be featured on mobile
| search as part of rich results and carousels. While AMP itself
| isn't a ranking factor, speed is a ranking factor for Google
| Search."
|
| https://developers.google.com/search/docs/guides/about-amp
| ksk wrote:
| If speed was ever a major factor in ranking - the search
| results would be dominated by pages without trackers/ads/etc.
| Google would never do that.
| marcusjt wrote:
| Google announced back in May that Core Web Vitals would
| become ranking factors next year, and more recently they
| recently announced that this would happen in May 2021 (a
| year after the first warning)
|
| https://www.searchenginejournal.com/google-core-web-
| vitals-p...
| dgb23 wrote:
| Largest Contentful Paint is something I don't get at all.
| How is this helping overall performance? A fast and light
| site typically does well on this metric, but a site that
| does well on this metric isn't necessarily fast and
| light.
| donohoe wrote:
| I would add that when pages are built properly they can often
| be faster than their AMP equivalents.
| lern_too_spel wrote:
| Not when clicked to from a link aggregator that has its own
| AMP cache like Google, Bing, or Baidu. In that case, the
| AMP page will often be prerendered and load instantly.
| codeflo wrote:
| Isn't that almost guaranteed? As far as I can tell, AMP
| does three things:
|
| 1. It enforces some good practices / forbids certain
| expensive browser features.
|
| 2. It lazily loads images only when they are scrolled in.
|
| 3. It fucks up scroll-to-top and other scrolling behavior
| on iOS.
|
| The first you can do with or without AMP.
|
| The second doesn't cause anything above the fold to load
| any faster. If anything, you get an additional delay until
| content shows up when scrolling, because the browser was
| prevented from continuing to download the other images in
| the background.
|
| The third regularly causes me to be done with a site in
| just a few seconds, which I guess is an optimization of
| some kind.
| Sodman wrote:
| It's very achievable if you have full control over the
| site and you know what you're doing... However that's
| frequently not the case in many large companies.
|
| Many times it just comes down to something along the
| lines of these pages being run by non-technical folks in
| sales/marketing that are just click-to-adding
| widgets/plugins/tags every week without ever removing
| anything. As a result, you see a lot of very low-hanging
| fruit make it into the final production site. It's not
| unheard of to see a website of a household name brand
| load in multiple versions of the entire jQuery library,
| for example. I've personally seen a major site from a
| recognizable brand that otherwise loaded in <1MB, but
| then proceeded to load Google Tag Manager and pull down
| an extra 15MB of JS/images.
|
| My point is, I think you're discounting the "AMP enforces
| some good best practices / forbids some bad patterns"
| point.
| codeflo wrote:
| I might be, that's not a world that's familiar to me. But
| I think if Google had only done that with AMP, no one
| would have any issue with it.
| joshuamorton wrote:
| There's a few other things AMP does, it prevents a lot of
| repaints by allowing the browser to determine the layout
| of the page at initial load time. All content areas are
| predefined, so you won't have things change or your
| scroll position modified because some advertisement
| loaded 5 seconds in and suddenly you're scrolled up from
| where you were.
|
| 2 is also a bit of an oversimplification. It'll load
| images if they're likely to be scrolled to, which I
| expect is some heuristic based on distance below the
| fold, and it may cause above the fold content to load
| faster since it doesn't need to compete with below the
| fold content (on very fast connections this may not
| matter, on slower connections it probably does).
| cma wrote:
| > While AMP itself isn't a ranking factor, speed is a ranking
| factor for Google Search.
|
| Isn't that hyper-misleading? Click-through is a ranking
| factor, and especially click-through without return and
| click-through to something else on same results page, and
| being on the mobile carousel increases click-through. Or do
| they exclude those clicks from ranking?
| amelius wrote:
| App store rules : Apple = AMP : Google
| kevmo wrote:
| AMP was never anything but a naked power grab by a monopoly.
|
| Google (Alphabet) needs to be broken up.
| tboyd47 wrote:
| Why would that help? At least now that they've been exposed, we
| all know what they're up to.
| [deleted]
| jez wrote:
| I switched to DuckDuckGo on mobile a while back because it meant
| that I didn't have to see constant AMP results. Even though I
| think DuckDuckGo's search results aren't nearly as good I have no
| intention of going back.
| coding123 wrote:
| Same here, I use DDG and Firefox. I do open google occasionally
| when I'm searching for a nearby restaurant. Unfortunately the
| reason the restaurant comes up in Google is all the invasive
| stuff they've tracked me with over the last 14 years.
| 1propionyl wrote:
| Wildcard blocking the following domains will break/disable AMP
| pretty much everywhere, leaving only the header bar (from which
| you can click to the original page):
|
| - google.com/amp
|
| - ampproject.org
|
| I've been including AMP in my blocklist for quite a while now,
| and while I've occasionally felt like I'm tilting at windmills,
| it's honestly not much more inconvenient.
|
| Before blocking AMP, I would get confused for a few seconds by a
| broken page that looked like a real page. Now I just see an empty
| page immediately, prompting me to get to the real page more
| quickly.
| darepublic wrote:
| We need an exorcism to rid ourselves of amp. The power of web
| compels you! The power of web compels you!
| bitcurious wrote:
| At least in the developed world, the case for AMP will be made
| obsolete as the transition to 5G happens on non-flagship phones.
| KronisLV wrote:
| What about the people who'd just prefer not to waste megabytes
| of data for loading what could as well be expressed in a few
| dozen kilobytes of text and some lightweight stylesheets, a la
| https://thebestmotherfucking.website/
|
| Now, AMP probably isn't the best solution for the problem, as
| many of the comments and other sources on the Internet do point
| out, but the website obesity crisis (
| https://idlewords.com/talks/website_obesity.htm ) is probably
| the actual problem that should be addressed, rather than just
| attempting to downplay the problem by saying that advances in
| how fast connections are will make it less annoying.
|
| Of course, the technical advancements are nice, but it still
| feels like some version of Wirth's law (
| https://en.wikipedia.org/wiki/Wirth%27s_law ) that's applied to
| the web, where the pages themselves should just be more
| lightweight and both drain less battery and consume less power
| (as well as require less processing power to render, because
| some of the modern sites are ridiculous in this regard, i can
| no longer have 50+ tabs open on a device with 4 GB of RAM
| without using tab suspension plugins).
| 1vuio0pswjnm7 wrote:
| Thought experiment: Divorce AMP from Google. Google withdraws
| from being the AMP standards author and "prototype" AMP cache
| provider. The project becomes truly non-commercial and is handed
| over to a non-profit that users trust, let's say, hypothetically,
| the Internet Archive. The IA adopts as AMP's goal: making web
| pages less expensive to crawl (ideally, by parties other than
| Google) as well as making pages faster on mobile. In addition,
| the AMP standard is revised to require that AMP pages must allow
| equal access by all clients, whether "browsers", "bots" or
| otherwise. No preferential treatment for certain browsers, e.g.,
| Chrome, or certain search engines, e.g., Googlebot.
|
| Bias disclosure: I use a text-only browser and AMP pages look
| great in links. For a links user, the AMP version can be useful
| on some sites that have a large amount of cruft, e.g., excessive
| number of same site URLs, at the top of the page, with the
| content buried below it, and yet more cruft at the bottom. AMP
| eliminates the necessary scrolling on such sites.
| three_seagrass wrote:
| >Thought experiment: Divorce AMP from Google.
|
| It already is. AMP was spun off into OpenJS Foundation in 2019.
|
| You can run AMP on your website without having to touch Google.
| jaredcwhite wrote:
| I can pick an AMP site out almost immediately. I click on a link
| somewhere, and a moment later as I start to the read the article
| I'm like: "this looks weird, like a crappy AMP site not a regular
| website!" I inspect the URL and sure enough it is. I always
| switch to the real site at the earliest opportunity. So not only
| is AMP terrible regarding the open web as others have commented,
| it's also freaking annoying on a pure UX level.
___________________________________________________________________
(page generated 2020-12-21 23:00 UTC)