
Neither PWA nor AMP are needed to make a website load fast - Scarbutt
http://tonsky.me/blog/pwa/
======
Solar19
The author says you can do these things anyway without AMP, but what he
doesn't get is that web developers were not doing them. It took the nudge of
AMP to get decent performance on the mobile web.

He also failed to mention a key AMP rule: all CSS is in the head, a max of 50
KB. There is no external CSS at all. That's crucial. It reverses a persistent
anti-pattern in web development that calls for a bunch of separate files for
CSS and JS. Almost all CSS on most webpages is unused (this is still true of a
lot of AMP sites -- 50 KB is way too much CSS for an article).

I think the reality here is that early 21st-century web developers are
terrible at web development. They stuff massive amounts of JS and CSS down
users throats, distributed across 50 or a 100 requests, and call themselves
"engineers".

AMP, or something even better, needs to be the default way to build websites.

~~~
Lukas_Skywalker
I know nothing about AMP, but isn't having the CSS in the head pretty bad for
caching? An external file can be fetched once by the browser and then cached
forever, while having the CSS in the head forces that part to be downloaded
over and over again?

Edit: I just realize that others posted the same concerns below...

~~~
criddell
If I'm pulling the page over an encrypted connection, is there any opportunity
for caching?

~~~
acdha
Yes: your device can always cache it, if you use a trusted proxy (think
enterprise networks) it can be cached, and if the site uses a CDN it can be
cached there as well.

------
pandapower2
>I’m not saying practices promoted by AMP are bad or useless. They are good
practices. But nothing stops you from following them in the regular web.

Disagree.

The most important feature of AMP is that it makes it impossible to add the
kind of bloated crap that causes poor performance on something like a large
media company website.

Something like a news website likely has 2-4+ analytics integrations, and a
similar number of ad provider integrations.

Your staff want to use google analytics so that goes in. Your display ad
provider (ads appearing in the page around articles) uses some other analytics
provider so they have to go in. You want video ads so another ad provider who
requires a video specific analytics provider goes in. Site rankings produced
by someone or other are important to get direct ad sales so their required
analytics integration goes in. Then someone in sales signs some deal to add a
third party widget to your homepage so that goes in.

All of this happens over the protestations of the developers. People may
literally quit over these integrations but their replacement will implement
it.

Turn off your ad blocker, go to a news site, watch the network tab and
despair.

AMP makes that crap near enough to impossible that the developers can convince
the sales team and management that it simply cannot be done.

~~~
saagarjha
Except it does so in a rather poor way:

* It's clearly driven by a biased entity (Google)

* It doesn't actually directly prioritize page speed

* It breaks websites

~~~
izacus
The web development community had plenty of time to fix these problems in
better ways and it instead just spent time building bigger and bigger JS
frameworks and background videos.

~~~
raxxorrax
What problems exactly? The web works pretty well and the source of most
problems is non-technical. AMP is cache + handcuffs. No, thanks. I am no web-
developer, but pretty sure I wouldn't want to touch that. Is performance
really an issue these days? It probably always is but there are worse ones.
One specifically being closed web technologies administered by large companies
like Google.

~~~
tonyarkles
The number of times I open a news article (local/regional seems to be the
worst) on my phone, start reading the article, and then 10-15 seconds later
have the whole thing go blank, reflow, and start me back at the top of the
page... I haven't spent any time investigating what actually causes it,
whether it's a stylesheet or a big JS module or what, but it's absolutely
enraging. I'm just reading what could be plain text content, and that flow
gets horribly interrupted.

I'm really torn on AMP to be honest. I'm morally and technically opposed to
it, but... the experience is often dramatically better than what I would have
gotten without it.

------
osrec
But you do need "PWA" if you want your site to work offline. PWAs were never
really sold as something that would make your site's initial load time faster.
Not really sure how the author got that impression.

It's almost like saying "you don't need jQuery to make your site faster" \- to
those who understand the purpose of jQuery, it's a bit of a nonsensical
statement.

