[soyyo]

I worked on amp for a leading newspaper, and everyone who says that amp is about "making the web faster on mobile" is either very naive or doing marketing for google.

For publishers, amp is about trying to top the results on google search and capture traffic, it's their only motivation to publish their content using amp, and the only metric they look in order to evaluate the results.

Once they have their amp content, they will look how to load it with ads and tracking, which very conveniently is supported on amp, just as they do in their regular sites.

So the "fast" part, besides using their CDN, actually comes from limiting what you can do on almost every other part of the site, you can only do the stuff that is packed in the amp components controlled by google, which in practice means that google controls the web behavior.

[noelsusman]

Of course AMP has other motives than simply making the web faster for mobile, but it also does make the web faster for mobile. I guarantee the AMP version of that paper's mobile website provided a significantly better user experience than the normal version. That is why AMP has been successful, and it's why I will continue to click on AMP links whenever available.

Is giving Google that much control ideal? Of course not, but from a user perspective it's a hell of a lot better than the alternative.

[littlestymaar]

> but it also does make the web faster for mobile.

AMP probably help making some previously bad-written amd bloated websites less slow, but it doesn't make them fast either.

HN is a fast website. The old reddit was a reasonably fast website. The new reddit (with AMP) is slower on my phone than the old one. It's still faster than the worst websites I browse on mobile, but it's far from being the fastest, and it's one of the slowest I actually use on my phone (simply because I usually don't browse websites that are too slow).

AMP isn't about speed.

[buboard]

> it also does make the web faster

this is true

> That is why AMP has been successful

This is not. If google removes ranking incentive, people will forget about AMP the next day

[qbaqbaqba]

> it also does make the web faster

No, it is not. Optimized plain old webpages are faster.

If Google wants to promote faster pages then amp should not be promoted in the search results.

It is about capturing traffic, injecting tracking and ads.

[thereisnospork]

>> That is why AMP has been successful

>This is not. If google removes ranking incentive, people will forget about AMP the next day

Google giving ranking incentive to sites that are faster seems like the exact sort of thing they should be doing.

[hk__2]

> Google giving ranking incentive to sites that are faster seems like the exact sort of thing they should be doing.

Yes. It should give ranking incentive based on actual speed, not AMP support.

[Udik]

> Google giving ranking incentive to sites that are faster seems like the exact sort of thing they should be doing.

Really? I thought Google's purpose was to find information in the web, not to give me fast links. If I am looking for an article, I want that article, not a different but faster one. If I am looking for a piece of information, I want the best fit, not the second or third best but faster fit.

[jhanschoo]

> find information in the web

This has not been true for more than a decade. The primary use case of the Internet today is to connect users with service providers of all stripes, and not just information repositories.

For most of these, the quality of service is more correlated with their "speed".

[thereisnospork]

Information delivered slowly is less useful than information delivered quickly[1]. If there are 5 takes on an AP-wire article I want google to give me a fast site over a bloated slow site. The finer points of how they get to a fast site don't particularly matter to me.

[1] One of the nicer features of HN is that it is snappy and responsive - ime the polar opposite of many non-AMP news sites.

[AlexandrB]

> If there are 5 takes on an AP-wire article I want google to give me a fast site over a bloated slow site.

I'd want Google to give me the accurate, well-researched site. When the difference between "fast" and "slow" is a matter of seconds (or often milliseconds), I'm not sure why better information delivered a few seconds later should be ranked lower.

[snowwrestler]

Google already incorporates site speed into their rankings, separate from AMP.

However, if you want to get into Google's mobile carousel above the normal search results, you have to serve AMP pages and let Google cache them.

[progval]

Except that it's now giving a huge boost to websites that use a specific technology to be fast; instead of just boosting all fast websites like it used to. Sites can be fast even if they don't use AMP.

[girvo]

Heck, sites can be faster if they don't use AMP. Sure, most sites aren't, but it's certainly doable. AMP, aside from Google caching your site on the SRP, doesn't really do anything crazy when it comes to site performance.

[beaner]

But speed results in better ranking, and that's what amp provides.

[SirHound]

No, AMP provides space on a top carousel of results.

[beaner]

It may also do that, sure. But you're telling me it does not provide speed improvements?

[stephenr]

Install a content blocker, and the original site sans bullshit is the best experience.

Ironically the amp page is artificially slow when blocking amp’s JS because they force an 8 second delay - via required boilerplate css - before content is visible.

