also, YouTube's embedded player is 1.17MB js minified (~411KB gzipped) [1]

this is why we simply self-host our mp4s w/ <video> tags.

Gmail and AdWords UIs are equally terrible/bloated perf-wise. the plain html version of gmail [2] is still by far the best. for a company that built V8, Closure Compiler, Chrome Devtools, PageSpeed Insights, Lighthouse, etc. they really do a shit job on their own properties. Gmail went from the best in performant webapps when it first popularized Ajax to the worst example of one in 2017.

it's as if Google can't find good frontend engineering talent, i don't get it :/

AMP is not a solution for slow pages, even if it's billed as such to clueless content producers. AMP is a content lock-in and user tracking strategy with the promise of boosted visibility/rank. nothing more.

[1] https://www.youtube.com/yts/jsbin/player-vfleyMpxV/en_US/bas...

[2] https://mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui

I wish they did some more optimization on Gmail, and especially Inbox. The desktop UI is painfully slow to load, to the point that I mostly use it on mobile now..

it's as if Google can't find good frontend engineering talent, i don't get it :/

They can. Addy Osmani, Paul Irish, the PWA people, etc. They just don't seem to employ them to actually make user-facing products.

They just don't seem to employ them to actually make user-facing products.

it's fine if the high-level public-speaking folks aren't doing this, but the problem is that no one seems to be doing it.

anyone can open up the DevTools network panel during a Gmail load, then look at the timings, payloads and generated DOM to see that it's almost entirely absolute shit by Google's own standards, even in Chrome on a fast desktop; they still use MochiKit ffs. there are at least several hundred engineers here on HN that can rewrite the Gmail UI to be "blazing fast" without gutting features and would still work great even on old phones still running Android 4.4.4 (with latest Chrome).

obviously Google knows all of this, they just don't care because there's no measurable ROI in a faster free Gmail compared to getting people to host their juicy AMP content on Google's servers. "It's what the users want" is a half-truth optimized for maximum PR value; a bit like "Don't be evil".

Addy, Dominic, Eric, the Pauls, etc are (mostly) dev outreach for the Chrome team, which is why they're so well known. There are a LOT of talented frontend devs in Google; you just don't see them much externally.

That being said, there is also a toxic stance from many Google engineers (and management) that JS is a "lesser" language, and that feeling often translates to the devs that work in it.

There are a LOT of talented frontend devs in Google...many Google engineers (and management) that JS is a "lesser" language

And exactly what language do these fine folks do their frontend development in, Go, C++?

Google sure spends a lot of resources on this lesser language for how few engineers want to work with it.

And exactly what language do these fine folks do their frontend development in, Go, C++?

For a very long time, GWT (Java compiled to JS) was the preferred approach. Then development moved to the Closure compiler (JS following very Java-like patterns), and only very recently is ES6 style code taking off.

Much of the code you see still carries the legacy of GWT/Closure (and there is so much there that porting would be an insane task). It's a slow process. But, for example, YouTube is switching over to Polymer (https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtu...).

Google sure spends a lot of resources on this lesser language for how few engineers want to work with it.

Google is a massive company, with many different (often conflicting) initiatives. Chrome spends a lot of effort on JavaScript; but Chrome engineers are (for the most part) not the ones that are writing Google's frontend code.

For a very long time, GWT (Java compiled to JS) was the preferred approach.

fine, but this is entirely irrelevant. the problem is that no one was optimizing for the deliverable (HTML, JS, CSS). the GWT folks could have easily written an excellent compiler so it didnt spew a bunch of unoptimized and bloated trash.

YouTube is switching over to Polymer

which requires a massive slow polyfill in all but latest Chrome and results in a shit experience for all others (if i recall a related thread correctly [1]).

[1] https://www.reddit.com/r/javascript/comments/68vehl/youtubes...

fine but this is entirely irrelevant. the problem is that no one was optimizing for the deliverable (JavaScript). the GWT folks could have easily written an excellent compiler so it didnt generate a bunch of slow trash.

