AMP: the missing controversy

Some of us do/did pay for gmail. Also you could stop using Google all together as I have for this exact reason. (Specifically no way to disable AMP). I’ve been using bing/duckduckgo for search and icloud for email for a few years now. The only reason Google gets away with any of this crap is how many people refuse to switch to another service so yes voting with your wallet/wall clock will get results.

> Links to other implementations

1. Google dominates search. So other caches are basically irrelevant

2. To create a competing cache you need to make sure Google's search uses that cache and that your cache is big, fast, and powerful enough to pre-render AMP pages on Google scale

Which comes back to the original problem: AMP is not fast until someone caches and pre-renders it.

> Custom elements are in the WebComponents spec, which is "valid HTML".

Will all of you "opponents" please read the article you comment on?

Since you can't, here is the six paragraph:

> AMP makes up its own standards that break with what is considered valid HTML. Case in point, have a look at how the AMP project’s homepage, which itself is an AMP page, produces over a 100 validation errors

You can check it yourself.

> Then why did you ask to see other caches? You're moving the goalposts.

No goalposts have been moved.

Once again. Slowly:

---- quote -----

AMP is designed by Google, and implemented almost exclusively by Google. It is also used in the most popular search engine in a way that makes AMP feel like it's fast.

Meanwhile: - it's not fast without Google's overpowered cache/CDN (that no one has a chance to replicate)

- it's not even valid HTML

---- end quote ----

You cannot replicate Google's cache for the following reasons:

- Google's search is dominant.

- Google's search uses and will use Google's own AMP cache.

- Google's own AMP cache relies on Google's infrastructure.

Even if you create an AMP-compliant cache:

- Google will not use it.

- It's highly unlikely that you will be able to match its power and speed.

How is AMP open and fast again?

> By a validator that doesn't understand HTML5. Try your browser

Nope. The browser is able to render AMP pages just because the browsers have historically tried to make the best out of shitty HTML.

Let's start from the top.

Do you know that this is invalid HTML 5?

HTML5 living standard sections 4.1.1 and 3.2.6.

Do you know that this is invalid HTML 5?

HTML5 living standard sections 4.12.1 and 3.2.6.

Do you know that this is invalid HTML5?

HTML5 living standard sections 4.2.6 and 3.2.6.

Shall I continue?

You see, in order to know that it's enough to just stop drinking in Google's propaganda and actually look at what the web has to offer, and how all of this stuff works.

> It won't fix this. The only thing it will do, it will let browsers show the original link, not the AMP link, and fix the UI. The problems described in the article will not go away.

No, it does more that, it does away with the need to use iframes which break scrolling, and it allows all sites to use preloading without violating privacy see https://redfin.engineering/how-to-fix-googles-amp-without-sl...

"If other browsers accepted the Web Packaging standard, the web might look rather different in the future, since basically any site that links to a lot of external sites (Reddit? Twitter? Facebook?) could start linking to prerendered Web Packages, rather the original site. Those sites would appear to just load faster. Web-Packaged pages could one day eliminate the Reddit “hug of death,” where Reddit’s overenthusiastic visitors overwhelm sites hosting original content.

Despite cries that Google is trying to subvert the open web, the result could be a more open web, a web open to copying, sharing, and archiving web sites."

>Are they though? When for every search google preloads tens of AMP sites to make them "fast"?

TheVerge.com non-AMP loads 3MB of data, 289 HTTP requests, executes 1.5Mb of JS. Going to Google.com and searching for Verge stories produces 10 carosel Verge stories, and according to Chrome DevTools, only 377kb was loaded, though this seems oddly wrong, I doubt prefetching AMP stories will exceed the shitty bloat of non-AMP pages.

WashingtonPost non-AMP homepage is 6MB+

NYT non-AMP is 4MB+

WSJ non-AMP is 5.7MB

And by non-AMP, I mean "mobile web version" The desktop versions are even larger.

Can you see the problem?

Here's another way for you to understand the problem.

Here's my page: https://dmitriid.com/blog/2016/10/javascript-tools/

It's prerendered (via a static site generator). In total, it loads 692 KB (I din't do anything to optimize it, the images are quite large etc.). It loads from a small server, and images are loaded from Twitter, meme.com etc.

Here's an AMP page: https://www.google.se/amp/s/www.usmagazine.com/celebrity-new...

It loads a whopping 2.9 MB [1], and keeps loading as you scroll down. If you open it from Google's search, it opens instantly. Because parts of it were already preloaded on the search page. And the page itself (including almost all images) is served by a ridiculously powerful geographically distributed CDN.

So, questions/hints

1. How is that fair to people who actually build their pages and host them on their servers?

2. What is open about this web?

3. How will Web Packaging solve this issue if I can't afford to build a geographically-distributed CDN on par with Google's for my own cache?

---

[1] It actually changes on every reload. The lowest number I've seen is 1.6 MB, but then, in a second or two, it starts loading additional stuff, going up to at least 2.2 MB

So much for "small APM pages". Actually, as I'm clicking around, rarely is a page below 1 MB. Even for pages that are not that different from mine: only images and text.