The bloat of AMP
lolware.net
lolware.net
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...
[2] https://mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui
They can. Addy Osmani, Paul Irish, the PWA people, etc. They just don't seem to employ them to actually make user-facing products.
it's fine if the high-level public-speaking folks aren't doing this, but the problem is that no one seems to be doing it.
anyone can open up the DevTools network panel during a Gmail load, then look at the timings, payloads and generated DOM to see that it's almost entirely absolute shit by Google's own standards, even in Chrome on a fast desktop; they still use MochiKit ffs. there are at least several hundred engineers here on HN that can rewrite the Gmail UI to be "blazing fast" without gutting features and would still work great even on old phones still running Android 4.4.4 (with latest Chrome).
obviously Google knows all of this, they just don't care because there's no measurable ROI in a faster free Gmail compared to getting people to host their juicy AMP content on Google's servers. "It's what the users want" is a half-truth optimized for maximum PR value; a bit like "Don't be evil".
Eg leaving at least some of their own static site-furniture graphics not fully minimised and not cacheable? Likewise the CSS. I keep removing Google stuff from my properties because it outweighs my stuff by typically 10:1, again entirely unnecessarily AFAIK!
That being said, there is also a toxic stance from many Google engineers (and management) that JS is a "lesser" language, and that feeling often translates to the devs that work in it.
And exactly what language do these fine folks do their frontend development in, Go, C++?
Google sure spends a lot of resources on this lesser language for how few engineers want to work with it.
For a very long time, GWT (Java compiled to JS) was the preferred approach. Then development moved to the Closure compiler (JS following very Java-like patterns), and only very recently is ES6 style code taking off.
Much of the code you see still carries the legacy of GWT/Closure (and there is so much there that porting would be an insane task). It's a slow process. But, for example, YouTube is switching over to Polymer (https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtu...).
> Google sure spends a lot of resources on this lesser language for how few engineers want to work with it.
Google is a massive company, with many different (often conflicting) initiatives. Chrome spends a lot of effort on JavaScript; but Chrome engineers are (for the most part) not the ones that are writing Google's frontend code.
fine, but this is entirely irrelevant. the problem is that no one was optimizing for the deliverable (HTML, JS, CSS). the GWT folks could have easily written an excellent compiler so it didnt spew a bunch of unoptimized and bloated trash.
> YouTube is switching over to Polymer
which requires a massive slow polyfill in all but latest Chrome and results in a shit experience for all others (if i recall a related thread correctly [1]).
[1] https://www.reddit.com/r/javascript/comments/68vehl/youtubes...
Compilers can only optimize so much. GWT/Closure do a very good job of it, too. https://www.peterbe.com/plog/advanced-closure-compiler-vs-ug...
Much of the "slow trash" is already optimized to death - it just dies under the weight of insane complexity (e.g. features), browser support, and overly-generic (IMO) support libraries
> which requires a massive slow polyfill in all but latest Chrome and results in a shit experience for all others (if i recall a related thread correctly).
Tangential: I'm not sure which version of Polymer they're using - but 1.0+ removes the need for most of the polyfilling.
Closure certainly does; I use it every day. If Gmail is an example of how GWT optimizes things, then I'm afraid you're factually wrong.
> Tangential: I'm not sure which version of Polymer they're using - but 1.0+ removes the need for most of the polyfilling.
that thread is just 2 months old (i linked to it above)
Gmail in particular is still written using GWT, AFAIK, hence the strange HTML, etc. Its current frontend is probably an unsexy maintenance project, with little or no new development; most new features and dev efforts are likely in the "inbox" project, etc.
Indeed; Arv is a TC39 member.
> Gmail in particular is still written using GWT, AFAIK, hence the strange HTML, etc. Its current frontend is probably an unsexy maintenance project, with little or no new development; most new features and dev efforts are likely in the "inbox" project, etc.
IIRC, Inbox is also GWT, so that they could cross-compile for the native platforms (https://gmail.googleblog.com/2014/11/going-under-hood-of-inb...)
Open, not locked in, anyone can parse and cache it and it has to be publicly available (versus Apple News and Facebook Instant Articles that are pushed to those services), ridiculously straightforward and obvious. Oh, and there is no boosted rank.
So aside from the entirety of your statement, you're entirely correct.
People can have rational discussions about whether AMP is worthwhile or not (for instance, Google hosting the canonical script seems dubious) -- or whether some other subset of HTML would be ideal given the endless bloat that allows publishers to abuse fly-by users. However the rhetoric on here regarding AMP is so over the top of flag waving nonsense that it simply doesn't fit on a site where presumably we're a little more enlightened.
It also does lock-in the users into Google's experience rather than actually visiting the site, which is a big issue, including problems like further centralizing traffic and data to a single company.
Google could easily penalize search results based on speed with a strict cutoff and the entire web would become faster within weeks. Also the largest ad server on the web is Google's own doubleclick which is one of the slowest. There are many better ways to improve performance and UX without AMP.
Apple and Facebook, two of the largest content (re)publishers, have their own competing formats, and Bing currently spiders and parses AMP content as well. But thinking more holistically, many others simply pushed their content into apps, abandoning the web wholesale. Because while we can talk about how "well functioning" the web is, a virtually universal observation is that native apps that just wrap a web browser are sloggy garbage, and a big reason is that the HTML stack has grown so enormously flexible it becomes its own enemy.
We don't need a new version from Google that so far only helps with google rankings
I'm a charitable sort of person, so when someone like Google comes out with something I assess why they did it without presuming the worst. In this case we see silos appearing from Apple and Facebook, not to mention the appification of content, so Google looks for a way to keep the web compelling. And it is. When I see an AMP page there are a number of user-centric benefits that make it a draw as a link, not just speed but also best behaviors.
I mean, many of the complaints on here about AMP seem just surreal. For instance if you open the carousel (an option for trending topics like Trump) and swipe, it brings you to the next story in the carousel. This outrages some that you aren't locked in the gutter of a given site, which is just bizarre and anti-user.
Solving different problems on THEIR platforms.
AMP is just imposing a non-solution to a non-problem on web users.
Maybe you're just not the target user for this, or even for the Internet. And to be honest, pretty much nobody reading HackerNews is the target user for this.
Because it is GOOD for Google.
Also Google owns Doubleclick which is the biggest and slowest ad server on the planet.
Yes, it's not a problem: it's a symptom.
Bloated pages is the actual problem - for which there is an existing well known solution: reduce the crap on your pages.
No new single company standard, no furthering Google's market capture, and no hiding links, is needed to achieve that.
>Why would Google be implementing a technology that is BAD for their users?
Gee, I wonder, why would ever a company do that. Except, for profit, and market capture, and reducing competition, and all that...
The greatest lie in this discussion is the farcical notion that it's "AMP vs the Full Web", as if those are the only options. It's facile sophistry, but if it's anti-AMP it's all good here.
And if it's pro-AMP then it's good for you.
Really, AMP is a step back and something that solves entirely the wrong problem, and coincidentally continues the trend of Google pulling ever more content into its own eco-system to get to the point where you hopefully will not leave Google any more during the course of a browsing session.
If you feel that's good then I really don't know what arguments would make you see that this is the opposite of where we should be headed, all this vertical integration on the web serves nobody except for the few largest players. If the frog doesn't jump out of the pot while it still can then that's a point against the frog.
As a user, I like AMP. I don't work for Google and have zero investment in whether AMP succeeds or fails. But I'm capable of rationally discussing it without ridiculous FUD or pejorative noise, which so many of you aren't.
If you feel that's good then I really don't know what arguments would make you see
Of course. Allude to the greater knowledge that the ignorant fool just doesn't get. 2 for 2 now.
Well, since you are commenting across many threads in the same vein I don't see what gives you the moral high ground on this.
You as a user like AMP, but what's good for you as a user may very well be detrimental to the web and your personal temporary inconvenience need not have taken a backseat to 'the greater good' if Google had simply increased the penalty for web bloat.
That's what I'm getting at when I say that AMP is solving the wrong problem, or if it is solving the right problem that it is solving it in the wrong way.
This is just Google replacing one kind of bloat with another and we need neither. It is also a fantastic example of how a near monopoly position can be abused to extend your grip on other markets.
Whether you work for Google or not doesn't interest me one bit, what I wonder about is if you do not remember the past where we had all these systems that wouldn't talk to each other and where a few very large players dictated what the rest of us should do.
Google is outright coercing content owners to support AMP 'or else' and that's just not the web that I want to see. Giving Google a free pass here means that other players will take it as a sign that the time is ripe for the next land-grab and then we will all - including you - suffer.
My web properties will never support AMP, they're not bloated to begin with and whatever penalties Google assigns to them are proof positive that this never was about bloat.
What are you talking about? No they haven't, all major publishers continue to develop and grow their websites with some reaching into other social platforms to distribute further. Nobody has moved to an app, if anything apps have decreased in importance across the mobile universe. And if you're trying to talk about complex webapps then they were never a target for AMP anyway.
If all you really care about is user benefits, then as I described Google already had plenty of options that would be faster and easier without forking the web.
Virtually every major publisher has an app that they try to herd users into. As do many if not most social news sites. Was your question satirical, or have you just been asleep for a decade?
Given the nonsensical beginning to your comment, the rest just seems like farce.
Another big anti-AMP person is John Gruber and your comment reminded me of him -- He'll effortlessly go from advocating why iOS apps aren't anti-web, because they're still hand-wavy using web services or something, and then go on a diatribe about AMP. It's quite a delightful bit of mental flexibility.
And if you can't even finish a comment that replies to exactly what you wrote then what are you doing talking about the "level of discourse" on HN?
what are you even doing talking about the "level of discourse" on HN?
A recurring set of alternative facts rise to the top of every discussion on AMP, and my post that questioned it sits at -5. It seems laughable to now demand that I rise above -- I just find it funny.
No major publisher wants to be an app. It's reasonable to have one available for the few users who want it but that's it. Apps don't have enough usage, have lower ad rates and take far more work to maintain for very few, if any, advantages.
The apps hype cycle has played out, most users spend 80%+ time on just 5 major apps, which are email, messaging and social platforms which link to content using in-app browsers, so if anything the websites are even more important than before. And any complex service like Yelp or ecommerce was never a use-case for AMP pages anyway so that doesn't apply here.
Every action says that this is a very wrong assumption. In an era of OS-provided ad and tracking blockers, the desire to appify is greater than ever. Now we have Android Instant Apps and the almost certain appearance of the iOS alternative.
and social platforms which link to content using in-app browsers
Facebook once opened links in an external browser. Then they actually wrapped Webkit and started coddling it in a built-in browser. And now they're heavily favoring content that is pushed as Instant Article content. There are only so many times that a user can be attacked from malicious websites before the people who send you there start to get wise.
IA is Facebook's attempt at keeping people on their own platform, similar to AMP's primary focus, and it also does not have as much uptake as it might seem. Other than that, a browser is a browser and opening a publications website is the vast majority of traffic, and consequently where the vast majority of effort is dedicated.
They inject a carousel, push the organics down. Then you have to publish AMP to make it into the carousel.
At which point Google takes over your page. Adding a big amp banner with a [x] button that doesn't do what users expect. Inserting a pagination widget that scrolls to competing content, breaking the back button, etc. Is it a coincidence that all of that drives more pageviews of Google's site? Is it really your page if you don't control it?
Why do we always have to talk about the carousel? It is only relevant for news/trending topics. For that the whole "organics" are upended regardless.
Is it a coincidence that all of that drives more pageviews of Google's site?
I really, really don't think Google cares about "pageviews". But yes, it may make users think "these results are quick and convenient, so maybe I won't use Facebook as much for trending topics".
If you followed what they did over time with Wikipedia content and links, for example, you might feel differently. Or Froogle, or KG, Google Flights, or this recent change: https://mobile.twitter.com/jeremys/status/876978936177082368... , etc.
The investor pressure on Google to sustain year over year click growth, that exceeds overall web growth...is tremendous.
Driving more pageviews is one of a very few levers they have to do that, since they have exhausted many others. Once you push all organics off the fold, there's not much else you can do.
Edit: We talk about the carousel, because it perhaps best telegraphs the true intent of AMP. Everyone told me to shut up about Froogle too, because it was free for advertisers.
Search has evolved past a list of links. Every vendor in the space is doing exactly the same thing -- becoming a knowledge engine versus a keyword corpus. Yes, Google wants to create a useful product. Nothing particularly nefarious about that.
Driving more pageviews is one of a very few levers they have to do that, since they have exhausted many others.
When has Google published pageviews? Google publishes revenue and income, and userbases for a few properties and products. They don't publish or gloat about pageviews, and it is entirely irrelevant if they serve you a page from a cache or not. But yes, they probably worry that as the web gets more user hostile, users might choose silos like Facebook Instant Article, where Facebook ads might be more likely, but in that case we're talking about user likes and dislikes which is tough to argue against.
We talk about the carousel, because it perhaps best telegraphs the true intent of AMP
Is this not FUD? Reading the tea leaves and discerning the future. Personally I find Android Instant Apps a dramatically bigger threat to the vague idea of the web.
Didn't say they did. They have, though, clearly done things to keep people on their properties vs straying off to the organics. Which is the same thing as pageviews.
Why else, for example, would hitting the back button 2 stories deep into a carousel AMP article not go back one article...but go all the way back to Google?
They don't publish their CTR for search pages either. You think that means they don't track goals for it internally?
Edit: Regarding this...
"Is this not FUD? Reading the tea leaves and discerning the future. Personally I find Android Instant Apps a dramatically bigger threat to the vague idea of the web."
Phrased as if I said AMP was their sole strategy. Of course they have multiple ideas to placate the investors that are used to double digit percentage YOY click growth. One does tend to focus on search since that's where the vast majority of their revenue is.
As for tea leaves, sustaining the same growth of stock price almost requires anti consumer and anti partner behavior.
Given that it doesn't do this, at all, I'm not sure how to respond. Yes, if you open a story in the carousel and then swipe to the next story via the machinations of the carousel, then clicking back goes back to "google". But if you follow "organic" links it goes to a rote web experience.
Phrased as if I said AMP was their sole strategy
No, it's phrased as if you said exactly what you said, and needs no strawman. Whether you hit a Google cache or a host site means exactly squat. Google's core intention, it seems, is simply to try to provide a good experience for the user which is indeed a long term income strategy.
It does though. On a mobile, go to google and search "Trump ". Click a carousel article. You're now on somebody's "AMP Cached Page", right? Let's say it's WaPo. Now right swipe, and you'll go to a competitor's site...say Fox News. Now click back. You'll go back to Google instead of WaPo. And, I did specifically say this was with a "Carousel AMP Article". You're not really being fair by saying "doesn't do this". It absolutely does.
The point though. It isn't that this one choice to hijack the back button is the whole strategy.
It's indicative of a larger strategy to use UI patterns that keep people on Google properties and off of other people's. Which is kind of an odd way for a search engine to work.
It's one of many. Here's a new one from today: https://mobile.twitter.com/jeremys/status/876978936177082368...
It's almost as if...well, "The goals of the advertising business model do not always correspond to providing quality search to users".
But it doesn't. You said two levels deep, but what you just described isn't at all. AMP is the container with the list of articles, and back logically and rightfully exits the container. If you clicked a link in one of those stories, it uses entirely normal web behavior. But yes, swiping, a function added by amp, in a container provided by amp, using the list provided by amp, is a lateral move not a depth move.
It isn't that this one choice to hijack the back button
The carousel is an entirely unique construction to provide news, exactly like a hundred other options that use similar paradigms. This, and the "hijack the back button" thing invariably gets dragged into every AMP discussion, as if Google trying to provide a news service is undermining some random blog link.
You get that the carousel existed before AMP, and didn't do any of this, right? No other page cache takes over the page like this. Digg died an early death, in part, by trying to do something similar. Taking over other people's pages...in their case an iframe.
What about the [x] button on the AMP banner being a back button to Google? Is that not odd? Don't most users expect an [x] on a banner to kill the banner and leave you on the page? Like the EU cookie warnings?
I'm personally on the fence regarding the whole situation. On one hand, I like less bloat, on the other I don't want a 3rd party involved more than is required in delivering a news article to me.
So Google is guilty of making things that users want?
"Google see this as a way keeping users within the Google system as much as possible while they browse."
Well, isn't giving users what they want a way to keep them inside your system?
I don't see the point in your comment, are you saying that Google should not be optimizing for what users want?
Well, I'm a user and I don't want this.
I want Google to not invent a new format for web pages, and instead help make the actual web faster.
You (and myself, and anyone reading HN) are not the target user for this, nor are you representative of the typical internet user.
Remember, India has more internet users than the US has people.
And you can just not click on AMP sites if you don't want them.
For the downvoters: https://danluu.com/web-bloat/
Very low-end devices still have an outrageous amount of memory and storage compared to the scopes we're talking about. In the actual anecdotes of people in India expressing their good user experience with AMP, actual results seem to differ.
But as a North American with a GS8 and a very fast LTE connection, I still love getting AMP results. Just confining to best practices is alone worth it.
Reducing the overall page size of a given page doesn't help
Optimizing rendering for content first and images loaded as required doesn't help
Serving pages from a super fast global CDN doesn't help
And prefetching content behind the scenes also doesn't help
I think you should take these to Google because it seems like they've totally goofed this AMP thing!
And yes, amp is a horrible idea. Block ad networks instead.
No, those are pushed out of memory.
"And yes, amp is a horrible idea. Block ad networks instead."
Well, just don't access any ad-funded content. You can't have the cake and eat it too.
Yes, but the typical internet user has never heard of AMP and wants it even less...
>Remember, India has more internet users than the US has people.
Which can always use simple lightweight html pages instead of AMP with its JS cruft?
But they might have seen the icon, and realized it means "it loads fast!", and they want it.
Users want faster pages, we can agree on that, correct?
They don't know what AMP is, and don't care about it.
"Which can always use simple lightweight html pages instead of AMP with its JS cruft?"
You can, but no publishers seem to want to do so. But you can. AMP is optional.
Imagine your country's water sources are filthy and crappy. Your tap water literally stinks - all of that because of unrestricted commercial development. Now imagine that to solve this problem, your government created a certificate mark (Aqua Model Premium, complete with a cool icon), which can be issued to bottle water companies who meet a set of water quality criteria.
People want clean drinking water, they might have seen the AMP icon, so they'll go and buy the water bottles from government-certified companies, right?
(Oh, and let's not forget the criteria are written in such way that the bottle companies can literally shit in the bottle, as long as they use government-certified shit dispensers for that.)
Or how about the government starts issuing penalties to water delivery companies and to those who pollute rivers, until the tap water again meets the AMP criteria?
It's not a perfect analogy (Google is not a government, but it kind of owns most of the web as we know it), but it's more-less how I see this situation. Google already penalizes some bloat; they could push this much further (especially for mobile searches) instead of creating a new pseudo-standard.
The point being, as a solution for bloat, AMP is at best a workaround. But as this article proves, it's not even an effective workaround - AMP pages are free to include all the usual resource-heavy crap, just through a new set of "AMP-optimized" JS libraries.
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.
Caching is not an excuse for giant JS files, they still need to be executed by my browser.
> And the videos almost always going to play faster and more smoothly from google CDN versus some homebrew solution.
That is indeed usually true.
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
RE that tweet, I assume the values there are in milliseconds. I hate it when people don't label their axes.
Speaking of this, why do all of those annoying autoplaying videos on every major news site always take ages to load? Every YouTube video starts playing instantly, but when I click a link to any news site I literally have to sit there waiting over 5 seconds for the video to start playing so that I can pause it again (because otherwise it will start playing after I've already started to scroll down), even though I have a reasonably fast connection.
Also, this greatly depends on the audience size: 30 users / hour might not need a CDN at all.
And even then, how would you create a homebrew CDN?
Sure, you could buy bandwidth, storage and processing capacity in multiple DC providers around the world and build, deploy and maintain your own solutions, at which point you're essentially becoming a small CDN with significantly higher costs as you don't have the efficiencies of scale and 100's (or 1000's) of multiple customers.
But isn't it true that as long as you can send >1s of video in 1s, it doesn't matter? I.e. latency doesn't matter much in video streaming, and bandwidth doesn't need a CDN for the 30 users / hour case?
Also, latency probably doesn't matter for 99% of sites, which are already so bloated with JavaScript and other pointless content that processing time dwarfs the connection delay.
> Also, latency probably doesn't matter for 99% of sites, which are already so bloated with JavaScript and other pointless content that processing time dwarfs the connection delay.
Indeed, but then CDNs also dramatically reduce the cost. It is far cheaper to serve an user in Jakarta from a server in Jakarta than from London. And even cheaper if the server is sitting in the ISP's core network in Jakarta.
The Internet as we know today couldn't exist without CDNs.
So that I get way worse performance on trying to stream your videos than with YouTube's CDN?
Seriously, anything besides YouTube (from Vimeo to Comedy Central, CNN, any site that self-hosts) is exceptionally sluggish...
if we had an uptick in traffic, we would use a CDN to host the vids as long as the CDN didnt require that we swallow a 1MB js player for the pleasure of doing so.
The way most websites fuck that experience up with superfluous JS and media content makes this point moot, IMO. Being able to deliver JS 200ms faster doesn't help when you're serving megabytes of it.
It's about the CDN being optimized for my (or any other user's) region...
Note: I’ve tested with an ad/tracking blocker.
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... I'm sure that in itself will hurt rankings.
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?
It is 100% benign.
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
It will render with three dots to let the browser know it is still loading. once it has finished, the dots disappear.
No thanks.
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.
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...
No one doing the ASCII ribbon thing could change what the majority of mail users saw when they opened their mail clients.
What do you mean by improving the web?
> 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...). 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.
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.
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.
[0] https://www.ampproject.org/docs/tutorials/create/preview_and...
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...
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.
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.