Compilers can only optimize so much. GWT/Closure do a very good job of it, too. https://www.peterbe.com/plog/advanced-closure-compiler-vs-ug...

Much of the "slow trash" is already optimized to death - it just dies under the weight of insane complexity (e.g. features), browser support, and overly-generic (IMO) support libraries

which requires a massive slow polyfill in all but latest Chrome and results in a shit experience for all others (if i recall a related thread correctly).

Tangential: I'm not sure which version of Polymer they're using - but 1.0+ removes the need for most of the polyfilling.

Guys that made the Closure compiler must take JS seriously.

Gmail in particular is still written using GWT, AFAIK, hence the strange HTML, etc. Its current frontend is probably an unsexy maintenance project, with little or no new development; most new features and dev efforts are likely in the "inbox" project, etc.

AMP is a content lock-in strategy with the promise of boosted rank

Open, not locked in, anyone can parse and cache it and it has to be publicly available (versus Apple News and Facebook Instant Articles that are pushed to those services), ridiculously straightforward and obvious. Oh, and there is no boosted rank.

So aside from the entirety of your statement, you're entirely correct.

People can have rational discussions about whether AMP is worthwhile or not (for instance, Google hosting the canonical script seems dubious) -- or whether some other subset of HTML would be ideal given the endless bloat that allows publishers to abuse fly-by users. However the rhetoric on here regarding AMP is so over the top of flag waving nonsense that it simply doesn't fit on a site where presumably we're a little more enlightened.

Nobody else wants to parse or host it because HTML works just fine. We don't need a new version from Google that so far only helps with search result visibility while losing flexibility and increasing the amount of effort publishers need to effectively maintain 2 copies of their site. This is a regression back to the days of WAP mobile sites.

It also does lock-in the users into Google's experience rather than actually visiting the site, which is a big issue, including problems like further centralizing traffic and data to a single company.

Google could easily penalize search results based on speed with a strict cutoff and the entire web would become faster within weeks. Also the largest ad server on the web is Google's own doubleclick which is one of the slowest. There are many better ways to improve performance and UX without AMP.

Nobody else wants to parse it because HTML is a perfectly well functioning and accepted system

Apple and Facebook, two of the largest content (re)publishers, have their own competing formats, and Bing currently spiders and parses AMP content as well. But thinking more holistically, many others simply pushed their content into apps, abandoning the web wholesale. Because while we can talk about how "well functioning" the web is, a virtually universal observation is that native apps that just wrap a web browser are sloggy garbage, and a big reason is that the HTML stack has grown so enormously flexible it becomes its own enemy.

We don't need a new version from Google that so far only helps with google rankings

I'm a charitable sort of person, so when someone like Google comes out with something I assess why they did it without presuming the worst. In this case we see silos appearing from Apple and Facebook, not to mention the appification of content, so Google looks for a way to keep the web compelling. And it is. When I see an AMP page there are a number of user-centric benefits that make it a draw as a link, not just speed but also best behaviors.

I mean, many of the complaints on here about AMP seem just surreal. For instance if you open the carousel (an option for trending topics like Trump) and swipe, it brings you to the next story in the carousel. This outrages some that you aren't locked in the gutter of a given site, which is just bizarre and anti-user.

Apple and Facebook, two of the largest content consumers, have their own competing formats

Solving different problems on THEIR platforms.

AMP is just imposing a non-solution to a non-problem on web users.

So slow page load speed is a non problem and speeding up delivering content is not a solution? Whether you like it or not, if you search on Google, you are using THEIR platform and you are THEIR user. What they have determined is that their users want to consume content faster than what is traditionally available on the web. So you'd rather wait 3 seconds to see your ebay listing than half a second? For the open web, javascript bloat and google is taking over the world reasons. That suits you fine but not the majority of users on Google. Why would Google be implementing a technology that is BAD for their users?

You really should get an AOL subscription. If you ask nicely they just might let you use the 1994 edition which did pretty much all that you describe. And then we got the web.

