The Two Faces of AMP(timkadlec.com)
timkadlec.com
The Two Faces of AMP
https://timkadlec.com/remembers/2018-02-14-the-two-faces-of-amp/
8 comments
> If you squinted your eyes and tilted your head just right you could see a "good for the web" angle with faster mobile pages.
AMP is much slower if you don't allow your browser to load JavaScript from 3rd party sources. It literally takes 8 seconds for my browser to display AMP pages. (Try it if you don't believe me.)
AMP is also slower than optimizing it yourself.
AMP is much slower if you don't allow your browser to load JavaScript from 3rd party sources. It literally takes 8 seconds for my browser to display AMP pages. (Try it if you don't believe me.)
AMP is also slower than optimizing it yourself.
I dream of 8 seconds :^)
Really, I regularly get broken links on an android phone from Google News. It's hilarious to watch it try and resolve, if the article is more than 15min old. A direct link to the article just works. New links work. I'm guessing it's something similar to what you describe...
Really, I regularly get broken links on an android phone from Google News. It's hilarious to watch it try and resolve, if the article is more than 15min old. A direct link to the article just works. New links work. I'm guessing it's something similar to what you describe...
I also experienced White Screens of AMP Death where only the AMP header was visible, not the page content. For what it's worth the white screen loaded pretty fast :)
> AMP is obviously conceived, funded, and implemented by Google and its employees. If you squinted your eyes and tilted your head just right you could see a "good for the web" angle with faster mobile pages.
An idea predicated on a lie can only go downhill. Engineers need to, as best they can, convince product owners that AMP in any form is a poison apple.
An idea predicated on a lie can only go downhill. Engineers need to, as best they can, convince product owners that AMP in any form is a poison apple.
I wonder if Google's AMP team is truly drowning in the Kool aid or if they actually know what's going on, but keep quiet for job security reasons.
You should read back on some of the older threads here on HN where AMP is heralded as the best thing Google has done in a long time.
I have, but the comments I read were from the AMP lead, who I assume has fully drunk the Kool aid since they probably signed up for that job. I'm more curious about his/her team members. Google hires smart people. I assume they are free thinkers.
Edit: I'm pretty vocal in those old threads calling out AMP as a walled garden play, FWIW. I remember AOL's early days.
Edit: I'm pretty vocal in those old threads calling out AMP as a walled garden play, FWIW. I remember AOL's early days.
Smart people with mortgages at valley rates seem to get a lot less smart when they are looking at their own contributions.
Doesn't the valley work much like every other tech hub in the world, i.e. if you lose your job in the morning you can start a new job somewhere else sometime after lunch? Especially with a place like Google on your resumé.
That may be true, but the vast majority of people don't keep a stockpile of "fuck you" money in case of such situations. The path of least resistance is to lick boots and spend spend spend, not to be "insubordinate" or forego bad deals like rent-to-own from banks.
Upton Sinclair - "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"
I like Google, but they are really losing their way with things like AMP and Material Design (accessibility). People need to speak up or we won't have a truly open WWW much longer.
> Engineers need to, as best they can, convince product owners that AMP in any form is a poison apple.
Sorry (as in: I apologize).
As an engineer, I know AMP shows slow AMP sites before fast HTML ones and this disgusts me.
As a product owner, I need to be in that carousel. It's sales and pays my rent. So product owner me even made engineer me write an AMP library for node. It doesn't feel great.
Sorry (as in: I apologize).
As an engineer, I know AMP shows slow AMP sites before fast HTML ones and this disgusts me.
As a product owner, I need to be in that carousel. It's sales and pays my rent. So product owner me even made engineer me write an AMP library for node. It doesn't feel great.
Google prefetches AMP Content. It can’t do that for HTML pages, so how is it possible that Google is showing slow amp pages before fast html? Is there an example of this that you can point to?
HTML pages do not appear in the carousel or in the new desktop stories area at all. These are both placed before the old style results.
> An idea predicated on a lie can only go downhill. Engineers need to, as best they can, convince product owners that AMP in any form is a poison apple.
Is that the same way as engineers convinced product owners to not turn pages into autoplaying video, malware javascript, popup ladden piles of garbage? Or is that ok for those engineers?
Is that the same way as engineers convinced product owners to not turn pages into autoplaying video, malware javascript, popup ladden piles of garbage? Or is that ok for those engineers?
My experience is limited, but I doubt engineers ever speak up about those things. I've yet to witness it. And I'm no better; the best that I usually do is audibly groan at those things or share opinion pieces about them in Slack.
Actually, there was one time I witnessed an engineer speak up about why a particular popular idea was a bad thing long-term. He left immediately after management squinted at him and tilted their heads like confused dogs.
That doesn't mean that it's not worth the effort. I would rather try something than to never have. All I can say now is that I won't be working on any future AMP development. The people who employ me may have to have to decide if it's worth firing me over an insidious Google feature. I hold no malice to my employer, but there comes a point where I cannot take money to do damage to the technology that enabled my career.
TLDR: Your point is well taken, but my point still stands that there should be some way for stakeholders to know that what they want may have long-term negative consequences.
Actually, there was one time I witnessed an engineer speak up about why a particular popular idea was a bad thing long-term. He left immediately after management squinted at him and tilted their heads like confused dogs.
That doesn't mean that it's not worth the effort. I would rather try something than to never have. All I can say now is that I won't be working on any future AMP development. The people who employ me may have to have to decide if it's worth firing me over an insidious Google feature. I hold no malice to my employer, but there comes a point where I cannot take money to do damage to the technology that enabled my career.
TLDR: Your point is well taken, but my point still stands that there should be some way for stakeholders to know that what they want may have long-term negative consequences.
> Engineers need to, as best they can, convince product owners that AMP in any form is a poison apple.
Product owners will convince them right back with large 3 figure salaries, bonuses and RSUs. It won't be that hard either.
Product owners will convince them right back with large 3 figure salaries, bonuses and RSUs. It won't be that hard either.
Oh I know full well what people's motivations are. Said motivations can contradict a principle without invalidating it. If people are fine playing into the erosion of the very technology that allows them to make money, that's on them. From now on, it won't be on me.
re: "abuse of the concept of open source to recruit volunteer technical labor"
I'm pretty sure any programmers working on AMP at this point have heard the criticism (since it's repeated every time AMP comes up) and know what they're doing. They just disagree.
I'm pretty sure any programmers working on AMP at this point have heard the criticism (since it's repeated every time AMP comes up) and know what they're doing. They just disagree.
I would wager most programmers implementing AMP don’t feel they have a choice. Either they need to do it for SEO purposes or they need to do it because project managers say so it for SEO purposes. That’s kind of the whole reason AMP is bad.
The grandparent was criticizing people who contribute to the AMP open source project.
Even if it's getting a bug fixed to make your own site work, would it be better for it to be closed source?
Even if it's getting a bug fixed to make your own site work, would it be better for it to be closed source?
I understand people can contribute with their eyes open; that's fine. People volunteer bug reports (for e.g.) to paid software all the time, open source or not. My criticism was actually of Google soliciting those contributions in the first place.
"Open source" is just a useful fiction in this case: what would a fork of AMP even do? It does however make the project corporately palatable to others that might want to implement it (i.e. Microsoft/Bing), plus it attracts unpaid contributions to fix the work of Google's highly paid engineers ("Building the future web, together."). The former might be necessary but the latter is extremely problematic IMO.
Google could have set up AMP as an independent W3C group (for e.g.) at arms length from its competitive interests, but it didn't, and recent AMP product announcements show us why.
"Open source" is just a useful fiction in this case: what would a fork of AMP even do? It does however make the project corporately palatable to others that might want to implement it (i.e. Microsoft/Bing), plus it attracts unpaid contributions to fix the work of Google's highly paid engineers ("Building the future web, together."). The former might be necessary but the latter is extremely problematic IMO.
Google could have set up AMP as an independent W3C group (for e.g.) at arms length from its competitive interests, but it didn't, and recent AMP product announcements show us why.
I think you have a rather odd idea of what open source means.
Community ownership and independent standards committees are not a requirement of open source. As long as forking is allowed, as a project owner, you're within your rights to veto any change. Consider Python ("Benevolent Dictator for Life") and Linux. Or for a smaller project, consider Elm.
It's not unusual for employees and volunteers to work together. Furthermore, the "volunteers" are often employees of a different company.
Community ownership and independent standards committees are not a requirement of open source. As long as forking is allowed, as a project owner, you're within your rights to veto any change. Consider Python ("Benevolent Dictator for Life") and Linux. Or for a smaller project, consider Elm.
It's not unusual for employees and volunteers to work together. Furthermore, the "volunteers" are often employees of a different company.
> As long as forking is allowed
But as per GP's point, what would forking the project do? Who other than Google is positioned to host an AMP fork, and why would they choose to do so?
The centralized nature of the project makes it hard to understand what the point of it being open-source is, apart from being good PR and getting free work done on it.
But as per GP's point, what would forking the project do? Who other than Google is positioned to host an AMP fork, and why would they choose to do so?
The centralized nature of the project makes it hard to understand what the point of it being open-source is, apart from being good PR and getting free work done on it.
It would do whatever you modified it to do. You don't have to run it as-is or have Google host the pages.
I agree that you'd lose some benefits, but it's still an interesting web framework.
I agree that you'd lose some benefits, but it's still an interesting web framework.
why do you think they are not the same?
only contributed because my employer was lockedin into using AMP for the perverse SEO incentive.
only contributed because my employer was lockedin into using AMP for the perverse SEO incentive.
If only I had a nickel for every online commenter who swore up and down that no one else implements or supports AMP, and then uses that to justify claiming Google is trying to fork the web...all major platforms pursuing end-arounds mobile ad garbage, _except_ Facebook and Apple, use and contribute to AMP.
Anyways, I'm just happy to finally have usable web results on mobile.
Anyways, I'm just happy to finally have usable web results on mobile.
Who conceived of AMP Stories? Who conceived of AMP in Email? What do they even have to do with "Accelerated Mobile Pages"?
My irritation with AMP is also driven by the fact it's not usable for me. Reader mode is often broken in iOS which is a particularly egregious regression. URLs are obviously broken. And sometimes sites can't even get text-on-a-page right with their AMP versions: https://twitter.com/lukestevens/status/963910460796936192
My irritation with AMP is also driven by the fact it's not usable for me. Reader mode is often broken in iOS which is a particularly egregious regression. URLs are obviously broken. And sometimes sites can't even get text-on-a-page right with their AMP versions: https://twitter.com/lukestevens/status/963910460796936192
AMP makes it faster (maybe) but the experience is worse. I copy URLs a lot to share, and a fucking AMP link doesn't even navigate and requires a different means of finding the actual URL... garbage.
People's participation in AMP isn't voluntary. They have to implement and support AMP, or they get penalized by Google Search.
[deleted]
Bing, Cloudfare.
They sure exist! But Google's search has like 4/5 of the market.
If you optimize for the bottom line (as a business should), what will you pay most attention to?
If you optimize for the bottom line (as a business should), what will you pay most attention to?
I think his point was that Bing implemented AMP voluntarily, without being pressured as you suggest publishers were: https://blogs.bing.com/search/September-2016/bing-app-joins-...
Bing's primary pressure is a need to compete performance wise with Google. The fact that the implementation is bad doesn't mean they don't need to match on the metrics.
To play devil’s advocate: the reason Bing can implement their own AMP cache and conform to AMP pages so easily is because AMP is an open project.
Nobody said the problem was AMP's code being available. The issue is the way Google is forcing their framework's dominance using their search monopoly.
Does Bing host the pages on their own servers? Hosting your content on their servers could be a motivation for joining. If Google is going to appify your websites on their own servers, then Microsoft doesn't want to be left out. They can both put giant back buttons on your website that take you back to the search engine results instead of deeper into the website.
And Facebook only isn't participating because they are instead doing the same thing in a less-open way with Instant Articles.
> finally have usable web results on mobile.
Weird, I've been reading web results on mobile for over a decade.
Weird, I've been reading web results on mobile for over a decade.
It will never be okay to give preferred treatment to those that use your framework. This basically is telling all other framework authors, "never mind, Google has decided the one that anyone that everyone will have to use (if they want in to the SEO club)" At this point, they're no longer saying, "we've found the most pertinent search results". Instead, they're saying, "our friends provide the best stuff... don't bother looking at the others"
The basement dream of the web is dying faster and faster. At the hand of large, scared companies. It's ironic that the more powerful you get the more scared you become.
The phrase "nothing to lose" comes to mind about the fearless.
At what point do the people working in tech come to the realization that Google has become a problem that must be eliminated if the web is to continue to flourish?
[deleted]
> The letter calls on the AMP team to make two primary changes:
> Instead of granting premium placement in search results only to AMP, provide the same perks to all pages that meet an objective, neutral performance criterion such as Speed Index. Publishers can then use any technical solution of their choice.
How would you measure this in a way that couldn't be gamed?
I'm not saying AMP is the best solution, but the way AMP prevents you from doing things that hurt performance makes it much easier for you to know for sure an AMP page has certain performance properties.
> Instead of granting premium placement in search results only to AMP, provide the same perks to all pages that meet an objective, neutral performance criterion such as Speed Index. Publishers can then use any technical solution of their choice.
How would you measure this in a way that couldn't be gamed?
I'm not saying AMP is the best solution, but the way AMP prevents you from doing things that hurt performance makes it much easier for you to know for sure an AMP page has certain performance properties.
This might be a somewhat controversial (or just reviled) opinion, but: why should search engine rankings care about page performance?
As soon as Google, the thing that indexes for relevance starts caring about an orthogonal behavior like performance, my ability to trust that I'll see relevant things first is compromised. Balancing between two good criteria dilutes both, basically.
Performance impacts a page's relevance in one case: if it never renders (times out), in which case it isn't indexable anyway. Otherwise, users have "stop" and "back" buttons at their disposal if a relevant page doesn't load fast enough for them.
Performance is important, but should not be a criterion for search results. The fact that it's may be incorporated into the ranking system is at best extremely misguided and at worst baldly avaricious.
As soon as Google, the thing that indexes for relevance starts caring about an orthogonal behavior like performance, my ability to trust that I'll see relevant things first is compromised. Balancing between two good criteria dilutes both, basically.
Performance impacts a page's relevance in one case: if it never renders (times out), in which case it isn't indexable anyway. Otherwise, users have "stop" and "back" buttons at their disposal if a relevant page doesn't load fast enough for them.
Performance is important, but should not be a criterion for search results. The fact that it's may be incorporated into the ranking system is at best extremely misguided and at worst baldly avaricious.
> This might be a somewhat controversial (or just reviled) opinion, but: why should search engine rankings care about page performance?
They'll care because faster results will generally mean happier and more engaged users who'll want to use your search engine again. This applies even more for mobile users where you might be waiting 10s of seconds before anything is rendered on a slow page.
They'll care because faster results will generally mean happier and more engaged users who'll want to use your search engine again. This applies even more for mobile users where you might be waiting 10s of seconds before anything is rendered on a slow page.
That concerns me, if true. If users will blame the search engine for directing them to a page that is relevant yet slow, and the logical solution to that is that the search engine should ensure all pages are fast, doesn't that open up a bit of a can of worms about the search engine itself? I.e. if users blame the search engine for providing results for "whose religion is the best" that they disagree with, wouldn't the same logic incentivize the search engine makers to filter those results for users whose religious preference is known?
It seems like a bad tradeoff to make: marginally increase user engagement by serving faster pages at the cost of potentially compromising the primary reason (relevance) that people use your search engine? I'm sure there is data supporting that decision, but this doesn't make it sit any better with me. It's like going to the library and saying "I'd like the complete works of Shakespeare, please" and having the librarian say "well, here's our theater section, but please pay special attention to these abridged/easy-reading versions of Shakespeare, since we think they'll make for a more enjoyable experience for you. The complete works are on this floor somewhere; you can find them yourself."
I'm not saying that we'll automatically slide down that slope, just that it's there, and a bit slippery.
It seems like a bad tradeoff to make: marginally increase user engagement by serving faster pages at the cost of potentially compromising the primary reason (relevance) that people use your search engine? I'm sure there is data supporting that decision, but this doesn't make it sit any better with me. It's like going to the library and saying "I'd like the complete works of Shakespeare, please" and having the librarian say "well, here's our theater section, but please pay special attention to these abridged/easy-reading versions of Shakespeare, since we think they'll make for a more enjoyable experience for you. The complete works are on this floor somewhere; you can find them yourself."
I'm not saying that we'll automatically slide down that slope, just that it's there, and a bit slippery.
Yep, I'm not saying it's without issues but I can see why Google wants to show users fast pages. I can relate when using a mobile: it's super frustrating when you're on the move, need a quick answer, the first link takes 20 seconds to load so you go back, you try another etc.
First off, you're right: any metric can be gamed. Even so, Google is already using performance to factor into its algorithm, so some level of reasonable accuracy must have already been agreed upon.
Ensuring a certain level of performance is not a very easy problem to solve. But it's doable.
Myself and a few others sat down with the AMP team awhile back and chatted about what that would look like and there were definitely a few different layers that would be needed to get it to work.
The first is already in progress. There's a spec for something called "Feature Policy" (https://wicg.github.io/feature-policy/). Feature Policy would let you tell the browser you don't need certain features which would in turn let browsers take shortcuts (so to speak).
For example, you could declare that you will not be allowing document.write. Enough features being declared could serve as a way for Google (and others) to say "Ok, this is going to be reasonably fast."
There's more needed of course: we had discussions about a standard related to declaring a limit on asset sizes, etc. But it's a start. And while it will always be a little fuzzy, the same is true of AMP. It's completely possible to build a slow AMP page.
The best Google can do is say "if they're doing X, then the odds are good that it's performant".
Ensuring a certain level of performance is not a very easy problem to solve. But it's doable.
Myself and a few others sat down with the AMP team awhile back and chatted about what that would look like and there were definitely a few different layers that would be needed to get it to work.
The first is already in progress. There's a spec for something called "Feature Policy" (https://wicg.github.io/feature-policy/). Feature Policy would let you tell the browser you don't need certain features which would in turn let browsers take shortcuts (so to speak).
For example, you could declare that you will not be allowing document.write. Enough features being declared could serve as a way for Google (and others) to say "Ok, this is going to be reasonably fast."
There's more needed of course: we had discussions about a standard related to declaring a limit on asset sizes, etc. But it's a start. And while it will always be a little fuzzy, the same is true of AMP. It's completely possible to build a slow AMP page.
The best Google can do is say "if they're doing X, then the odds are good that it's performant".
> Ensuring a certain level of performance is not a very easy problem to solve.
What I'm getting at is maybe AMP is Google's way to make the problem easy. Sometimes when a general problem is difficult, you're better adding restrictions to make the problem tractable.
> It's completely possible to build a slow AMP page.
Can you elaborate? How easy would it be to test AMP pages for that?
What I'm getting at is maybe AMP is Google's way to make the problem easy. Sometimes when a general problem is difficult, you're better adding restrictions to make the problem tractable.
> It's completely possible to build a slow AMP page.
Can you elaborate? How easy would it be to test AMP pages for that?
> What I'm getting at is maybe AMP is Google's way to make the problem easy. Sometimes when a general problem is difficult, you're better adding restrictions to make the problem tractable.
It absolutely is! (Sorry if I made it sound like it wasn't). That's what the goal is of Feature Policy and other standards too: to add restrictions to make it easier to solve.
> Can you elaborate? How easy would it be to test AMP pages for that?
I keep meaning to make an example, but real work gets in the way. :)
Basic gist though is that AMP is, again, only a fuzzy approximation of good performance. You can still mess it up.
As for testing, the best thing to do is probably test from the origin server. That way you eliminate the Google cache layer and just focus on what the format itself actually accomplishes.
There was a post recently where a guy did exactly that, and the results were far from instant: https://ferdychristant.com/amp-the-missing-controversy-3b424...
The conclusion, for anyone who doesn't want to click through, is that the vast majority of the performance benefits don't come from AMP itself. They come from A) the Google cache layer and B) the fact that Google preloads the AMP page in the background before you click on it.
It absolutely is! (Sorry if I made it sound like it wasn't). That's what the goal is of Feature Policy and other standards too: to add restrictions to make it easier to solve.
> Can you elaborate? How easy would it be to test AMP pages for that?
I keep meaning to make an example, but real work gets in the way. :)
Basic gist though is that AMP is, again, only a fuzzy approximation of good performance. You can still mess it up.
As for testing, the best thing to do is probably test from the origin server. That way you eliminate the Google cache layer and just focus on what the format itself actually accomplishes.
There was a post recently where a guy did exactly that, and the results were far from instant: https://ferdychristant.com/amp-the-missing-controversy-3b424...
The conclusion, for anyone who doesn't want to click through, is that the vast majority of the performance benefits don't come from AMP itself. They come from A) the Google cache layer and B) the fact that Google preloads the AMP page in the background before you click on it.
Interesting, thanks for the link!
Not sure I agree with this part though:
> What we know about AMP is that the technical standard in itself enforces good performance. For example, CSS is limited to 50KB and only inline, custom JS is not allowed (other than via an iframe method), and all images are guaranteed to be lazy loading. Hence, this is why AMP pages load instantly compared to a “normal” web page. It’s enforced by the standard. Right? Wrong.
If you're including several MBs of CSS and JS in a render blocking manner and even more MBs of non-lazy loading images (which really isn't unusual) you're going to have a significantly slower page. There's a lot of hate for AMP but those restrictions make a lot of sense.
Not sure I agree with this part though:
> What we know about AMP is that the technical standard in itself enforces good performance. For example, CSS is limited to 50KB and only inline, custom JS is not allowed (other than via an iframe method), and all images are guaranteed to be lazy loading. Hence, this is why AMP pages load instantly compared to a “normal” web page. It’s enforced by the standard. Right? Wrong.
If you're including several MBs of CSS and JS in a render blocking manner and even more MBs of non-lazy loading images (which really isn't unusual) you're going to have a significantly slower page. There's a lot of hate for AMP but those restrictions make a lot of sense.
AMP implementation also sucks, why cant i use !important in css for AMP ? Also try to convert any user generated page to an AMP page and have fun with all the validation errors. AMP might be a good thing for web in general but the way it is handled poorly by google , atleast Facebok Instant Articles dont have that many restrictions
[deleted]
Google have to answer to shareholders, it's in their interest to keep users within their ecosystem.
It's just corporate astroturfing.
AMP is obviously conceived, funded, and implemented by Google and its employees. If you squinted your eyes and tilted your head just right you could see a "good for the web" angle with faster mobile pages.
But AMP for email & AMP Stories have nothing to do with making the web faster, it's just another part of Google's attempt to essentially fork the web & control the platform so they can compete with Facebook by shoehorning FB/IG/Messenger features on to the web (Instant Articles, Stories, Carousels, "interactive" email etc).
That's bad in and of itself, and for Google to present its corporate strategy as an "open source" project so it can enlist the help of volunteers and those passionate about the web is disingenuous in the extreme.
There are far more worthy projects that could use volunteer help than a $750 billion company's corporate strategy.
Further thoughts here: https://twitter.com/lukestevens/status/963905898895699968