amphtml

ustom JS template engine made by Google. If you are an ad network then you have to make negiotiations with Google, your competitor, to be included into the whitelist. There are lot of whitelists: list of sites that can provide fonts, list of sites that can add widgets to AMP pages. Here is one example of such conditions [4]: > In order to qualify for inclusion, an extended component that integrates a third-party service must generally meet the notability requirements of the English Wikipedia, and is in common use in Internet publishing. As a rough rule of thumb, it should be used or requested by 5% of the top 10,000 websites as noted on builtwith.com, or already integrated into oEmbed. If you are a small business, you are not welcome. [1] https://amp.theguardian.com/us-news/commentisfree/2016/feb/1... [2] https://imgur.com/RGYij9q [3] https://imgur.com/j1IYaMW [4] https://github.com/ampproject/amphtml/blob/master/3p/README....

their head tag. So every AMP document MUST load a Google-controlled script. And by the way, it contains 12 000 lines when beautified. It contains different Google URLs like 'https://ampcid.google.com/v1/publisher:getClientId?key=' or 'https://ampcid.google.com/v1/cache:getClientId?key=AIzaSyDKt... , references to Doubleclick and AdSense (but not other ad networks). Does every site need it? It contains a lot of code not necessary for most websites. For example, a XHR interceptor for "some trusted AMP viewers" [3] is included into the script. Or a cryptographic library for calculating sha hashes [4]. You can use only JS components approved by Google; the spec says: > Extended components > The script URL must start with https://cdn.ampproject.org So for example, Google might make a custom component for Facebook but not for QQ or Mixi. Google defines what widget can appear on an AMP page. If you are an ad network, you have to make negotiations with Google to be added (you have to negotiate with your competitor). If US government imposes sanctions on some foreign site, Google will have to comply. It is clearly a technology made for integrating news articles into a Google page (and judging by limitations in the spec, Google might plan to make a non-vebview native renderer for AMP pages). Don't believe when they try to pretend that it can be used independently as a standard or made for accelerating the web. [1] https://amp.theguardian.com/us-news/commentisfree/2016/feb/1... [2] https://www.ampproject.org/docs/fundamentals/spec [3] https://github.com/ampproject/amphtml/issues/11294 [4] https://github.com/ampproject/amphtml/blob/master/src/servic...

native apps like Apple News. (It’d be better named FoF-HTML.) That’s the corporate side. And the way to do that was to massively overengineer solutions to problems that could have been addressed largely through SEO incentives (treat it as a spam problem) and left things like URLs (!) intact. Instead we’ll be left with years of AMP detritus that’s going to pollute the web for who knows how long. It’s all corporation-driven engineering and no spirit or science. No one is actually studying if these overengineered micro-solutions actually matter. All we need is more engineering! 3. Picking winners: Google used its own market dominance to bless AMP as the web framework of the future. It could have worked on common standards; it could have created other incentives, but it chose not too. Imagine if Microsoft actually succeeded in creating some kind of MS-HTML in the 90s or 00s. Thus there’s no market-driven competition for Google’s over-engineered solutions. 4. The cognitive dissonance inherent in the project: It’s an “open source” project that was born out of Google’s corporate interests. It has a public tech lead, but the actual Google exec above him responsible for the project doesn’t respond to anyone or answer anything. They cherry pick contributor stats to mislead the actual amount of Google-driven involvement. They desperately want it to be this thing of pure intentions for the benefit of the web and have us all singing kumbaya, but fundamentally it’s the product of a corporation acting in its short term competitive interests and using whatever engineering it has as its disposal to achieve those ends. 5. I still hate the UX. Reader mode support has improved but can be hit-or-miss, URLs are still broken and will be for years, and frankly I want to go to the actual web site and use Reader mode if necessary, rather than read the web through Google’s faux news reader. While developers have to maintain multiple versions of their code base (AMP & responsive HTML) things are going to break. And all this for what? Slightly faster page loading and Google Web Reader experience, so Google can stick it to Facebook somehow? Is there any data on people using the web more instead of apps en masse now AMP is a thing? What %? And does that make forking the web worth it? I guess we’ll never know. It’s such a shame. [1] https://github.com/ampproject/amphtml/issues/13597 [2] https://github.com/ampproject/amphtml/issues/13623

wledge/investigation/interest still seems to be above your own.

am has gone out of the way to derail, shut down and outright ignore any direct questions: https://github.com/ampproject/amphtml/issues/13597 - A regular AMP page rarely weighs less than 1 MB when reached from cold cache. The only reason they are fast is because: Google dominates search, and Google aggressively preloads AMP pages from its own huge geographically distributed CDN. So when you click on an AMP page it's instant only because it's already been preloaded. Meanwhile Google's own page speed tools say that AMP are not fast. And to add insult to injury, AMP is not even valid HTML5. https://ferdychristant.com/amp-the-missing-controversy-3b424... Of course independent superhackers can't do anything because they don't have Google-level infrastructure. Because Google makes AMP appear to be faster than even http://motherfuckingwebsite.com which is just text. Just a quote: "The performance benefit of prerendering is enormous, so enormous that prerendered pages can load hundreds of KB of JavaScript and still display “instantly” by the time the user taps on a link." https://redfin.engineering/how-to-fix-googles-amp-without-sl... - Taking the previous bullet point further: AMP is a hack that has nothing to do with actual website performance or "slimming down" of websites. The only reason AMP exists is because of Facebook Instant Articles. It's not because of walled gardens. It's not because of "open web". It's just the desire to not be outdone by competition and the strive for ad revenue and MAUs. It's a way to promote a few select websites and penalise every other website, even those who strictly adhere to Google's own performance guidelines: https://developers.google.com/speed/docs/insights/rules Any and all concerns about AMP where entirely dismissed by Google (and AMP team) until a significant portion of publishers have started voicing their concerns and some have even started pulling out of AMP. Why publishers you ask? AMP is primarily targeted at publishers and publishers are the only ones even allowed to somewhat participate in AMP. To quote "Standardizing lessons": "constant adjustment to publisher and user feedback." which is half truth at best. The only working group on AMP is amp-news-publishers (https://github.com/ampproject/amphtml/blob/master/contributi...), and any "user feedback" that is allowed is "intents to implement" and comments on how a feature is implemented. All other discussions are shut down. - The new standards proposed by Google only seek to cement the status quo. Web Packages is a way to store signed prerendered and preloaded pages on a CDN iframe promotion explicitly describes how and why AMP pages are "fast": they are preloaded in invisible iframes during search. The only goal of this proposal is to help google make those frames visible and switch the browser URL when the iframe is presented to the user. This does not actually solve any performance issues. You can still develop your 8 MB site. However, it will load instantly just because Google has preloaded it while you were searching. Do not be fooled by the use cases. The primary benefactor of aggressive preloading and caching is Google, who already has the entire infrastructure in place, and dominates search. No mater how much you try and adhere to all the performance guidelines, you will never beat a pre-rendered and preloaded page stored on Google's CDN. - And yes. Ultimately the AMP team in its entirety fails to accept or acknowledge any shortcoming of AMP. Even the "Standardizing lessons" spew the same easily falsifiable myths around AMP heavily sugar-coated in self-aggrandizement. On top of that, no matter how many times they say that the process is well-lit (they say it three times in the article), the process is entirely opaque, developed by Google, for Google, and in Google's products and then presented post-factum as a "standards proposal".