Exactly the level of discourse that HN is capable of having regarding AMP. Congratulations.

The greatest lie in this discussion is the farcical notion that it's "AMP vs the Full Web", as if those are the only options. It's facile sophistry, but if it's anti-AMP it's all good here.

but if it's anti-AMP it's all good here.

And if it's pro-AMP then it's good for you.

Really, AMP is a step back and something that solves entirely the wrong problem, and coincidentally continues the trend of Google pulling ever more content into its own eco-system to get to the point where you hopefully will not leave Google any more during the course of a browsing session.

If you feel that's good then I really don't know what arguments would make you see that this is the opposite of where we should be headed, all this vertical integration on the web serves nobody except for the few largest players. If the frog doesn't jump out of the pot while it still can then that's a point against the frog.

And if it's pro-AMP then it's good for you.

As a user, I like AMP. I don't work for Google and have zero investment in whether AMP succeeds or fails. But I'm capable of rationally discussing it without ridiculous FUD or pejorative noise, which so many of you aren't.

If you feel that's good then I really don't know what arguments would make you see

Of course. Allude to the greater knowledge that the ignorant fool just doesn't get. 2 for 2 now.

But thinking more holistically, many others simply pushed their content into apps, abandoning the web wholesale

What are you talking about? No they haven't, all major publishers continue to develop and grow their websites with some reaching into other social platforms to distribute further. Nobody has moved to an app, if anything apps have decreased in importance across the mobile universe. And if you're trying to talk about complex webapps then they were never a target for AMP anyway.

If all you really care about is user benefits, then as I described Google already had plenty of options that would be faster and easier without forking the web.

What are you talking about?

Virtually every major publisher has an app that they try to herd users into. As do many if not most social news sites. Was your question satirical, or have you just been asleep for a decade?

Given the nonsensical beginning to your comment, the rest just seems like farce.

Another big anti-AMP person is John Gruber and your comment reminded me of him -- He'll effortlessly go from advocating why iOS apps aren't anti-web, because they're still hand-wavy using web services or something, and then go on a diatribe about AMP. It's quite a delightful bit of mental flexibility.

Having an app available is not "abandoning the web" - which is what you claimed. I've worked with all the major publishers and their biggest focus is always their own websites.

And if you can't even finish a comment that replies to exactly what you wrote then what are you doing talking about the "level of discourse" on HN?

Abandoning meaning not basing their electronic presence on it. No one wants to be just a website, except for maybe Metacritic. Everyone wants to be an app.

what are you even doing talking about the "level of discourse" on HN?

A recurring set of alternative facts rise to the top of every discussion on AMP, and my post that questioned it sits at -5. It seems laughable to now demand that I rise above -- I just find it funny.

Surely you can see the less attractive aspects of Google's AMP cache?

They inject a carousel, push the organics down. Then you have to publish AMP to make it into the carousel.

At which point Google takes over your page. Adding a big amp banner with a [x] button that doesn't do what users expect. Inserting a pagination widget that scrolls to competing content, breaking the back button, etc. Is it a coincidence that all of that drives more pageviews of Google's site? Is it really your page if you don't control it?

They inject a carousel, push the organics down.

Why do we always have to talk about the carousel? It is only relevant for news/trending topics. For that the whole "organics" are upended regardless.

Is it a coincidence that all of that drives more pageviews of Google's site?

I really, really don't think Google cares about "pageviews". But yes, it may make users think "these results are quick and convenient, so maybe I won't use Facebook as much for trending topics".

I really, really don't think Google cares about "pageviews".

If you followed what they did over time with Wikipedia content and links, for example, you might feel differently. Or Froogle, or KG, Google Flights, or this recent change: https://mobile.twitter.com/jeremys/status/876978936177082368... , etc.

The investor pressure on Google to sustain year over year click growth, that exceeds overall web growth...is tremendous.