[gregable]

You misunderstand the 8 second CSS animation in the AMP boilerplate. Here's the code (simplified):

  <style>
    body { animation:-amp-start 8s steps(1,end) 0s 1 normal both}
    @keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
  </style>
  <noscript>
    <style amp-boilerplate>
      body{animation:none}
    </style>
  </noscript>

See the noscript section: if javascript is disabled, the CSS displays the body immediately. If Javascript is enabled, but for some reason the AMP javascript fails to load, after 8 seconds, the page is displayed anyway. When the AMP Javascript loads (a single js file, one request, typically already in the users cache), the javascript displays the page immediately. The page is probably somewhat broken without the javascript loading, but the 8s is a fallback, not code to slow down non-javascript browsers.

The only two cases where the 8s is relevant are: the network connection is so bad that the javascript file fails to load within 8s and the useragent has explicitly blocked the one javascript file on the page, without blocking javascript overall.

[JoshMnem]

The 8-second delay is there to punish users who block JavaScript that is loaded from Google's servers (with ad-blockers) but still have JavaScript enabled.

[esrauch]

I think that's a bit unnecessarily tin-foil-hat. If they didn't put in the 8 second css rule it would just show blank for those users right? So adding that rule is making it work at all instead which doesn't sound like "there to punish them".

[squiggleblaz]

Why is there an eight second delay instead of, say, an 0.8 second delay? Or no delay at all?

I mean, if the goal is to make the page display only once it's fully loaded, and the point of amp is to make pages load quickly, eight seconds seems gratuitous. Even slow sites load within eight seconds.

(I don't deliberately use any Google products, so I'm completely unfamiliar with amp.)

[JoshMnem]

It's the other way around -- AMP pages show a blank page for 8 seconds for people with ad-blockers because of that CSS rule.

[munk-a]

This will hit a lot of people on the web today that have given up on a blanket block on JS (because a lot of pure text content simply fails to render without JS, yaaaaay) but do have a blanket blacklist on JS assets and whitelist requests on a need basis.

[4ntonius8lock]

As intended. We desperately need some anticompetitive scrutiny on google.

Unfortunately... https://www.opensecrets.org/orgs/summary.php?id=d000067823

[wizzwizz4]

Source for your second paragraph: https://news.ycombinator.com/item?id=16730905

That's out of date now, though; despite still being part of the required boilerplate CSS for AMP pages, I can't find that delay in any of the https://amp.dev/ pages (the ampbyexample.com replacement demo site).

This is really shady.

[joshuamorton]

It's a little more complex than that:

If you disable all js, there is no delay. If you specifically block amp js, there is a delay. There could certainly be a shady reason for this, but the justification makes sense: one of the goals of AMP is to have, basically, a single, correct, initial paint. That's why images are statically sized and amp sticks placeholders there until the real images load. The js delay exists to allow the site to fetch the js and use it to correctly render the initial paint, even on a slow/flaky connection where the js takes a bit to fetch.

[stephenr]

The delay is css based not js based, so why would blocking all js affect it?

[wolfgang42]

If you tell the browser to disable execution of all <script> tags, it will instead evaluate the <noscript> tag which contains some additional CSS that disables the animation.

[gregable]

Sites which optimize their pages via https://www.npmjs.com/package/@ampproject/toolbox-optimizer have the initial layout performed server-side instead of by javascript, and thus the CSS Flash-of-unstyled-content protection is removed. amp.dev runs this optimization, along with lots of other sites.

[basq]

Does it really make the web faster for mobile? I've had the exact opposite experience with it. It's made sites run much slower, broken things like dark themes, and make advertisements more intrusive. For example, I used to think the game guide/news site polygon was a horrible slow mess until I learned about amp, I was accessing it via google search, and once I excised the amp portion of the url the site became snappy and usable. The same exact thing happened to me two nights ago with SoundOnSound as well.

[dbtx]

> a lot better than the alternative

There are more alternatives. IIRC the goal in 56k days was to make the page load inside 10 seconds. People managed.

[dbtx]

It was probably 5 seconds, to maximize conversion. Thankfully, I haven't had to think about it for 10+ years.

[hw]

HTTP/2, HTTP/3, 5G, faster mobile phones, will all make AMP inconsequential and unnecessary, unless your primary audience lives in rural areas or are not able to adopt such technologies.

