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
>Google dominates search. So other caches are basically irrelevant
Then why did you ask to see other caches? You're moving the goalposts.
>produces over a 100 validation errors
By a validator that doesn't understand HTML5. Try your browser - it's a far more advanced version of the validator. You'll find it understands amp pages just fine.
> 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.
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.
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.