~~~
starik36
Can't you just use ServiceWorkers in a regular webpage? Seems like you can.
That would allow you to have an offline persistent website while still using a
webpage.
[https://caniuse.com/#feat=serviceworkers](https://caniuse.com/#feat=serviceworkers)

~~~
osrec
There seems to be a few misconceptions around what is and what isn't a PWA. A
PWA (in my opinion) is simply a website that makes use of certain browser
features (e.g. service workers, push notifications, manifests). It's a bad
definition, with a lot of grey areas, but it is what it is (and let's face it,
definitions in web development are often hard to pin down).

For example, we built [https://usebx.com/app](https://usebx.com/app) with
plain old HTML, JavaScript and CSS. Yet, it can be installed on your phone,
send you push notifications and even works offline. So I would categorise it
as a PWA rather than a website.

My point is, if you're using service workers, you're more a PWA than a
standard website.

~~~
dkrikun
gj using plain old js+html, very nice))

~~~
osrec
Thank you!

------
Spivak
Well yeah but the author is missing the point: these tools allow your site to
load faster than the theoretical limit without them.

AMP buys you Google's CDN and prefetching on Search.

And PWA buys you a 0 distance cache hit on your second visit, the ability to
prefetch unvisited resources, and with the ability to update the cache in the
background.

Not saying these aren't negligible on a 15MB site but they are tools for
making an existing slow site appear faster which is what everyone who isn't a
dev really wants.

~~~
dvtrn
_on a 15MB site_

Good lord, friend. Why put your users through this to begin with?

~~~
osrec
If it's just a website, then I agree that is indeed excessive. If, however,
it's 15mb of useful functionality (perhaps an app that lets you edit and
encode video), then in my eyes, it's acceptable, and probably a good candidate
to be a PWA.

I know a lot of people hate the idea of doing everything in the browser, but
seriously, it's the one ubiquitous platform that we have, which even competing
entities have agreed to standardise. I personally think it will be the most
popular app delivery mechanism in the next few years, even on mobile devices.

~~~
dvtrn
_If, however, it 's 15mb of useful functionality (perhaps an app that lets you
edit and encode video), then in my eyes, it's acceptable_

You either have an abundance of high speed internet access, or benefit from
internet usage that isn't metered by the amount of data consumed, or both.

Functionality or not, heavy web experiences leave out a lot of people who
would otherwise be willing and capable users of %product% if it weren't for
the excessive payloads they're often expected to consume just to be a user
when that payload could quite trivially be reduced and still accomplish the
goal of delivering content and information to the end user.

So here's my question: forget about people who hate doing everything in the
browser, what about the users who just don't have access to Cable+ internet
speeds, want to use the product, but perhaps can't because they're downloading
15, 20, 30MB websites just to fill out a form element _because the browser is
all this user is familiar with_?

Not everyone on the internet is a regular of HackerNews who groks native
applications versus web apps. At what point do we start focusing on the
_content_ and asking ourselves "Do I REALLY need this animation library just
to indicate 'Start here' is where they should be interacting with my webform"?

To answer that rhetorical question for you: probably, quite likely not.

~~~
zdragnar
> but perhaps can't because they're downloading 15, 20, 30MB websites just to
> fill out a form element?

Parent post (in fact, the segment you quoted) _literally says_ that it's okay
when it is useful functionality, i.e. _not_ when it's just to fill out a form.

Sadly, these aren't going to get to experience a decent chunk of the internet
anyway, since video, gifs, and images all frequently weigh significantly more
when put together.

~~~
dvtrn
_Parent post (in fact, the segment you quoted) literally says that it 's okay
when it is useful functionality, i.e. not when it's just to fill out a form._

Since when did forms become useless and what web-based video editor are you
(or the original reply-er) pointing to that uses AMP?

~~~
zdragnar
We're talking about two completely separate types of websites. Nobody said
forms are useless. Web-based video editing was a hypothetical example. AMP
wasn't really part of this discussion; presumably, lots of JS + PWA
functionality in the hypothetical video editing example was the referenced
useful functionality.

Take Google Sheets as an example. I don't know what the total download size is
for the JS (certainly not 15mb), but it's an example of a JS heavy website
where you wouldn't want to serve -> submit form -> serve cycle for every user
input.

~~~
dvtrn
_We 're talking about two completely separate types of websites. Nobody said
forms are useless. Web-based video editing was a hypothetical example. AMP
wasn't really part of this discussion_