Applications used to fit on a floppy disk. Websites used to be a few K in size. AMP might be successful (if it's even considered successful), but only for a short while. I avoid AMP links when I can, since I don't want the jank, stripped down experience of a site. If I really want a great experience on publishing sites, I just turn on Reader Mode.

And of course, it's preposterous that Google gives preferences to AMP pages on search rankings. It's just as if Amazon prioritizes its own products in its search rankings (not saying it does or doesn't).

[bytematic]

Exactly, use google amp and get higher rankings and it can increase your traffic by hundreds to thousands to millions. I hate it but its how it works

[earthboundkid]

Huh, weird, it's almost like they're abusing their search monopoly to push a technology that everyone hates and is only fast when compared to their ad monopoly.

[bscphil]

> a technology that everyone hates

There are users in this thread that seem to like it quite a lot because it's faster than the original site, because it limits the amount of crap the original site can run. The only reason I don't like AMP is because I don't like an intermediary like Google rendering pages for me and probably tracking what I do on them. That's ... not even close to something on most people's radars, so there's no way "everyone" hates it for that reason.

I suspect most people have never heard of AMP and just like it when sites load fast.

[superkuh]

Higher rankings and google will preload the amp page they have and their servers for the amp link. That's why it is a tiny bit faster. It has nothing to do with the amp spec itself. It's faster because google is abusing it's monopoly search position to pre-load.

[shawnz]

I think the idea is that preloading wouldn't be feasible with arbitrary unrestricted HTML because of security concerns, which is why they created this restricted subset in the first place.

[lern_too_spel]

> google is abusing it's monopoly search position to pre-load.

How is that abusing their monopoly search position? Abusing their monopoly search position would be making publishers integrate directly with them to enable preload, like Apple News. Instead, they ask publishers to serve documents that can safely be prerendered, and all their competitors get to (and do!) consume those documents as well to enable safe prerendering from their own sites.

[stephenr]

Without their monopoly search position no one would be forced to adopt amp and further strengthen said monopoly position.

[lern_too_spel]

> Without their monopoly search position no one would be forced to adopt amp

It is used by the major search engines in every major market, so yes, they would be forced to adopt AMP. Compare to Apple News, which gives the publisher even less control.

Once again, how is it abusing their monopoly position if all their competitors get to benefit from it for free?

Finally, how do you propose to enable safe prerendering on the web that you would be fine with? RSS enables the same thing but takes even more control away from the publisher, but you're presumably fine with that. Not a single person in all these AMP rant articles that pollute HN has ever proposed an alternative, with 99% of the ranters, including this one, not even understanding the basic fact that prerendering is the thing that AMP enables.

[saagarjha]

I don’t want prerendering if it comes with this attached to it. Fast pages don’t need prerendering.

[squiggleblaz]

Why does safe prerendering need to break URLs? Why can't the pages be safely prerendered client side?

[joshuamorton]

How does amp strengthen a monopoly position?

[RonanTheGrey]

"Use AMP or your site will not be present in mobile search results" doesn't seem like monopolistic practices to you?

[stephenr]

It strengthens googles control over the web.

[saagarjha]

Apple isn’t running a dominant search engine that upranks Apple News results.

[lern_too_spel]

You're right. Apple is worse. They show only Apple News results.

[squiggleblaz]

But there's a difference between having a service which only shows your stuff, and having a service which apparently shows the entire internet, but subtly prefers your stuff. Most people find the latter far more questionable than the former, because if we want to find anything, we need to know where to look.

[emodendroket]

No, I'm well aware that that's what it's "about," just like I'm well aware that the search engine is mainly about advertising. I just don't care what it's about so long as the results are beneficial to me -- which they definitely are. When I see the AMP icon I know the page is going to load much faster

[pixl97]

Always question what long term loss you are taking for these short term gains.

[munk-a]

I really wish content servers considered that before letting all their sites become ad laden wastelands.

The web infrastructure we have today can respond to pages blindly fast if proper optimization is done, bloated front end frameworks and malvertising counter all of that to draw it down to molasses speeds - and the "I want to server my stuff to my users" argument is only valid if it's to extracting ad revenue from them - I think it's just time to reeducate people on the fact that ads may subsidize content but they can't fully sponsor it outside of niche situations.

[emodendroket]

I suspect I am not losing very much at all by preferring to click AMP links.

[mrtksn]

Are we going to lose high-quality paid by the reader content? Probably not, because that already happened to the newspapers. They were replaced by the "get a view at any cost, track the user through all means possible, it's all about eyeballs on ads" folks and now they are warning us that they might be next and we, the readers, should decline reading the low quality fast.

[vkou]

The long term loss for short term gains that we're already dealing with has been the page bloat over the past decade.

AMP is the solution to that long-term loss. It's not the best possible solution, but it's the best that we currently have.

Prior to AMP, the web didn't give a rat's ass about performance.

[manderley]

To me, AMP is annoying because it means I have to make two extra clicks to get the real site to load.

[adammenges]

use duckduckgo! :)

[AlexandrB]

> I just don't care what it's about so long as the results are beneficial to me -- which they definitely are.

Are they though? With the search engine example, how do you know that the engine is not biasing your opinion so that you act against your own self-interest and to the benefit of the advertisers?

The AMP situation is a bit more complicated, but how are you sure that AMP is beneficial to you in the broad, long-term sense?

[emodendroket]

It is quite simple. My calculation is: 1) an AMP page will load much faster 2) clicking on an AMP or non-AMP page will have nearly no effect on me in the "broad, long-term sense;" to the extent AMP more generally may adversely affect me, my own personal participation in it has pretty much no impact at all.

