Past all the considerations of content ownership and all, it seems to be quite the technical feat, the impact on page load is real (or maybe my testing was partial or biased).
I'd argue it is more of a social feat than a technical one. It is still HTML, after all.
The real underlying issue that AMP solves is ad bloat. Online newspapers tend to include that one more ad library that tracks a particular thing that one ad partner or one analytics team wishes to have, let alone visual bloat such as "share as", "like", "comment" and other social widgets all implemented as iframes with their own separate trackers, and the sum of it all has a large impact on both download sizes and performance, since they are seldom optimized. Oil on fire is the fact that there is generally no incentive to remove libraries that no longer have a use.
AMP forces newspapers and other content providers reliant on advertising to play nice. It gives them an incentive (through caching and better indexing) which costs them the bloat.
Big fan of what AMP is doing, but I'm a little surprised by the statement that:
> Today, multiple web metrics providers are on board, including Moat (who partner with Chartbeat), Nielsen, ComScore, Parse.ly, ClickTale, Adobe Analytics
As far as I know, our (Snowplow's) PR into AMP is the first and only (so far) from a non-GA analytics vendor:
"Such mobile performance, wow".
4 megabytes of video(Preloading two different videos. Why?), maybe 10 different domains, downloading JS before downloading images...
And this is the showcase for AMP.
It's almost as if "there is no silver bullet" for web performance, and "actual programming skill" is still a requirement.
But at this point in time, it seems that installing an ad blocker has about the same impact as "conceding to view a crippled AMP-redesign of the page that doesn't even have navigation".
Using the same tool, I can see that my website loads in 440ms in the Netherlands. The homepage is 140kb, makes 6 requests, leverages caching and http/2 thanks to nginx etc.
Which is great and everything, but for a reader in Texas, that becomes 1.2s thanks to the fact that my site is hosted in London.
As you point out, AMP pages which weigh in at 4MB can be loaded in a seemingly underwhelming time: ~800ms. However, I think the important takeaway from this is that the pages load in ~800ms in two different continents.
The articles I publish on my blog use AMP-HTML. I don't include media or ads at all, just text and fonts. These pages fully load in 200ms.
I conclude that the free CDN offered by Google is, frankly, a very attractive feature.
How do you know Cloudflare or other CDNs are participating with advertisers somehow, or responding to government tracking requests?
If the government can subpoena data from Google, are we sure they're not doing the same or more with CDNs, which don't seem as transparent as the consumer-facing companies.
Cloudfare publishes a transparency report https://www.cloudflare.com/transparency/, whether you trust it is another thing. Personally I have given up on privacy and now just hope that it can be made so that we are all equally naked.
Every page weighs 4+MB, because the page-specific content on the page weighs more than 4MB. There's almost 1MB of "CSS + JS + HTML", but about 4MB of video.
They're pre-loading videos for the same reason Facebook does: if you post an article with a video, the video instantly plays, with little to no buffering.
"This kills the 3G data plan". At least with "the optimized for mobile" version, preloading should not happen. And it definitely shouldn't happen twice for the same video.
if a publisher want to do everything right in todays internet, they need
* a responsive website
* with views for desktop, mobile and tablet
* optimized for search, social and conversion
* optional: augmented with schema.org
* an iphone app (one or more)
* an android app
* optional: tablet/ipad app
* facebook channel
* twitter channel
* youtube channel
* pinterest presence
* whatsapp presence
* snapchat presence
* one or more newsletter
* constant A/B testing
now add
* facebook instant articles
* google amp pages
did i forget something?
yes page bloat, third party crap and webperformance is a serious issue for users and publishers, but solving it with throwing another half baked technology at the publishers will not work.
I agree. This is why some pages are omitting social shares.
And my understanding is amp does not work with Javacrip. That's a problem.
Why does this sound like google+ all over again?
I agree with the first half of your comment: publishers (as well as those who might support publishers, like devs, etc.) have so much to do nowadays. And while i care less about AMP being half-baked or not...I do feel it is a step in the right direction. If this works out, I think publishers (and devs) stand to benefit. Just think: if everyone gets on the bandwagon of improving performance for the sake of a better web experience, then the conventional web platform could win supreme again!
The real omission, however, should have been #0: “high-quality content”. Sure, you see the NYT, NPR, Guardian, et al. post a lot on Twitter, Facebook, etc. but they were already some of the most popular content on the web and would have been widely shared either way.
It's possible but in the context of web design “responsive” has had a specialized meaning for many years, going back to a very influential article in 2010 which grouped older practices under that term:
Nope. Responsive as in "Resppnsive website". But instead of views I should have written "breakpoints". Said that: breakpoints get misused as device dependent views regularly, implementing complex .hidden CSS mambo jumbo. So yes, for me breakpoints are views (even if the should not be)
I am far from being an expert front end developer. I have found that a good match for my requirements and the amount of time I am willing to spend developing and maintaining my web sites is to simply use minimal Bootstrap themes and let media queries generate mobile and desktop versions of my sites.
Without too much hassle I can support all device types and as long as I am careful to use small image files and minimized JS and CSS, page load times are pretty good.
I'm fine with it long as all content/analytics don't pass through Google, but I imagine many content sites will be lazy and let Google handle everything.
In order to make my completely static non-JS site AMP compliant do I have to include the amp JS library or is Google smart enough to realize my site is plenty fast enough as-is?
Accelerated Mobile Pages are just like any other HTML page, but with a limited set of allowed technical functionality that is defined and governed by the open source AMP spec
And from the Spec:
Enable the AMP runtime to manage the loading of external resources, which may slow down the initial render or cause jank.
Allow AMP authors to include functionality above and beyond standard HTML, while maintaining the security- and performance-minded requirement that no author-written JavaScript is executed
Appears we won't have access to Canvas2D, WebGL, WebRTC, Fetch and other HTML5 Web APIs. AMP's subset of declarative elements and caching will be great for longform-y "static" content. The kind of articles I find myself reading more of on Mobile Chrome during down times in transit. Thinking of Medium confessionals and NewYorker dispatches, etc.
But how do you implement something like ChartBeat? Snapshots of dynamic chart images and data pre-rendered on the server and pushed out to the cdn? Sort of eliminates the performance benefits of geospatial caching doesn't it...
I do take heart however in Tony Haile's pull quote from the ampproject.org homepage:
The mobile open web experience is terrible and some have suggested it's too slow to compete. We can choose to see the mobile open web as a relic of its time and flee to the warm embrace of closed platforms and apps. Or we can say that the open web means something important to the world and if it’s broken it’s our job to fix it. I think we should fix it.
From the article: "...most ad servers (not just Google-owned DFP) will be able to send ads in AMP pages. Some work remains to be done on the formats that will be deemed acceptable in AMP pages." Deemed acceptable by who, and doesn't this indicate it will become another walled garden?
Not sure why you were down-voted as it is a legit question.
I'd honestly be pretty surprised if they didn't just opt to support all IAB-approved ad formats. The one format I could see being a big question mark is "native ads." Outside of their increased Gmail ad presence, Google has been curiously absent from the native advertising landscape.
Ah--love Ben's blog and podcast (listen to it several times a week during my commute).
His point is a good one. In terms of feeds of potential branding interest, beyond Youtube, Google's big (and mostly untapped) opportunity is in Gmail.
They made a stride to first assert control and doing users a favor by moving things to the Promotions tab. Now they have their ads in the email "feed" in that tab. The Inbox product, IMHO, was their attempt at redefining email into an fully algorithmically-curated feed ala FB, Twitter and Reddit.
My personal bet is that Inbox was a proof of concept and they will force Gmail to shift to that approach in the not too distant future. If users don't leave en masse, I would not be surprised at all to see Google forcing advertisers to pay to get into the inboxes of Gmail users--even users who have explicitly asked for promotional emails. That was FB's brilliant gambit (that somewhat blew up in their face). They convinced advertisers to invest in building an audience on the FB platform (so FB owned the audience), let them see revenue from it, and then switched from a "communicate all you like to everyone who Likes you for free!" model to a "pay us on an auction model if you want to reach anyone" model. Many advertisers consider it a huge bait-and-switch play, but I can't deny that it seems to have been successful. And that is why I won't be surprised to see Google follow suit there.
The web is getting bigger, there is no denying that. People developing responsive sites irresponsibly, adding large images, videos and JavaScript libraries and frameworks.
What I don't understand is why search engines don't punish those individuals with larger pages rather than move everyone to something new? Is this taking us back to the mobile site days?
I love the concept of getting core content to the user fast but what is stopping someone adding a 2MB amp-img to their page and then we are right back where we were before?
Even more centralization and single point of failure. If this continues the web as envisioned will be entirely replaced by a centralized system of walled gardens with big companies controlling access.
This is why we need IPFS sooner rather than later.
Keep in mind that the AMP caching infrastructure will also be able to serve as a tracking platform because it records every single IP address. This effectively grants Google and associates a defacto monopoly in terms of an unblockable mobile tracking platform in a world where ad-blockers are becoming ubiquitous.
I think it's a smart move on their part actually, but what I assume will eventually happen is other providers will come along and provide a similar free infrastructure but without retaining logs and then everyone will migrate to that. Google will have gotten the ball rolling, and benefited for a number of years from the data, but ultimately people on the web prefer not to be tracked.
but ultimately people on the web prefer not to be tracked.
It's curious because most people on the web pay lip service to this preference but their actions typically indicate that they don't really care all that much. The folks on Hacker News are in the minority of users whose actions indicate they truly care.
Nah, I think they don't have the time to get up to speed enough to even understand what it means to have their IP tracked, let alone understand the lengths they would have to go to avoid being tracked.
Most of my non-technical friends are super concerned, and frequently tell me how scary it is not knowing what to do or how to avoid it.
It's an active role the current ad-based industry takes to convince their users that the tracking either doesn't matter or somehow empowers the user, which are both demonstrably false.
Or it is even worse, in that not being tracked is now a negative so some of us allow ourselves to be tracked enough so that we don't fall foul of not being tracked. Kinda like jobs that look at your social media presence before hiring and consider no such presence to now be a negative.
You nailed the problem with AMP: some people, like me, like to reduce the amount of tracking and general information gathering by corporations (and governments, but that is a different discussion). I stopped using Google Analytics (which is a great free product) because I wanted to reduce the tracking of people kind enough to visit my tech web sites and blog. If I were to use AMP, then my readers would get tracked.
This is the bigger story around AMP for me at least. I wonder if this would give them the ability to provide impression-level data in Universal Analytics for display ads not run through DCM if a given placement/site uses AMP. If they log the ad loading, and can parse the metadata from it, they can in theory use that to populate impression data and view-through conversions in UA.
Talk about a brilliant strategic move if this pans out since they'll be speeding up the web, gaining a massive dataset they didn't have access to before, and building a nice moat along with it.
> The reality is that content can take several seconds to load, or, because the user abandons the slow page, never fully loads at all. Accelerated Mobile Pages are web pages designed to load instantaneously – they are a step towards a better mobile web for all.
That's kind of dishonest of Google. The "content" doesn't take longer to load. The website does, but its because of Ads, pointless JS scripts that are spying on the user and a whole host of things that are _NOT_CONTENT_.
In any case, even if creating a new standard, or reduced-HTML, or w/e made sense, I'd be less skeptical if it wasn't controlled by an advertising company.
56 comments
[ 3.4 ms ] story [ 93.2 ms ] threadThe real underlying issue that AMP solves is ad bloat. Online newspapers tend to include that one more ad library that tracks a particular thing that one ad partner or one analytics team wishes to have, let alone visual bloat such as "share as", "like", "comment" and other social widgets all implemented as iframes with their own separate trackers, and the sum of it all has a large impact on both download sizes and performance, since they are seldom optimized. Oil on fire is the fact that there is generally no incentive to remove libraries that no longer have a use.
AMP forces newspapers and other content providers reliant on advertising to play nice. It gives them an incentive (through caching and better indexing) which costs them the bloat.
> Today, multiple web metrics providers are on board, including Moat (who partner with Chartbeat), Nielsen, ComScore, Parse.ly, ClickTale, Adobe Analytics
As far as I know, our (Snowplow's) PR into AMP is the first and only (so far) from a non-GA analytics vendor:
https://github.com/ampproject/amphtml/pull/1358
Maybe I'm looking in the wrong place?
Oh my: http://tools.pingdom.com/fpt/#!/bniZiH/https://www.theguardi...
"Such mobile performance, wow". 4 megabytes of video(Preloading two different videos. Why?), maybe 10 different domains, downloading JS before downloading images...
And this is the showcase for AMP.
It's almost as if "there is no silver bullet" for web performance, and "actual programming skill" is still a requirement.
There is a difference between AMP and non-AMP, yes: http://tools.pingdom.com/fpt/#!/bAnV7C/https://www.theguardi...
But at this point in time, it seems that installing an ad blocker has about the same impact as "conceding to view a crippled AMP-redesign of the page that doesn't even have navigation".
Which is great and everything, but for a reader in Texas, that becomes 1.2s thanks to the fact that my site is hosted in London.
As you point out, AMP pages which weigh in at 4MB can be loaded in a seemingly underwhelming time: ~800ms. However, I think the important takeaway from this is that the pages load in ~800ms in two different continents.
The articles I publish on my blog use AMP-HTML. I don't include media or ads at all, just text and fonts. These pages fully load in 200ms.
I conclude that the free CDN offered by Google is, frankly, a very attractive feature.
If the government can subpoena data from Google, are we sure they're not doing the same or more with CDNs, which don't seem as transparent as the consumer-facing companies.
And "Place a CDN in front of it" has been an available solution for... what, more than a decade?
If your site has meaningful traffic from multiple continents, you can spend the $10/mo it takes to add a CDN to it.
AMP: http://tools.pingdom.com/fpt/#!/brWXpA/http://www.theguardia... Requests: 67 Load time: 485ms Page size: 627.3kB
Non-AMP: http://tools.pingdom.com/fpt/#!/eNuTPX/http://www.theguardia... Requests: 136 Load time: 2.88s Page size: 1.8MB
And to be fair, note that the non-AMP page has a lot more content, onward links, components, etc.
And don't a lot of these sources only start loading once the page has finished rendering? AMP is supposed to be fast-to-render firstmost, right?
if a publisher want to do everything right in todays internet, they need
now add did i forget something?yes page bloat, third party crap and webperformance is a serious issue for users and publishers, but solving it with throwing another half baked technology at the publishers will not work.
it's cHTML all over again https://en.wikipedia.org/wiki/C-HTML
AMP solves the right problem with a non solution.
* a responsive website
* with views for desktop, mobile and tablet
#3 and #4 are similarly redundant
#1 makes all of the apps unnecessary, along with AMP and Facebook Instant. See also the dismal return on the sunk cost for developing apps: http://techcrunch.com/2015/07/23/i-dont-want-your-app/
The real omission, however, should have been #0: “high-quality content”. Sure, you see the NYT, NPR, Guardian, et al. post a lot on Twitter, Facebook, etc. but they were already some of the most popular content on the web and would have been widely shared either way.
http://alistapart.com/article/responsive-web-design
It's somewhat unlikely that anyone working in front-end development in 2016 would assume the generic usage.
https://xkcd.com/927/
Without too much hassle I can support all device types and as long as I am careful to use small image files and minimized JS and CSS, page load times are pretty good.
"Google made clear that AMP wasn’t the only way to speed up mobile pages." http://searchengineland.com/google-amp-coming-rank-fast-2380...
Accelerated Mobile Pages are just like any other HTML page, but with a limited set of allowed technical functionality that is defined and governed by the open source AMP spec
And from the Spec:
Enable the AMP runtime to manage the loading of external resources, which may slow down the initial render or cause jank. Allow AMP authors to include functionality above and beyond standard HTML, while maintaining the security- and performance-minded requirement that no author-written JavaScript is executed
Appears we won't have access to Canvas2D, WebGL, WebRTC, Fetch and other HTML5 Web APIs. AMP's subset of declarative elements and caching will be great for longform-y "static" content. The kind of articles I find myself reading more of on Mobile Chrome during down times in transit. Thinking of Medium confessionals and NewYorker dispatches, etc.
But how do you implement something like ChartBeat? Snapshots of dynamic chart images and data pre-rendered on the server and pushed out to the cdn? Sort of eliminates the performance benefits of geospatial caching doesn't it...
I do take heart however in Tony Haile's pull quote from the ampproject.org homepage:
The mobile open web experience is terrible and some have suggested it's too slow to compete. We can choose to see the mobile open web as a relic of its time and flee to the warm embrace of closed platforms and apps. Or we can say that the open web means something important to the world and if it’s broken it’s our job to fix it. I think we should fix it.
I'd honestly be pretty surprised if they didn't just opt to support all IAB-approved ad formats. The one format I could see being a big question mark is "native ads." Outside of their increased Gmail ad presence, Google has been curiously absent from the native advertising landscape.
His point is a good one. In terms of feeds of potential branding interest, beyond Youtube, Google's big (and mostly untapped) opportunity is in Gmail.
They made a stride to first assert control and doing users a favor by moving things to the Promotions tab. Now they have their ads in the email "feed" in that tab. The Inbox product, IMHO, was their attempt at redefining email into an fully algorithmically-curated feed ala FB, Twitter and Reddit.
My personal bet is that Inbox was a proof of concept and they will force Gmail to shift to that approach in the not too distant future. If users don't leave en masse, I would not be surprised at all to see Google forcing advertisers to pay to get into the inboxes of Gmail users--even users who have explicitly asked for promotional emails. That was FB's brilliant gambit (that somewhat blew up in their face). They convinced advertisers to invest in building an audience on the FB platform (so FB owned the audience), let them see revenue from it, and then switched from a "communicate all you like to everyone who Likes you for free!" model to a "pay us on an auction model if you want to reach anyone" model. Many advertisers consider it a huge bait-and-switch play, but I can't deny that it seems to have been successful. And that is why I won't be surprised to see Google follow suit there.
What I don't understand is why search engines don't punish those individuals with larger pages rather than move everyone to something new? Is this taking us back to the mobile site days?
I love the concept of getting core content to the user fast but what is stopping someone adding a 2MB amp-img to their page and then we are right back where we were before?
This is why we need IPFS sooner rather than later.
https://m.youtube.com/watch?ebc=ANyPxKqMiNbStnEQHC-kiEBSd1jI...
I think it's a smart move on their part actually, but what I assume will eventually happen is other providers will come along and provide a similar free infrastructure but without retaining logs and then everyone will migrate to that. Google will have gotten the ball rolling, and benefited for a number of years from the data, but ultimately people on the web prefer not to be tracked.
Most of my non-technical friends are super concerned, and frequently tell me how scary it is not knowing what to do or how to avoid it.
It's an active role the current ad-based industry takes to convince their users that the tracking either doesn't matter or somehow empowers the user, which are both demonstrably false.
Talk about a brilliant strategic move if this pans out since they'll be speeding up the web, gaining a massive dataset they didn't have access to before, and building a nice moat along with it.
Something which loads really instantly is D's forum, it's incredibly how fast it is and it's written in D:
http://forum.dlang.org/
(I am not into D, just found this thing recently on reddit/programming)
> The reality is that content can take several seconds to load, or, because the user abandons the slow page, never fully loads at all. Accelerated Mobile Pages are web pages designed to load instantaneously – they are a step towards a better mobile web for all.
That's kind of dishonest of Google. The "content" doesn't take longer to load. The website does, but its because of Ads, pointless JS scripts that are spying on the user and a whole host of things that are _NOT_CONTENT_.
In any case, even if creating a new standard, or reduced-HTML, or w/e made sense, I'd be less skeptical if it wasn't controlled by an advertising company.