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 67K

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/nmoffdblmcmgeicmolmhobpoocbbmknc?hl=en 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.