Google’s AMP Poised to Take the Lead from Facebook’s and Apple’s Walled Gardens
mondaynote.com
mondaynote.com
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
* 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
* facebook instant articles
* google amp pages
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.
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 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.
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.
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.
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?
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.
This is why we need IPFS sooner rather than later.
https://m.youtube.com/watch?ebc=ANyPxKqMiNbStnEQHC-kiEBSd1jI...
> 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?
"Google made clear that AMP wasn’t the only way to speed up mobile pages." http://searchengineland.com/google-amp-coming-rank-fast-2380...
Something which loads really instantly is D's forum, it's incredibly how fast it is and it's written in D:
(I am not into D, just found this thing recently on reddit/programming)
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.
> 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.