This entire discussion started from an opinionated blog post that _directly_
discusses AMP and it's performative nature on the web.

So yes.

It is.

You can't just invent a hypothetical that makes it easier to justify
exceptions to the very topic the original blog post we're talking about here,
of _course_ exceptional things like resource-heavy, full-featured web apps are
going to be outliers to lightweight payloads for web apps. For some reason I
highly doubt those were the types of use-cases Google had in mind when AMP was
released, so why are we even considering exigent outliers on this one?

------
aethertron
In defense of PWA, specifically the value of offline-availability:

> _You can’t call Uber while being offline, and why would you open Uber app
> otherwise?_

To see my journey history. Uber has this data. It's my data, why shouldn't it
be on my device too?

> _Tinder is useless offline. You can’t date empty chat screens._

I could look at my messages offline, if they were saved on the device.

> _You can’t join a meetup at Meetup.com without network connection._

But I could look at my calendar and see upcoming stuff for the days ahead, see
past events, my message history, and profiles for my groups.

All this stuff loading from a local cache could improve speed. But that's just
a bonus.

------
geuis
AMP is a fucking cancer on the web right now.

When you visit what you expect to be a search result url, it should take you
to the server/site that was indexed. When AMP for launched, it didn’t even
provide a link to the original site. It took a lot of people like me grousing
and complaining before Google’s 17 tiers of product managers had enough
meetings to even budge on that.

I honestly can’t tell you how so many sites were convinced to implement AMP on
their sites. I could wave my hands and say everyone is stupid and just goes
along with the latest shiny bullshit but that can’t be but a small part of the
actual answer.

Supposedly Google isn’t factoring AMP pages into their search rankings yet,
but given the positive signal of page speed (a good thing, generally) and them
switching to a mobile first index, a natural direct side effect is that AMP
pages will be ranked higher by default.

If Google were somehow automatically transforming sites you’d never hear the
end of people complaining, especially content owners. Instead they convinced
engineers and content creators to tie the rope on the hanging post themselves,
jump off, and be happy about it.

I can’t speak too negatively of PWA. The ability to build offline web apps is
actually pretty useful in some situations.

Overall I still firmly believe that a good search engine should deliver the
most relevant links or content for what is being queried. Should a bad QA site
get ranked higher than a high quality one just because the former delivers
mobile-first AMP pages and the latter has a slightly bigger payload but has
much more relevant content?

------
naikrovek
I agree with the article author.

Performance today is not a priority for web developers. It's not even in the
top ten priorities. Performance is just not considered unless it is so bad
that a site looks like it isn't working.

We can change this at any point we like. We won't. It will continue to get
worse.

~~~
Romanulus
It's a shame since all hardware is getting slower and slower every day.

~~~
naikrovek
That kind of thinking is why people STILL wait on computers to do things that
could be SO MUCH faster.

Why the hell does it take an application like Photoshop 30 fucking seconds to
simply launch and get to where it can accept input on my 32-core, dual-Xeon
desktop at work with 192GB of RAM and a very fast SSD? Because people punt the
fucking problem into the future and assume everything will just continually
get faster

------
jillesvangurp
Amp is not about making your site fast but about making sure that sites
aggregated in e.g. Google News are all predictably fast by constraining what
they can do. It's not about making the individual sites fast but making sure
that none of them are needlessly slow by imposing constraints.

Similarly PWA is also not about performance but about adding metadata that
phones and browsers can use to treat the site like an app by e.g. giving it an
icon in an app folder. You couldn't do this before, now you can. Before people
were doing silly things like packaging up websites as apps and putting them in
the app store just so they could their own cute little icon in somebody's app
folder. Now they don't have to do that and the install/discovery is a bit
smoother as well (easier discovery, less steps, less users lost).

~~~
jjulius
>... but making sure that none of them are needlessly slow by imposing
constraints.

Anecdotally, AMP sites always load a bit slower for me. The page will sit
blank for a few seconds before finally dumping all of the content at once, as
opposed to loading text immediately while it takes a moment to load the rest
of the content that has a higher file-size.