[brentonator]

I invite you to go to your local Fox/ABC/CBS channel's website and TRY to read an article vs AMP.

AMP is about stopping....that. It's indescribable how horrible these companies have become.

1. Auto-playing ads 2. Scroll-jacking 3. Overlay...after overlay... after overlay. 4. Popover 5. Paywall 6. Popover again for good taste. 7. Oops you scrolled too far better redirect you to another page entirely. 8. You wanted the video version of this article right? Better force you to read the article in 20% of the screen so all of our ads, bars, and video can fit on the page.

[ogre_codes]

This doesn't address those problems, it has effectively created a second, proprietary web which is only accessible from the Google home page.

If Google actually wanted to improve the web, they wouldn't be splintering it, they would reward publishers with better search placement for building user-friendly sites. As it is, AMP is little more than a way to ensure the "Google" web is better than the non-Google web. Which of course funnels money into Google's pockets.

[gregable]

AMP pages are just HTML. Publishers can and do use AMP pages as their "regular" pages that every user sees, not just those coming from Google. Other aggregators (Bing, Twitter, LinkedIn, etc) link to AMP versions. These pages are far from only accessible from Google queries.

[ogre_codes]

Publishers can and some do, but from what I've seen, the overwhelming majority do not. The overwhelming majority of "modern" web-sites are a shit show. If that wasn't the case, there would be no need for AMP.

[saagarjha]

If they’re just HTML pages, why would I use AMP?

[lern_too_spel]

Because, as you have repeatedly shown you already know, AMP pages are a constrained HTML that supports safe prerendering. Why ask a question you already know the answer to?

[saagarjha]

> AMP pages are a constrained HTML that supports safe prerendering

Then they're not HTML, are they? As other commenters have pointed out, nobody is using the constrained set of AMP as their main page, precisely because it's not "just HTML". (And specifically, Google controls which subset of HTML this is.)

[tyingq]

Google is capable of driving SERP and carousel position based on the performance of the site. They don't need AMP for that. AMP is very much about creating an semi-walled garden. Any performance benefit is the lovely exterior of the Trojan horse.

[bduerst]

And has been. Look at how well that worked for mobile web.

[tyingq]

Sorry, "has been" what?

You mean Google is using performance, in a meaningful way, to drive SERP and Carousel placement?

If so, I disagree. They talk about it. They don't do it in a way that drives behaviour. They could.

A significant drop plus a webmaster tools message that says why, would work.

[privateSFacct]

No kidding

Despite all the claims that AMP is only faster because of preload, if you actually look at these HTML sites on big news orgs they are MONSTROSITIES. Check out dev tools, the number of network requests is wild. The page is so insanely dynamic do old / slow computers even run it well?

From script size to dome/paint reflows etc etc to third party javascript having total access to your page - much of that is limited with AMP. I think third party javascript is forced into an iframe sandbox, can only be async with a web worker, limited in size acrosss ALL scripts etc.

[hayyyyydos]

> 3. Overlay...after overlay... after overlay.

amp-sticky-ad, amp-video-docking, amp-app-banner

> 4. Popover

amp-fx-flying-carpet

> 5. Paywall

amp-access, amp-access-poool