Driving more pageviews is one of a very few levers they have to do that, since they have exhausted many others. Once you push all organics off the fold, there's not much else you can do.

Edit: We talk about the carousel, because it perhaps best telegraphs the true intent of AMP. Everyone told me to shut up about Froogle too, because it was free for advertisers.

If you followed what they did over time with Wikipedia content and links

Search has evolved past a list of links. Every vendor in the space is doing exactly the same thing -- becoming a knowledge engine versus a keyword corpus. Yes, Google wants to create a useful product. Nothing particularly nefarious about that.

Driving more pageviews is one of a very few levers they have to do that, since they have exhausted many others.

When has Google published pageviews? Google publishes revenue and income, and userbases for a few properties and products. They don't publish or gloat about pageviews, and it is entirely irrelevant if they serve you a page from a cache or not. But yes, they probably worry that as the web gets more user hostile, users might choose silos like Facebook Instant Article, where Facebook ads might be more likely, but in that case we're talking about user likes and dislikes which is tough to argue against.

We talk about the carousel, because it perhaps best telegraphs the true intent of AMP

Is this not FUD? Reading the tea leaves and discerning the future. Personally I find Android Instant Apps a dramatically bigger threat to the vague idea of the web.

When has Google published pageviews?

Didn't say they did. They have, though, clearly done things to keep people on their properties vs straying off to the organics. Which is the same thing as pageviews.

Why else, for example, would hitting the back button 2 stories deep into a carousel AMP article not go back one article...but go all the way back to Google?

They don't publish their CTR for search pages either. You think that means they don't track goals for it internally?

Edit: Regarding this...

"Is this not FUD? Reading the tea leaves and discerning the future. Personally I find Android Instant Apps a dramatically bigger threat to the vague idea of the web."

Phrased as if I said AMP was their sole strategy. Of course they have multiple ideas to placate the investors that are used to double digit percentage YOY click growth. One does tend to focus on search since that's where the vast majority of their revenue is.

As for tea leaves, sustaining the same growth of stock price almost requires anti consumer and anti partner behavior.

Why else, for example, would hitting the back button 2 stories deep into a carousel AMP article not go back one article...but go all the way back to Google?

Given that it doesn't do this, at all, I'm not sure how to respond. Yes, if you open a story in the carousel and then swipe to the next story via the machinations of the carousel, then clicking back goes back to "google". But if you follow "organic" links it goes to a rote web experience.

Phrased as if I said AMP was their sole strategy

No, it's phrased as if you said exactly what you said, and needs no strawman. Whether you hit a Google cache or a host site means exactly squat. Google's core intention, it seems, is simply to try to provide a good experience for the user which is indeed a long term income strategy.

It's true that Google doesn't explicitly boost AMP pages. But it does boost all of the attributes that AMP enforces on a page (reduced page size, loading speed, etc). So it's an implicit signal boost rather than explicit. You may think that that's fine and there's nothing wrong with that, but no doubt Google see this as a way keeping users within the Google system as much as possible while they browse.

I'm personally on the fence regarding the whole situation. On one hand, I like less bloat, on the other I don't want a 3rd party involved more than is required in delivering a news article to me.

"It's true that Google doesn't explicitly boost AMP pages. But it does boost all of the attributes that AMP enforces on a page (reduced page size, loading speed, etc)."

So Google is guilty of making things that users want?

"Google see this as a way keeping users within the Google system as much as possible while they browse."

Well, isn't giving users what they want a way to keep them inside your system?

I don't see the point in your comment, are you saying that Google should not be optimizing for what users want?

So Google is guilty of making things that users want?

Well, I'm a user and I don't want this.

I want Google to not invent a new format for web pages, and instead help make the actual web faster.

"Well, I'm a user and I don't want this."

You (and myself, and anyone reading HN) are not the target user for this, nor are you representative of the typical internet user.

Remember, India has more internet users than the US has people.

And you can just not click on AMP sites if you don't want them.

Indian users are the worst example for this, given the regular 2G connections. Hundreds of KB of JS is not helping this, especially not on low-end mobile devices.

