
The bloat of AMP - technion
https://lolware.net/2017/07/04/amp-bloat.html
======
leeoniya
also, YouTube's embedded player is 1.17MB js minified (~411KB gzipped) [1]

this is why we simply self-host our mp4s w/ <video> tags.

Gmail and AdWords UIs are equally terrible/bloated perf-wise. the plain html
version of gmail [2] is still by far the best. for a company that built V8,
Closure Compiler, Chrome Devtools, PageSpeed Insights, Lighthouse, etc. they
really do a shit job on their own properties. Gmail went from the best in
performant webapps when it first popularized Ajax to the worst example of one
in 2017.

it's as if Google can't find good frontend engineering talent, i don't get it
:/

AMP is not a solution for slow pages, even if it's billed as such to clueless
content producers. AMP is a content lock-in and user tracking strategy with
the promise of boosted visibility/rank. nothing more.

[1] [https://www.youtube.com/yts/jsbin/player-
vfleyMpxV/en_US/bas...](https://www.youtube.com/yts/jsbin/player-
vfleyMpxV/en_US/base.js)

[2]
[https://mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui](https://mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui)

~~~
matt_wulfeck
> _also, YouTube 's embedded player is 1.17MB js minified (~411KB gzipped) [1]
> this is why we simply self-host our mp4s w/ <video> tags._

I find that as a user this is an often _not_ ideal. For starters I probably
have the JS cached. And the videos almost always going to play faster and more
smoothly from google CDN versus some homebrew solution.

~~~
leeoniya
> For starters I probably have the JS cached.

this is one of those fallacies that people keep repeating and actually believe
as truth. if you look at the headers of the youtube player file i linked,
you'll see that anyone who had it cached prior to Wed, 28 Jun 2017 18:12:45
GMT is out of luck as well as myself when i request in > 48 hours. i dunno how
often it changes, but it's safe to say "very frequently".

    
    
        date:Wed, 28 Jun 2017 18:23:58 GMT
        expires:Thu, 06 Jul 2017 18:23:58 GMT
        last-modified:Wed, 28 Jun 2017 18:12:45 GMT
    

also relevant:
[https://twitter.com/HenriHelvetica/status/877924754195324928](https://twitter.com/HenriHelvetica/status/877924754195324928)

~~~
TeMPOraL
A good point.

RE that tweet, I assume the values there are in milliseconds. I _hate_ it when
people don't label their axes.

------
SimeVidas
I’ve tested the AMP and regular versions of a The Guardian article page, and
the AMP version is more than 4 times smaller in terms of transferred KBs,
coming in at about 300 KB. Yes, JavaScript represents more than half of that
size, and there are 16 separate script files, but in comparison to the regular
page, it’s a significant improvement.

Note: I’ve tested with an ad/tracking blocker.

~~~
jacquesm
The funny thing is that that Guardian article page is probably less then 10Kb
in content to begin with. It's all the cruft on the page that makes it large,
and AMP is _also_ cruft, just less of it.

~~~
SimeVidas
The main content does indeed load after disabling JavaScript. The page size is
about 60 KB in that case.

------
Retr0spectrum
> I mean, I still can't make Get Cryptolocker[0] show up on Google.

Hmm, I wonder if that's something to do with the fact that you're literally
distributing malware...

Surely there are legal issues here too?

[0] getcryptolocker[.]com/get/

Edit: According to the about page, it isn't really cryptolocker, but
VirusTotal still isn't happy about it:
[https://virustotal.com/en/file/0a2816af8a0580b0f58cb4ee1f102...](https://virustotal.com/en/file/0a2816af8a0580b0f58cb4ee1f102dc507d4013a0c1fd42af285d269da6029ee/analysis/)
I'm sure that in itself will hurt rankings.

~~~
JadeNB
> Edit: According to the about page, it isn't really cryptolocker, but
> VirusTotal still isn't happy about it ….

Since you've obviously followed this up, for the benefit of those of us who
don't want to follow the link, could you explain what it is?

~~~
Retr0spectrum
I have no idea, I haven't tried running it.

------
monokh
AMP plugins are (supposedly) designed to be the fastest/lightweight/user-
friendly implementation of a specific functionality.

Yes, if all you consider by "bloat" is how many kilobytes of javascript you
have on the page, AMP is not doing well. This is a crucial mistake in this
post. In reality "bloat" is more than that. It also refers to whether there's
active javascript slowing the browser down, whether resources are cached etc.

The purpose of having these small plugins that enable functionality is that
they are all individually cached by your browser for a good amount of time.
Any Google user would have them cached as they are all using the same
reference that any other AMP page would. This is unlike other "bloat" where
resources are fragmented and come from any number of sources that users
probably haven't hit before. In addition these JS resources wouldn't have been
written for a specific experience - which AMP is

~~~
TeMPOraL
The problem is, though, that the moment such wide variety of rich-media
plugins is available, AMP _stops working_ for bloat prevention - people will
bloat up their AMP pages with superfluous media and JS. Bloat is not a web
protocol problem - it's a problem of people being incentivized to add it.

------
Navarr
> this image will helpfully render with three dots in the middle to show you
> it's full of AMP goodness or something.

It will render with three dots to let the browser know it is still loading.
once it has finished, the dots disappear.

------
johnklos
Google decided to name something "AMP" to confuse people who've used AMP to
refer to Apache, MySQL and PHP for ages? Thanks, Google!

------
randomguy7788
you also have to remember these javascript files are then cached and used for
ALL amp pages across the board and only gets invalidated once a week. there is
also a stale-while-revalidate mechanism in amp if service workers are
available so users never experience the delay of fetching new javascript
binaries

------
petarb
I haven't used AMP, but my impression with all of Google CDN JavaScript files
for AMP is the end user has to download them just once per version (which I
agree will lead to a bloated first load experience) but on subsequent requests
throughout the AMP network they'll be loaded from cache. Similar to how Google
recommends you load jQuery through their CDN since millions of people already
have it in cache.

~~~
josteink
And then you have to waste your battery on running 100s of kbs of JS to show
static HTML.

No thanks.

~~~
monokh
But you'd rather go to the non AMP version which is 10x as bloated?

It seems like the vision in your head is: AMP vs. Perfectly optimised site. In
reality it's publishers who have built their main site over several years with
massive bloat and are unable for whatever reason to optimise.

~~~
swiley
What google could do instead, if they really cared, is incentivise simple
javascriptless static HTML. They won't do this though, because it makes
tracking for ads harder.

~~~
ucaetano
This seems to be the main recurring argument against AMP.

It isn't a comparison between AMP and the current web, it's a comparison
between AMP and this utopian case where the entire web is simple
javascriptless static HTML.

It's like the ascii ribbon against HTML email...

~~~
swiley
The diffence is that google has the power to improve the web and instead they
warp it for their own profit while saying they're improving it.

No one doing the ASCII ribbon thing could change what the majority of mail
users saw when they opened their mail clients.

~~~
ucaetano
The problem is that what you call "improving the web" isn't necessarily what
other users would call "improving the web".

What do you mean by improving the web?

------
gregable
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/nmof...](https://chrome.google.com/webstore/detail/amp-
validator/nmoffdblmcmgeicmolmhobpoocbbmknc?hl=en)). 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.

~~~
technion
Hi Greg,

Thanks for your response here. I think we'll just have to agree to disagree on
a number of points, but there's a few I would like to comment on:

    
    
        If the page is loaded from the AMP cache, which is probably the common case, the file has a 1 year expiration.
    

As per the screenshot, Google Pagespeed appears to disagree. Looking at the
headers via curl, I see "expires" with the current date and time (ie, it's
already expired), a max-age tag of 50 minutes. I'm not seeing one year
anywhere.

If the 30 day stale-while-revalidate really invalidates those two headers, and
I'm not knee-deep in browser support enough to really know, can someone at
Pagespeed please consider this a bug?

The issue has come up a number of times on various forums over the years in
relation to the vanilla analytics.js, and the answer that's usually accepted
is "just self host the Javascript". I'm calling it now - people will start
doing this with AMP scripts if Pagespeed doesn't change the warning,
regardless of the consequences.

    
    
         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.
    

Thanks for explaining that. It makes sense in a way I don't see another way of
doing it - but the AMP website[0] suggests this should "just work". If it in
fact only works "in certain CORS environments", what I'm hearing is that most
people testing these AMP sites just have those environments and assume
everyone else does. Which may be concerning from a security point of view.

[0]
[https://www.ampproject.org/docs/tutorials/create/preview_and...](https://www.ampproject.org/docs/tutorials/create/preview_and_validate)

~~~
gregable
> Looking at the headers via curl, I see "expires" with the current date and
> time (ie, it's already expired), a max-age tag of 50 minutes. I'm not seeing
> one year anywhere.

Take a look at the version of the doc which is served from the AMP cache:
[https://cdn.ampproject.org/c/s/lolware.net/2017/07/04/amp-
bl...](https://cdn.ampproject.org/c/s/lolware.net/2017/07/04/amp-bloat.html)

I like to think of PageSpeed Insights like the output of a good linter. No
linter is or can be perfect. The issues reported are good things to consider
and are correct for the majority of times that they trigger, but not in all
cases. This is one of those cases.

> CORS

The best fix here might be a more useful response in the dev console. Plenty
of sites, especially on dev servers, don't have any CORS headers at all, so
this does work in those cases. I'd still recommend one of the other validation
methods which work fine with any CORS setup.

------
the8472
The site uses AMP. My block AMP since it's a cross-domain request.

After a while some inline script must be running into a timeout because the
content suddenly shows up.

Completely disabling javascript makes the site display faster.

------
wcr3
less whining, more gifs of talented cats.

------
verytrivial
If there was an option to disable AMP in Chrome, I'd flip it to off
immediately. The longer this option is MIA, the more likely Firebox will
become my default browser (again!)