> 7. Oops you scrolled too far better redirect you to another page entirely.

amp-next-page

> 8. You wanted the video version of this article right? Better force you to read the article in 20% of the screen so all of our ads, bars, and video can fit on the page.

amp-sticky-ad, amp-video-docking

[aembleton]

Can probably solve all of that by switching off Javascript.

[zelly]

uBlock Origin and uMatrix can give you the AMP experience without AMP, but the vast majority of users won't use them. I see the need for AMP but it just enables these bad corporate websites, as if CNN/FOX/Quora etc. can't afford to clean up their pages.

It would be better to just completely penalize blogs that paywall or otherwise make content unreadable. It's not like news articles are ever scarce. I don't know what they're doing as a search engine if I get any results that are this opaque.

[mrtksn]

Serious question: what else those websites are supposed to do (that AMP does not provide) with all those megabytes of scripts?

Newspapers display a text and an image and very rarely an interactive content(Election day maps and charts, mostly).

Is there a reason FROM USERS PERSPECTIVE to have different website codebase for each publisher?

For years the Web community kept creating new JavaScript libraries every day and all these web libraries were about providing a different way to do the same thing. No one ever created anything for the users, in fact, AMP is the first web technology that improves the user experience. It's loading fast and not too much stuff happens to display a text and an image.

Web people are mad at Google and I think they should be but all this happens because the web publishers refuse to compete on User Experience. They all optimize for the clickbitiest title or controversial topic and Google came and steamrolled their publishing tech.

I can't really blame Google for this one, you can check it out - I am critical of Google but I am more critical of the news business or the web tech community that optimized for very bad KPI that destroyed democracy, made web unpleasant and are now crying because of someone demolished their low-quality business.

From USERS PERSPECTIVE, AMP is a godsend. You can quickly view and skim low-quality content. The alternative is slowly viewing and skimming low-quality content.

It seems like the web technologists are unaware that they are dealing with real human beings, optimizing blindly for page views and CPMs.

AMP is Youtube for written content. A strealined conent delivery platform prioritizing UX that the publishers failed to create themselves all these years.

[jammygit]

I’m just annoyed at my links being hijacked. When I click a link, my intention is to visit someone’s page, not to view it through some sort of creepy iframe. When I go to share a link, why is it a google link instead of the newspaper? Why do I have to spend a minute or two hunting for the real one in the ugly ui?

[mrtksn]

I agree with this, I don’t want to share AMP links because it feels wrong for some reason. Still, on the right top corner there’s a share button that would give you the link to the original source.

[gregable]

Publishers who implement Signed Exchanges get AMP links directly to their site with no iframe viewer on browsers that support the technology: https://amp.dev/documentation/guides-and-tutorials/optimize-...

https://github.com/WICG/webpackage/blob/master/explainer.md

[munk-a]

Doing a thing and then offering a service or agreement to undo the thing is not the same as never doing a thing and is usually a pretty clear signal of some underhanded doingness.

[sixstringtheory]

Is “browsers that support the technology” interchangeable with “Google chrome”?

[Sohcahtoa82]

> From USERS PERSPECTIVE, AMP is a godsend.

This right here.

The first time I found myself on an AMP page, I thought "Holy crap, this page is fast and responsive!"

It was a couple months later I started seeing hate for AMP on HN and was kind of surprised. I understand the dislike of Google basically taking over, but I feel like Google is telling publishers "Since you guys can't figure out how to make fast web pages, we're gonna basically do it for you".

> AMP is Youtube for written content.

A few commenters have taking issue with this, but I interpreted it to mean early YouTube. Before YouTube became a thing, sharing videos online was difficult for a non-technical person. Just like YouTube made it easy to share videos, AMP has made it easy to make responsive pages.

Though a key difference is that it isn't hard to make responsive mobile web pages. Site owners have just decided that tracking, metrics, and advertising is more important than UX.

[buboard]

from USERS PERSPECTIVE, amp is meh. yes it's faster, does it really matter if you re getting an article in 1 second when you -obviously- plan to spend 2 minutes reading it? i dont know anyone who thinks so, perhaps your USERS do

> A strealined conent delivery platform prioritizing UX that the publishers failed to create

what you re implying is, Google failed to improve their algorithms to bypass obvious SEOs, so they are forcing everyone to use a dumbed down platform that is harder to SEO - for now!

[mrtksn]

Actually, it's a pretty well-known fact that users leave websites if they are not loading fast.