It is helping this when you consider all the JS is cached because they've visited an AMP page before.

You (and myself, and anyone reading HN) are not the target user for this, nor are you representative of the typical internet user.

Yes, but the typical internet user has never heard of AMP and wants it even less...

Remember, India has more internet users than the US has people.

Which can always use simple lightweight html pages instead of AMP with its JS cruft?

"Yes, but the typical internet user has never heard of AMP and wants it even less..."

But they might have seen the icon, and realized it means "it loads fast!", and they want it.

Users want faster pages, we can agree on that, correct?

They don't know what AMP is, and don't care about it.

"Which can always use simple lightweight html pages instead of AMP with its JS cruft?"

You can, but no publishers seem to want to do so. But you can. AMP is optional.

also, YouTube's embedded player is 1.17MB js minified (~411KB gzipped) [1] this is why we simply self-host our mp4s w/ <video> tags.

I find that as a user this is an often not ideal. For starters I probably have the JS cached. And the videos almost always going to play faster and more smoothly from google CDN versus some homebrew solution.

For starters I probably have the JS cached.

this is one of those fallacies that people keep repeating and actually believe as truth. if you look at the headers of the youtube player file i linked, you'll see that anyone who had it cached prior to Wed, 28 Jun 2017 18:12:45 GMT is out of luck as well as myself when i request in > 48 hours. i dunno how often it changes, but it's safe to say "very frequently".

    date:Wed, 28 Jun 2017 18:23:58 GMT
    expires:Thu, 06 Jul 2017 18:23:58 GMT
    last-modified:Wed, 28 Jun 2017 18:12:45 GMT

also relevant: https://twitter.com/HenriHelvetica/status/877924754195324928

And the videos almost always going to play faster and more smoothly from google CDN versus some homebrew solution.

Speaking of this, why do all of those annoying autoplaying videos on every major news site always take ages to load? Every YouTube video starts playing instantly, but when I click a link to any news site I literally have to sit there waiting over 5 seconds for the video to start playing so that I can pause it again (because otherwise it will start playing after I've already started to scroll down), even though I have a reasonably fast connection.

The homebrew solution can also be a CDN, just not Google's own.

Also, this greatly depends on the audience size: 30 users / hour might not need a CDN at all.

The CDN isn't just about volume, it's about location and bandwidth. It doesn't matter how many users you have, if the user is in Uganda and your server is in California, the video will never load immediately.

And even then, how would you create a homebrew CDN?

Sure, you could buy bandwidth, storage and processing capacity in multiple DC providers around the world and build, deploy and maintain your own solutions, at which point you're essentially becoming a small CDN with significantly higher costs as you don't have the efficiencies of scale and 100's (or 1000's) of multiple customers.

The CDN isn't just about volume, it's about location and bandwidth. It doesn't matter how many users you have, if the user is in Uganda and your server is in California, the video will never load immediately.

But isn't it true that as long as you can send >1s of video in 1s, it doesn't matter? I.e. latency doesn't matter much in video streaming, and bandwidth doesn't need a CDN for the 30 users / hour case?

Also, latency probably doesn't matter for 99% of sites, which are already so bloated with JavaScript and other pointless content that processing time dwarfs the connection delay.

this is why we simply self-host our mp4s w/ <video> tags.

So that I get way worse performance on trying to stream your videos than with YouTube's CDN?

Seriously, anything besides YouTube (from Vimeo to Comedy Central, CNN, any site that self-hosts) is exceptionally sluggish...

our traffic levels (as 85% of all sites) are low enough where the experience is significantly better to self-host without involving third party HTTPS connections or dependencies.

if we had an uptick in traffic, we would use a CDN to host the vids as long as the CDN didnt require that we swallow a 1MB js player for the pleasure of doing so.

A CDN isn't only for helping you handle large amounts of traffic. It also makes sure the content is close to the user so they get a better experience.

It's not about the load on your servers.