Without AMP, I can start reading a page before it's done loading. With AMP,
especially on a desktop, I'm often stuck staring at a white screen for 15-20
seconds before anything shows up. I often find myself trying to cut the "amp"
bit out of the URL to see if I can get to the original page. It's frustrating,
and it is a big part of why I'm considering dumping Google as a search engine.

That's just my experience, though - YMMV.

~~~
ayoisaiah
AMP on the desktop? Don't think I've seen that before. I've only seen AMP
links on mobile and I don't think it's returned in desktop search results

~~~
jjulius
You're correct - Google search results don't return AMP links on desktops, but
that doesn't stop me from stumbling upon them.

If you come across an article you want to share from your mobile device, and
it's an AMP link, it's the AMP URL that gets shared if you post it on sites
like HN, FB or Reddit. If I'm browsing those pages from my desktop, clicking
that link almost never redirects me to the "original" page, but loads the AMP
page in the desktop browser. Sometimes getting around that is as easy as
cutting out "/amp/" from the URL, other times it's a totally different URL and
I'm stuck staring at a blank page for 30 seconds before it either loads, I
just give up or I Google the headline/title and try to find the original page.

Forced AMP results on mobile devices also make it difficult to get to certain
pages when I want them. Take Eater's 38 lists[1] that they put together. If
I'm on my phone and want to find a restaurant from that list in a particular
location (say if I'm out of the house and want restaurants near me), then the
AMP result returns a page that doesn't include the map, only a list, which
isn't very helpful. In order to get to the map, I either need to go to
Eater.com and manually find it, or use something like Bing to search for it. I
know that the purpose of AMP is to _not_ load the map in an effort to increase
speed, but in that instance the map is exactly what I want and AMP makes it
harder to get to.

I'm not saying AMP doesn't have its benefits, but its inconveniences have
outweighed them, in my experience.

[1][https://sf.eater.com/maps/best-restaurants-san-
francisco-38](https://sf.eater.com/maps/best-restaurants-san-francisco-38)

------
askaboutit
Wikipedia is a static delivery website. Of course it’s easy if all you’re
delivering is static content. Try that with an ecommerce site where dynamic
information is sent from sometimes multiple sources. It’s better to load it
once and have a reactive site call just the necessary apis after. Calling
everything over and over again in eCommerce is a pain for users. Unless you
can afford a database and servers to be distributed globally to counter the
added latency of downloading everything again and again. PWA is the next step
for that. But, yeah, ok, for Wikipedia you can be static as you want.

~~~
jmull
> Wikipedia is a static delivery website.

What do you think all those little "Edit" buttons all over wikipedia do?

~~~
adventured
> What do you think all those little "Edit" buttons all over wikipedia do?

They take you into the CMS where you can produce more static content.

------
robinanil
At Tock we had been obsessed with page load performance since the beginning
and I agree with the author. We avoided PWA mostly due to it's broken
behavior. Often times we are faster than loading the same restaurant page on
Google search.

Out challenge has been that we have to load a lot of images, so we spent a lot
of time optimizing everything around it and optimizing everything around it.
From TLS1.3 to the CDN, to every part of our stack.

Try it out

[https://www.exploretock.com](https://www.exploretock.com)

[https://www.exploretock.com/tfl](https://www.exploretock.com/tfl)

~~~
robinanil
Also ours is not a static page, it has dynamic content, and ga + fb tracking
for our restaurants and we make it work by correctly prioritizing important
rendering elements over other

~~~
robinanil
We have also spent time reducing the initial JS parsing size by chunking out
our ever growing JS bundle and we constantly test on slow devices on 2g/3g
profiles to emulate bad internet conditions. We have learned a lot in the
process probably good for a blog post

------
tyingq
It's not the hype that has publishers moving to AMP. It's not wanting to be
dropped out of the carousel. Shame if somethin' were to happen to yer website
traffic, friend.

~~~
ravenstine
Having worked for a publisher, it's definitely carousel FOMO. Some of it is
the Google hype, but the carousel is 90% of it.

------
cheeaun
The footnotes mentioned:

> By the way, since you first opened this article my ServiceWorker has
> downloaded XXX Mb of useless data in background. I hope you are on WiFi :)

But the code doesn't really download anything. It stores the intial datetime
your first load the page, and diff to the current time, convert it to "bytes"
every second.

~~~
omeid2
[http://tonsky.me/sw.js](http://tonsky.me/sw.js): "Totally legit ServiceWorker
ES6 implementation";

------
androidgirl
I agree on AMP, you can just pack less JS and be done with it. But AMP is
REALLY about rich search results online.

Google creates more interactive search results for AMP pages than non-AMP
versions.

As for PWA's, I'm honestly a fan, to a certain limit. I really like Gatsby.js,
especially because the rendered pages work with Javascript disabled.

Django/Rails/$FRAMEWORK with Turbolinks.js is also great, for the same reason
I like pwa's. If you aren't a fan of the JS ecosystem (totally fair),
Turbolinks is a great way to get some ""snappyness".

~~~
lern_too_spel
Microdata is for rich search results. AMP is for instant (not fast, as the
author mistakenly stated) loading from a search results page or content
aggregator.

~~~
androidgirl
True! But Google incorporates more microdata from AMP pages in Search results
(as in more fields), or at the least their Rich Search Results documentation
makes it out to be that way.

I may be wrong, this just was my understanding from reading all the Google
search guides last week.

------
gambler
Google is steadily undermining the foundational principles of the web that
made the platform so popular and allowed Google to do searching in the first
place.

The scary part is that they don't just offer an "alternative" technology like
ActiveX, Flash, Applets, Silverlight and so on. They are influencing core web
standards.

------
deepakkarki
It's true, that with static sites you're better off without any JS. It's
pretty much how I've built [https://discoverdev.io](https://discoverdev.io)

It's powered by a home grown static site generator framework. Hosted on
Netlify. Works fairly fast even random corners of India. But then I found my
own generator limiting and surveyed existing frameworks - decided to go with
Gatsby - a ReactJS based SSG. To my surprise Gatsby+Netlify worked much faster
and smoother than my JS free solution! It's currently running at
[https://beta.discoverdev.io](https://beta.discoverdev.io)

Worth noting that Gatsby generates pure html+css during build time, and page
renders fine without JS enabled. Seems to be a good balance between DevX and
UX. :)

~~~
_eric
Minor thing I noticed on your site: a clean load is requesting around 425kb of
data, but your /assets/img/dd-logo.ico alone weighs 362kb. Same thing happens
in your new site. Maybe it's something to look into, reducing the size of it
should make your site even faster.

~~~
deepakkarki
Oh thanks, I didn't notice :)

I guess I can compress a lot further, given it should be a tiny (34x34?) image
anyway!

------
AngeloAnolin
Want to load fast? Load less.

------
goofballlogic
I too struggle to like AMP. The rhetoric seems a little absent imagination in
regard to offline. Are you really saying your handheld computer can't be
useful without a worldwide network connection?

------
liuyanghejerry
The article is with prejudice somehow. You still need lots of apps which
working perfectly with offline mode. For example reading books you already
downloaded, watching movies you already downloaded, or whatever immutable
content you already have. The author choose to making examples with apps that
demands communications with outside world instantly, which makes the whole
point weak.

------
juskrey
Though we can find a lot of obvious overengineering cases, Tonsky should have
known better that reference-style website a la Wiki and feature rich
application like Airbnb impose very different trade offs between
initial/overall loading times and functionality.

An interesting case when someone who is firmly saying "BS" three times in
every paragraph is BS too.

~~~
ForHackernews
How is Airbnb a "feature rich application" compared to Wikipedia? They're both
Search+CRUD sites as far as I can see.

~~~
juskrey
Wikipedia user experience is basically a tree, Airbnb is a pretty complex
graph

~~~
ForHackernews
Wikipedia has editors, varying levels of admin permissions, different types of
pages, templates, comments, edits, etc. I'm not sure their data model is any
less complicated than Airbnb.

But regardless of the complexity of the database schema, neither one of them
is really an "feature rich application" in the way that that say, Photoshop,
is a feature rich application.

At the end of the day, I think they're both just CRUD apps.

------
scotchio
You don't need AMP if you want to make your website load fast, but you do need
AMP if you want mobile SEO organic clicks.

------
ridiculous_fish
AMP is embarrassingly buggy on iOS. The address bar doesn't hide properly,
rotation breaks things, the "original link" often triggers the address bar,
find highlighting is busted, and Reader Mode often fails.

AMP links are often slower than Reader Mode, because they're blocked on slow
font loading.

------
scoot_718
In my experience AMP makes a website not load, until it times out and
redirects to the non-AMP.

------
tylerjwilk00
Author has good points about PWAs. I love PWAs because I hate giving native
apps access to my phone's data but the emphasis on offline support for PWAs
does seem off point. It has Web in the name. You probably need internet
access!

------
fipple
The headline is analogous to “Antitrust laws are not needed to prevent price
fixing.” Treated as a statement of fact, it’s technically true, but it’s
really a statement of policy opinion, whose weaknesses are clear.

------
xte
Hem... To make a website faster... Make a website! Not a webcrap with tons of
"framework", tons of stuff loaded from third parties etc you'll get a
skyrocketing high speed.

------
ksec
I hate Service Worker. It literally provides a tools for website to abuse and
judging from the trend things will be much worst in the next few years.

------
edem
Definitely true. What you need is less js and more content. My site loads so
fast that it even works in a forest where there is only EDGE available.

------
aceon48
Lol this guy's site took over 10 seconds to load on my mobile. Invalidates
anything he had to say

~~~
rchaud
Ever heard of the HN "hug of death"? Sites load slower if there are a high
number of concurrent connections at the time you're trying to visit.

------
donohoe
I’ve seen many cases where AMP version of an article was slower to load than
the regular web version.

------
codedokode
I tried to look at an example AMP page here [1]. When loading with an empty
cache, it loads 5.5 Mb of files. I don't see where are the optimizations.

It uses a custom font. Custom fonts are absolutely unnesessary for a news
page; they only delay the moment when text becomes visible. Standard Windows
fonts are of a good quality and don't need a replacement (which often renders
very poorly on Windows XP).

It uses a lot of scripts. Script block some browsers while parsing and
executing.

It has SVG images embedded into the page. If you want the page to load faster,
you should move images into external files.

AMP is directly linked to Google and cannot be used without it. Please look at
the requirements for AMP HTML documents: [2]

> AMP HTML documents MUST ... contain a <script async
> src="[https://cdn.ampproject.org/v0.js"></script>](https://cdn.ampproject.org/v0.js"></script>)
> tag inside 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='](https://ampcid.google.com/v1/publisher:getClientId?key=')
or
'[https://ampcid.google.com/v1/cache:getClientId?key=AIzaSyDKt...](https://ampcid.google.com/v1/cache:getClientId?key=AIzaSyDKtqGxnoeIqVM33Uf7hRSa3GJxuzR7mLc')
, 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](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...](https://amp.theguardian.com/us-
news/commentisfree/2016/feb/16/thomas-piketty-bernie-sanders-us-election-2016)