People don't go with reading plans to websites, the titles are optimized to bring you there and you don't know what's in the article. More often than not, the text on the website is not what the title made you believe it is. You can't plan ahead, you want to quickly find out what is this all about.

The article themselves are usually garbage optimized for SEO, long paragraphs of sentences that say the same thing but with different keywords. If that's not enough, they try to sway attention with ads and popups. Even if you had a plan about reading an article, the publisher's plan about you is different(tip: it's not about letting you read in peace).

The Web is horrible, it's even more horrible on mobile. AMP is an improvement.

[reaperducer]

Actually, it's a pretty well-known fact that users leave websites if they are not loading fast.

Is it? The only place I've ever seen push that view is Google. I've never seen any non-Google information reflecting that.

[gregable]

A few references listed in this article: https://www.cloudflare.com/learning/performance/why-site-spe...

- Mobify found that decreasing their homepage's load time by 100 milliseconds resulted in a 1.11% uptick in session-based conversion

- Retailer AutoAnything experienced a 12-13% increase in sales after cutting page load time in half

- Walmart discovered that improving page load time by one second increased conversions by 2%

[buboard]

those statements sound like incredible cherrypicking

does 1.11% sound a lot an is it statistically significant?

cut page in half from what to what? from 30 to 15 seconds? or from 2 to 1?

improving one second like how? from 12 to 11 or from 2 to 1? and is 2% really substantial?

[dhimes]

I too am skeptical- except in extreme cases. Maybe if it's some sort of mindless bullshit site that I'm not really interested in I would leave it if it didn't load in, say, 5 seconds. But I don't really give a shit about the bullshit web. Life would be better without that anyway (except, of course, for companies who make a living selling ads on such sites).

But if somebody's leaving a page that has content they need because it doesn't load in 1 second, then I'd say they're a dumbass.

[buboard]

> users leave websites if they are not loading fast

then google is doing a bad job of presenting these sites to users, since obviously these sites should lose their rank, since users leave them. Google surely thinks bounce rates are important, no?

> The article themselves are usually garbage optimized for SEO, long paragraphs of sentences

and how is AMP fixing this? and who is responsible for SEO having these incentives? SEO literally means they optimize for what google wants

[mrtksn]

They do lose ranks[0].

AMP is fixing this because you can take a peek into the content almost instantaneously so you can just see what is this all about and leave.

https://developers.google.com/web/updates/2018/07/search-ads...

[buboard]

i don't see why any webmaster would want users who "peek instantaneously and leave". what a waste of an http request

[Mindwipe]

It's sometimes a little faster but also considerably less functional. The Guardian and Reddit both have AMP pages that are much worse than the actual pages.

[summerlight]

> if you re getting an article in 1 second when you -obviously- plan to spend 2 minutes reading it?

In my experience, 99.9 percentile is more like 2~30 seconds in NorCal with a potentially sub-optimal ISP. I expect this to be even worse in developing countries like south/southeast asia.

[Kiro]

You clearly don't speak for the users in the developing world with bad connections. Speed is anything but irrelevant.

[wizzwizz4]

Google AMP mostly just reduces the latency by pre-loading the pages from Google Search results. That has the side-effect of increasing the traffic on networks using Google Search when Google AMP results come up on the Google Search results, which they probably will given that using Google AMP will improve the site's Google Search ranking.

I haven't benchmarked it, so I can't actually speak from anything but wild speculation, but Google AMP might actually be making this problem worse.

[mrtksn]

I gave it a try. So I searched for "Trump" in Safari mobile, the result page loaded 2.5mb. It loaded a bit more when I clicked on an AMP article and kept loading more as I jump from article to article. It did not load any data without me switching to the next article.

After 10 articles, the transferred data was 28MB. I visited the Guardian's own website and it fetched 3MB.

So, It looks like Google does not preload a huge amount of data.

ps: I use ad-blocking and cleaned the cache.

[arthurcolle]

How are you able to look at how much data was transferred on Safari mobile? As far as I know you can't access dev tools on mobile. Did you just change the User Agent on your computer to simulate?

[wizzwizz4]

I do know it preloads on Chrome on Android on mobile networks, but it's a little surprising that it doesn't on Safari on iOS.

[Kiro]

I know it's not kosher to complain about downvotes but I said nothing about AMP, just argued against the statement that users don't care about speed. Anything that could possibly be interpreted in Google's favor gets downvoted immediately. It's carpet bombing with collateral damage.

[buboard]

slow users everywhere are better served with the simple amphtml page without any of google's scripts

The major problem is the download size anyway, and most of it is google-served ads and trackers. Amp is making this asynchronous, but afaik it doesn’t get rid of the ads

[bassman9000]

AMP is Youtube for written content. A strealined conent delivery platform prioritizing UX that the publishers failed to create themselves all these years.

Do you pay for youtube? Because the vanilla youtube experience is an ad-ridden UX nightmare.

If AMP is YouTube, AMP sucks.

[mrtksn]

I use adblocking on Safari(mobile and desktop), so the web experience for me is very good. On the iPhone App, the ads are annoying but I do understand that this is how the content is paid for, so I am O.K. with it.

The main difference is that with many websites things jump around when on Youtube the design is clearly defined. There's no cognitive load in trying to find the content between those "subscribe" popups and menus etc.

They clearly designed their experience with the understanding that you are there to watch a video.

Actually, YouTube's website is so good that the first thing that appears on the page is the video and it starts playing when the rest of the page(like, subscribe buttons suggested videos etc.) is still loading and not rendered.

Most websites on the other hand act as if the content was the bite to lure you there and try to make you subscribe/create an account/ allow notifications/show you ads and it's their failure if you actually happen to consume the content that was promised to you from the link you clicked.

Completely different experiences.

[bassman9000]

What's the point of praising youtube's UX if you're blocking part of it?

[mrtksn]

I'm blocking ads on all the websites, my content blocker is not youtube-only. Still, other websites suck and Youtube is great because UX is not just about ads.

[saagarjha]

> The alternative is slowly viewing and skimming low-quality content.

No, the alternative is quickly skimming low-quality content with an adblocker and reader mode.

[lern_too_spel]

AMP is fast because it prerenders. That is the main point of AMP, and you seemingly don't understand it after working on it. It amazes me how little developers understand their platforms these days.

[tyingq]

You may consider that we do understand pre-render, but don't like the trade-off involved.

A full on AOL style walled garden could be even faster. It could mandate brotli, force a common css base, only offer one kind of ad platform, etc. Should we go there?

[lern_too_spel]

The person I was responding to said that AMP was fast for a reason other than prerendering. That's wrong. Prerendering is the main point of AMP, which is what I pointed out in my comment.

A full AOL style walled garden is what Apple News and Facebook Instant Articles are. AMP enables the same speed in a way that any link aggregator can take advantage of without having to strike deals with individual publishers.

[tyingq]

I agree with your literal statements, but Google does abuse AMP. The way they hijack left/right swipe and the back button for carousel loaded pages is ample evidence for me. It's very clearly not my content any more when you steal the top X pixels and hijack user interactions.

AMP also requires I include a Google owned and controlled piece of JavaScript that they can change at any time. That's literally in the "standard". In fact, a bad update borked all AMP pages for quite a while some time ago.

[lern_too_spel]

> The way they hijack left/right swipe and the back button for carousel loaded pages

This doesn't happen for me on any of my Android browsers. The problem is likely with your browser. I wouldn't be surprised if Chrome on iOS is buggy just like every other browser available for iOS.

> AMP also requires I include a Google owned and controlled piece of JavaScript that they can change at any time

If you don't want your page to load instantly from Google, Bing, and other link aggregators, don't use it. Same with Apple News, which has more ornery integration requirements. I, as a user, will simply skip over your links to find faster ones. If you don't give users what they want, what do you expect will happen?

[RonanTheGrey]

> This doesn't happen for me on any of my Android browsers.

They're talking about a feature built into Safari on iOS that allows you to swipe between pages from the left and right edges of the screen. Since all browsers on iOS use Safari as the base, they will inherit this behavior unless they take specific steps to disable it, which most don't.

AMP breaks that behavior and although I don't use it, many many people on iOS do and are accustomed to it.

[tyingq]

Yeah...my Google controlled browser that has dominant market share. Don't think Google wouldn't hijack on other browsers if they thought they could get away with it.

[tyingq]

"If you don't want your page to load instantly from Google"

Right. Would be a shame if somethin' bad were to happen to my little website, eh Vinnie?

[dang]

Please don't cross into personal attack. Your comment would be fine with just the first sentence, or if it stopped before "you seemingly". There's no need for supercilious disses of "developers" either.

https://news.ycombinator.com/newsguidelines.html

[lern_too_spel]

That soyyo, like the article's author, seemingly does not understand that AMP enables prerendering is simply stating a fact. In soyyo's comment, there is no place where soyyo shows any understanding that this is the thing that AMP was designed to do.

When I continued with my general statement about developers not understanding their platforms, I can see how that can be interpreted as a personal attack, and for that I apologise to soyyo and to the readers of this forum.

[s17n]

> So the "fast" part, besides using their CDN, actually comes from limiting what you can do on almost every other part of the site

That is a good thing.

[privateSFacct]

If you work for a media org - than you KNOW that on the non-amp pages the synchronous java script from a hundred tracking / ad platforms (why can't these sites just use ONE tracking library) CRUSH the page load times.

Despite your (false) claim that google support sync javascript ad libraries "just as they do in their regular sites" this is 100% false.

The amp javascript components have DOM interaction restrictions, file size restrictions, response restrictions, can't run sync etc.

for amp-ad

"No ad network-provided JavaScript is allowed to run inside the AMP document. Instead, the AMP runtime loads an iframe from a different origin (via iframe sandbox) as the AMP document and executes the ad network’s JS inside that iframe sandbox."

If you can't understand why some of these steps result in both a faster site and one that is more secure I can't help you, but please stop with the misinformation here.

[earthboundkid]

> "No ad network-provided JavaScript is allowed to run inside the AMP document. Instead, the AMP runtime loads an iframe from a different origin (via iframe sandbox) as the AMP document and executes the ad network’s JS inside that iframe sandbox."

GOOGLE CONTROLS THE AD ECOSYSTEM. If they think that's a good idea, do it on regular webpages. Literally, AMP is only faster because Google provided ads are so slow that any more sane architecture can easily run circles around them.

How Google could speed up the web 5000%:

"Starting next month, all ads must be a collection of static assets with no JavaScript outside of this toolbox. We will host the ads and ensure no other JavaScript is executed."

Done.

[tobr]

> Despite your (false) claim that google support sync javascript ad libraries "just as they do in their regular sites" this is 100% false.

OP didn’t claim this.

[yellowapple]

> they will look how to load it with ads and tracking, which very conveniently is supported on amp, just as they do in their regular sites.

Yes OP did.

[kingo55]

He put words in OPs mouth about sync loaded JS.

[yellowapple]

Take "sync" out of the mouth-inserted words and it's an exact representation of OP's claim: that AMP pages will gravitate toward being just as JS-laden as non-AMP pages.

Whether or not that claim is true is beyond both my expertise and my interest.

[tobr]

No, this doesn’t say anything about sync vs async.

[privateSFacct]

The parent / op literally says they will load AMP with ads and trackers "just as they do in their regular sites."

So we are very clear, regular HTML websites allow sync javascript and cross site / full dom access etc by trackers and ad platforms. Sync is preferred for a few reasons by ad providers. Lots of regular sites have sync javascript.

On AMP, total javascript size is limited, dom interactions are limited (ie, you can repaint the screen repeatedly with the flyover crap etc) and sync is prohibited and the script generally runs in a sandboxed iframe with a separate web worker.

So I'm not putting words in anyone's mouth, I quotes them exactly, and am pointing out that despite their false claim that you can run same things in AMP you do on regular site - you cannot.

People claiming that AMP is only faster because of preload, that publishers can abuse the user as much as they do with full HTML, that javascript works just as it does on their regular site are lying.

Is AMP perfect? No - folks will always be able to abuse things, but it cuts down on a bunch of common and egregious abuses.

I wonder if part of the issue is some folks here browse with ad-block or other extensions and so don't really experience the web as publishers intend it - because the differences between AMP and non AMP sites is glaring (ignoring the preload question).

[tobr]

Sorry, none of this matters. You are still putting words in OPs mouth. You should apologize for doing that and simultaneously saying they made a false claim.

[buboard]

amp-ads moves those ads/trackers in iframes, but that doesn't reduce the code size, right? google is also injecting code in your site , so you can't be sure that it's secure / private, right?

And if i promise to make all ads async and iframe, will google promise to rank my site higher? If not , they are discriminating in favor of their own walled garden system without an objective ruse.

[liveoneggs]

really? adsense forbids use of iframes afaik

[underdown]

Many ads are served via iframes

https://support.google.com/admanager/answer/183282

[buboard]

they offer replacements as amp-ads. i dont know how they work