It's about the CDN being optimized for my (or any other user's) region...

AMP plugins are (supposedly) designed to be the fastest/lightweight/user-friendly implementation of a specific functionality.

Yes, if all you consider by "bloat" is how many kilobytes of javascript you have on the page, AMP is not doing well. This is a crucial mistake in this post. In reality "bloat" is more than that. It also refers to whether there's active javascript slowing the browser down, whether resources are cached etc.

The purpose of having these small plugins that enable functionality is that they are all individually cached by your browser for a good amount of time. Any Google user would have them cached as they are all using the same reference that any other AMP page would. This is unlike other "bloat" where resources are fragmented and come from any number of sources that users probably haven't hit before. In addition these JS resources wouldn't have been written for a specific experience - which AMP is

I’ve tested the AMP and regular versions of a The Guardian article page, and the AMP version is more than 4 times smaller in terms of transferred KBs, coming in at about 300 KB. Yes, JavaScript represents more than half of that size, and there are 16 separate script files, but in comparison to the regular page, it’s a significant improvement.

Note: I’ve tested with an ad/tracking blocker.

That 150KB js needs to be executed in the browser, most of which could be simple HTML and CSS.

The funny thing is that that Guardian article page is probably less then 10Kb in content to begin with. It's all the cruft on the page that makes it large, and AMP is also cruft, just less of it.

I mean, I still can't make Get Cryptolocker[0] show up on Google.

Hmm, I wonder if that's something to do with the fact that you're literally distributing malware...

Surely there are legal issues here too?

[0] getcryptolocker[.]com/get/

Edit: According to the about page, it isn't really cryptolocker, but VirusTotal still isn't happy about it: https://virustotal.com/en/file/0a2816af8a0580b0f58cb4ee1f102... I'm sure that in itself will hurt rankings.

Edit: According to the about page, it isn't really cryptolocker, but VirusTotal still isn't happy about it ….

Since you've obviously followed this up, for the benefit of those of us who don't want to follow the link, could you explain what it is?

I haven't used AMP, but my impression with all of Google CDN JavaScript files for AMP is the end user has to download them just once per version (which I agree will lead to a bloated first load experience) but on subsequent requests throughout the AMP network they'll be loaded from cache. Similar to how Google recommends you load jQuery through their CDN since millions of people already have it in cache.

And then you have to waste your battery on running 100s of kbs of JS to show static HTML.

No thanks.

But you'd rather go to the non AMP version which is 10x as bloated?

It seems like the vision in your head is: AMP vs. Perfectly optimised site. In reality it's publishers who have built their main site over several years with massive bloat and are unable for whatever reason to optimise.

What google could do instead, if they really cared, is incentivise simple javascriptless static HTML. They won't do this though, because it makes tracking for ads harder.

This seems to be the main recurring argument against AMP.

It isn't a comparison between AMP and the current web, it's a comparison between AMP and this utopian case where the entire web is simple javascriptless static HTML.

It's like the ascii ribbon against HTML email...

The diffence is that google has the power to improve the web and instead they warp it for their own profit while saying they're improving it.

No one doing the ASCII ribbon thing could change what the majority of mail users saw when they opened their mail clients.

Breaking down a few of the concerns in this article:

Google's v0.js, which is compulsory on every AMP page, is currently 217Kb of Javascript.

It is only 67KB gzipped, so it's not as bad as suggested, but this is an area for improvement.

However, the file size doesn't directly translate to the implied latency, which is really what we care about. There are several reasons why this is much better than your average <5KB javascript files:

- The file loads with an async tag, so does not block rendering.

- The file uses a stale-while-revalidate header with 30-days, which means that any user who views any amp page on the web once a month will never wait for this file after the very first page load. That's most users.

- If the page is loaded from the AMP cache, which is probably the common case, the file has a 1 year expiration.

- The javascript uses a foreign fetch service worker to implement the same 1-year effective expiration on the non-AMP cache page views, for browsers that support it.