[2]
[https://www.ampproject.org/docs/fundamentals/spec](https://www.ampproject.org/docs/fundamentals/spec)

[3]
[https://github.com/ampproject/amphtml/issues/11294](https://github.com/ampproject/amphtml/issues/11294)

[4]
[https://github.com/ampproject/amphtml/blob/master/src/servic...](https://github.com/ampproject/amphtml/blob/master/src/service/crypto-
impl.js)

------
auct
Why it's so funny

Netflix recently found out that if they remove 500 Kb of JavaScript from a
static (!!!) webpage it will load WAY faster

I loled a lot:)

------
lern_too_spel
This guy doesn't know what AMP does. AMP is a subset of HTML that can be
validated safe to prerender. That means instant page loads for the user, not
merely fast.

~~~
tyingq
The outside bits of a Trojan horse are attractive for a reason.

~~~
lern_too_spel
It is the only available solution to a real problem. If you have a better
solution, by all means, be a hero. Meanwhile, the rest of the search and
content aggregation industry has gone with AMP, which works today.

~~~
untog
> the rest of the search and content aggregation industry has gone with AMP

Because Google effectively gave them no choice.

~~~
lern_too_spel
> Because Google effectively gave them no choice.

I'm talking about link aggregators and search engines, not publishers. They
could have come up with another solution, but they decided to use AMP, which
provides the same benefits to them as it provides to Google.