Google's default analytics.js is 30Kb. The AMP compliant edition of amp-analytics-0.1.js - is 80KB.

All of the same responses as above apply here too. It's actually only 27KB on the wire, uses stale-while-revalidate and foreign-fetch service workers, etc.

However, this is also not a completely fair comparison. amp-analytics doesn't implement Google Analytics, it implements every common analytics vendor on the web and has a configuration system for novel vendors. Most pages have half a dozen vendor's scripts running on them each with their own javascript payload and running code. This produces a single analytics event runtime and dispatches events to all of the vendors you want to run.

Another advantage here is that it's not a new origin to connect to. Even if it's not cached, the DNS and HTTPS connections will be shared with v0.js and any of the other extensions. Depending on your connection, this will almost certainly reduce latency more than the added bandwidth.

you can still embed bloatey ads

True, however what is less obvious is that those ads cannot block the main thread for loading the page, so they can't cause issues with scroll or displaying content. In fact, the ads don't actually load until right before they should be in the viewport. The ads also cannot reflow the layout of the page, making content move around as the page loads.

you could dynamically build a page using a mustache template

True, but you cannot do so using custom javascript on the client which often blocks the rendering thread. This is a direct mapping from json to html.

The other is to append #development=1 to a URL. Unfortunately, if you try that here, your browser will crap out with errors about CORS and a CSP violation.

The issue here is that the validation must operate on the original source of the document. By the time javascript runs, the browser has modified the DOM to the point where the original string is simply unavailable. So the #development=1 trick works by refetching the document using an XHR which only works in certain CORS environments. I'm not sure how else to do this. If you want to validate docs often, I recommend the chrome extension instead (https://chrome.google.com/webstore/detail/amp-validator/nmof...). There are ports for other major browsers.

Paraphrasing: you can still load animations, large images, videos, etc.

True, but you also don't have to. All of the code for loading these things has been optimized so that while it still may take a while to load those embedded objects, they won't slow down the rest of the document, which is the main advantage. They also won't cause re-layout events causing content to jump around while the page is loading.

As a test, open up the network panel on chrome devtools, simulate a mobile phone with a smaller viewport, and hard refresh the page. You'll notice that the 9MB image included as a demo doesn't even get fetched. It's only when you scroll down halfway on the document that this image starts loading. This is what the amp-img component is accomplishing.

The author appears to want fewer html features supported which is understandable, but it's not clear that this opinion is widely shared.

this image will helpfully render with three dots in the middle to show you it's full of AMP goodness or something.

It's a loading indicator, the dots disappear when loading is complete. This is admittedly an odd effect with an animated gif, since the loading is still happening after the first frame has completely loaded.

Hi Greg,

Thanks for your response here. I think we'll just have to agree to disagree on a number of points, but there's a few I would like to comment on:

    If the page is loaded from the AMP cache, which is probably the common case, the file has a 1 year expiration.

As per the screenshot, Google Pagespeed appears to disagree. Looking at the headers via curl, I see "expires" with the current date and time (ie, it's already expired), a max-age tag of 50 minutes. I'm not seeing one year anywhere.

If the 30 day stale-while-revalidate really invalidates those two headers, and I'm not knee-deep in browser support enough to really know, can someone at Pagespeed please consider this a bug?

The issue has come up a number of times on various forums over the years in relation to the vanilla analytics.js, and the answer that's usually accepted is "just self host the Javascript". I'm calling it now - people will start doing this with AMP scripts if Pagespeed doesn't change the warning, regardless of the consequences.

     trick works by refetching the document using an XHR which only works in certain CORS environments. I'm not sure how else to do this.

Thanks for explaining that. It makes sense in a way I don't see another way of doing it - but the AMP website[0] suggests this should "just work". If it in fact only works "in certain CORS environments", what I'm hearing is that most people testing these AMP sites just have those environments and assume everyone else does. Which may be concerning from a security point of view.

[0] https://www.ampproject.org/docs/tutorials/create/preview_and...