Do we really need Instant Articles (Facebook) and AMP (Google) when we can accomplish fast loading pages with plain, uncomplicated HTML and CSS?
I feel that many web developers don't realise that simple HTML and CSS is often all you need to make clear, fast loading pages. No complicated tricks or techniques required. You can make the page reasonably pleasant in appearance too.
Think of the sites you often visit: news stories, blogs, magazine-style sites, discussion sites. These are mostly text, not web apps.
I hope I'm not hijacking this thread, but I'd like to ask if readers find the web page links below fast to load on their mobile phones? They don't use AMP.
I created the pages below as a test because I was (and still am) frustrated by the slow page-loading speeds when using my phone with a 3G connection.
The page links below represent a common article/blog/report style of page. There's about 2500+ words on the page.
The page content is CC licensed but the pictures from the original synopsis are not included despite the references in the text (since this was just a test)
Okay but let's be realistic-- you are not a major publisher trying to make money off these pages. You can say "yes my page loads in 100k and 300ms until DOMContentLoaded" all you want, that doesn't change the fact that when you slap a couple of pieces of advertising on there, it's going to slow down.
To give you an idea-- the New York Times page without any advertising on it is 2MB and has a DOMContentLoaded event at 1.29s, approximately 1 second slower than your page. With advertising, it is 3.9MB and 1.82s.
When ad networks are able to run without almost 2MB of Javascript, then we can talk about how AMP isn't needed.
> you are not a major publisher trying to make money off these pages.
Hate to break it to you, but major publishers aren't making any money of the AMP'd version of their pages - most of the monetization is stripped out, and readers aren't even actually on their site so they won't stay and click around.
The spec for amp specifically has an "amp-ad" tag for displaying ads. There are multiple ways they can be shown in an AMP page. The nice thing about AMP ads is they will not cause the page to change layout/flow as they load. I believe a size must be declared for ads to prevent bad behavior.
I didn't say they couldn't show ads, but basic ads aren't the only way that these places monetize. Trackers, 'you might also like' panels, etc all feed in to the overall monetization strategy. A couple of amp-approved ads on an amp-page don't necessarily make up for all that...
I'm not trying to avoid anything. As a user I don't even get a choice for AMP or no AMP. In fact, I changed my search engine on my phone to DuckDuckGo specifically to get rid of AMP pages.
As a dev at a major publisher I can confirm that we are making money off these pages, and readers are actually clicking on more recirculation links. The monetization isn't stripped out at all, it's just all sandboxed in iframes.
^^^And THAT RIGHT THERE is why I load the asynchronous Adsense script at the very bottom of my pages, after everything else, and why I load my core JavaScript synchronously, just before that, so it can schedule key tasks before getting swamped with third party guff.
I mean, sure, Adsense loads asynchronously and Google claims it won't slow your page loads, but once it starts loading advertising assets and scripts it's the Wild West. Some - not all, by any means, but some - of those third party scripts are extremely badly behaved and, yes, they do measurably slow your page load down.
page without any advertising on it is 2MB and has a
DOMContentLoaded event at 1.29s
With advertising, it is 3.9MB and 1.82s
This does not support your core argument about ads being the issue.
The ads load in 602ms.
The page loads in 1290ms
The ads are 1.9MB of data
The page is 2MB
Yes the ads are very heavy. But how are the ads slowing the page down exactly? The page is already INCREDIBLY slow without them.
Only ~30% of load time is spent with displaying the ads. The other ~60% is what ever brain damage the NYT web team cooked up. If anything you are enforcing parent poster's point.
I doubt the payload is the problem in most cases. The ads load asynchronously, in most cases, and cause other types of performance issues. When an ad loads and causes your scroll position to be lost, or when the ad takes over the screen and can't be closed, or when you get a malicious ad that starts running JavaScript that starts opening alerts and redirects you, all of these things simply don't happen with AMP.
I disagree with that. AMP pages load and work for me without fail. Most non-AMP news sites are unreadable on my phone. Saying it adds a "layer of suck over an already sucky experience" doesn't give AMP nearly enough credit.
How do you find the URL of an AMP page? What's the point of it if I can't? Sharing content from mobile is near impossible without also tracking the sharing.
I mean, really, that's most of AMP: a restriction on a bunch of elements that may slow things down and a bit of special mark up so things can be further accelerated.
If most websites actually did load quickly, then I don't think AMP would have a reason to exist. But if most websites can't manage to slim down their bloat, then one potential answer may be to take away some of their toys (and I'm not saying it's the right answer, just a large part of AMP).
Ok, so the solution is to create a standard subset of elements and create an open tool to test your site against the standard. If your page meets the requirements it gets the pagerank boost. If it doesn't meet the requirements somewhere then it points out what you need to change. No need for AMP.
That would work (and personally I would prefer if AMP went in that direction) but it would be merely fast instead of crazy fast because apparently prerendering is only possible if you use the Google CDN.
Why? Chrome has been prerendering pages on search results for years. The only thing I could think of that would make it slower is that you may need to do a DNS request for a different domain, where google's domain is already resolved. (And google probably has a better CDN.)
google could have opted to create a standard that matches the amp standard, but not host the pages, and not put a "X" bar at the top, and not create new urls. they could have put the lightning icon on the serps next to all pages that are fully compliant with the standard.
the difference in speed between google-hosted amp and what i suggest above would be minimal.
the reason google didnt do it this way is because amp is not about speed. speed is just the thing they pitch to you to get you to look past all the negative aspects of the system.
Google could have, indeed. We were aiming at instant loading, though, and for instant loading we needed to do pre-rendering, and the only known way to do that does not allow for changing the origin (has to stay https://www.google.com).
We are working on a few ways how to both make access to the base URL easier and how to eventually even get the right URL in place.
We're not talking about developer/technical blogs, which are generally very lightweight, and the person making it likely takes pride in things like efficiency. Your typical content publishing platform on the other hand, is a giant mess of wordpress plugins, tracking, ads, and scripts that pull in other scripts that pull in other scripts. Is it efficient from a technical perspective? No, but it gets the job done for them. AMP is a solution that makes it dead simple for these shops to get a reasonable load time for their content on mobile, which translates to less time spent, which at the end of the day is more important to them.
The problem is that their framework is too big and bloated. Your suggestion is to have them add another layer on top of that, rather than remove the bloat?
> we can accomplish fast loading pages with plain, uncomplicated HTML and CSS?
Sure, but news sites don't. That's the problem. They're loaded with bullshit that makes them mostly unreadable on many devices, screws with your scrolling, and takes insane amounts of bandwidth. The problem is that these news sites are fiscally incentivized to make their experiences bad. The more crap you load, the more money you make.
The hook here is that Google gives priority to AMP pages. "Make your page be provably not terrible and we'll rank you higher than your competitors" is a really juicy proposition, and it makes the user (who just wants to read their news) happier. To a news site, you're faced with the decision of having more revenue with a terrible UX or potentially less revenue with more traffic.
Version B was noticeably slower for me on desktop, but still 100% okay in my book. Version A was near-instant. My eye caught that the image didn't magically appear fully loaded, but after a split second loading was complete and the page (and layout) look great!
Thanks for trying out these test pages! When I created them, I tried loading them in different locations on my phone. Surprisingly, even in busy city-centre locations (using 3G), the pages weren't always loading instantly - but they were fairly fast, enough to feel usable.
Anecdotally, this article for me took about 5 seconds after loading the text to apply its CSS and fonts, which was kinda jarring when reading. I don't need an exotic font to read basic content. I'd most like a simple lightweight site, but I'd take AMP over this site's clunkiness.
Version A was excruciatingly slow. Version B was very quick.
I wonder if original dns resolution wasn't to blame... or either load or lack of a recent one on your server. I know I'm a little late to the party in this thread.
> Do we really need Instant Articles (Facebook) and AMP (Google) when we can accomplish fast loading pages with plain, uncomplicated HTML and CSS?
Can you suggest frameworks that help me do this automatically? Please no, raw html. I daresay that those would recommend developing without frameworks have no experience maintaining other people's projects.
We need it like we needed "use strict" in JS, which is to say not really, but it really helps. I think of AMP as "HTML Strict", a means of enforcing the rules and practices necessary for faster web sites.
They do. They reward sites that load fast. They also offer AMP as another way to speed sites up, which in turn makes them rise in rankings. But Google offers a large suite of tools to help web developers speed up their websites.
I hear this a lot, but whenever I search for something common like lyrics or weather, I get only large bloated webpages, while the lightweight and simple ones are nowhere to be found. Unless Google opens up their reasoning for ranking, I genuinely don't believe they add enough weight to load-times.
Huh, what? What site do you get? I always get azlyrics which is a fairly simple and clean site. EVery other one I tried seems more bloated.
Obviously, there's many other factors at play. SEO is a complicated world, especially in such a crowded place as song lyrics. Though I noticed Google actually has an inline box for lyrics now which avoids the issue entirely.
azlyrics is far from what I would consider simple or clean. It took over 30s to load for me and had way too much junk on the page.
Yes, there are many factors, and I clearly don't know all of them. I definitely see the problem that Google's inline (or amp) is trying to solve, but I think encouraging the right sites to grow to the top is a much better solution.
If only it were as simple as that. AMP websites get a place in the search carousel of Google. So even if your website loads faster than an AMP page, it would not be placed in the carousel - and that's Google forcing companies to adopt AMP even if they already have a fast website.
The world isn't that simple. Search engines know how fast their fetches are all of the time, but they only know how fast a javascript-heavy site is when the search engine crawls with javascript on -- which is rarely.
And by construction, AMP pages are easy to analyze without having to execute anything.
You perhaps underestimate the complexity and fidelity of the Google crawl, indexing, and ranking pipeline. Many intelligent people have spent many years trying to solve the sorts of problems you describe.
(disclaimer: I work at Google, and used to work on Search)
I totally get that Google has done a lot of work on these issues. It is still the case that no website that wants good ranks should depend on Google executing their javascript. Implementing AMP, on the other hand, means that you know you're going to get a good mobile speed score.
In no way was I dissing Google's crawl or crawl team. I'm just handing out conservative advice for website owners.
(disclaimer: blekko Founder/CTO. Nice to meet you.)
AMP pages can be tested and proven to load fast. There's no way to guarantee that a non-AMP page will be fast for a user. The way AMP is designed allows Google to inspect the source and determine whether the page meets the requirements or not. Caching the page guarantees that the content Google tests is the content the user gets.
Imagine if Google rewarded plain old websites the same way they reward AMP sites. You'd have sites gaming the system by hiding ads and disabling web fonts just to get ranked higher, then taking a crap on "real" users visiting the site.
AMP is a standard for creating fast / jank-free web sites, which all search engines can implement freely. Google is spearheading the effort because nobody else did, but they're not monopolizing it. Everyone is free to contribute.
It is not true that AMP does not accept contributions. What is your data to back that up?
Here is actual data: https://github.com/ampproject/amphtml/graphs/contributors
AMP currently has 275 contributors (people whose code was merged) on its open source project. Lets aim high and say 50 of them work for Google (probably a bit less), that leaves about 225 other contributors.
I love AMP because I can easily tell which sites will actually load fast and give me the info I wanted directly from the search results page.
Publishers are still able to track pageviews and serve ads, so I don't get what the hullaballoo is all about here.
There's nothing in the AMP spec that stops links from working.
I just searched for "Is Google AMP a good thing" on my mobile, and got the OP's post as the first result (probably personalized?). Had to go to the fourth result for something with AMP, from CIO.com. The page loaded instantly, was able to scroll without things jumping around, and the header link to the CIO.com homepage worked as expected. They were still able to serve ads and count my pageview too, even if I never directly contacted their server.
Just for giggles, I hit "copy link" in the Chrome Webview that the Android Google Search App opened up. Pasted that into Android Chrome, and it took me straight the AMP page, which loaded instantly and let me scroll right away. Seems fine.
I then went to my desktop, used the Chrome history feature to open the tab from my mobile, and the AMP URL redirected me to the publisher's desktop site, which took multiple seconds to load and then displayed an annoying interstitial.
If anything, I'm frustrated that my desktop browser wouldn't open the AMP page and load and allow scrolling immediately with no interstitials.
The "huge useless bar" at the top was the exact same in the AGSA Chrome Webview as the OP's non-AMP site. I don't know what you're on about. I didn't notice it because it's not there.
I went and looked at the search results in Android Chrome (instead of the Google Search app), and there was an extra bar at the top that said "From cio.com" which disappeared as soon as I scrolled, which happened instantly because I was able to load and scroll instantly.
I don't much like the idea of AMP because, to me, it does violate the idea of an open and free world wide web. But, equally, publishers have brought this on themselves. (And I suppose, equally, it isn't the halcyon days of the mid 1990s any more either.)
Sites are egregiously slow and heavyweight, and the experience on mobile is often nothing short of appalling with actual content when it eventually loads relegated below the fold, or near the bottom of the screen. You then have to find a way to scroll without accidentally triggering an ad and once you've done this you're likely to be confronted with one of those delayed interstitials that are so in vogue (and so completely unacceptable) at the moment.
From this perspective AMP is kind of a backdoor to holding large media outlets (in particular) to account for the inexcusably poor web experience they offer to users. Because this isn't a technology limitation: it's a choice they make in the name of monetization.
I don't really care about that. I just know that if I see the AMP logo on a search result that I'm about to click, it's going to be a pleasant experience when I click through and very quickly am able to read the page. Whereas almost any other news site will be more or less unreadable and unscrollable, constantly changing as it loads over the course of a minute or more, until a huge popover blocks the whole thing and refuses to close.
It may be a non-optimal solution to the problem, but much like Uber, until someone comes up with something better, I'll take it, because it does improve my experience greatly.
Maybe I'm being selfish, but when I click on an AMP link I know the page is going to scroll funny on my iOS device (something with iframes?) and there'll be an oversized bar at the top and the site will feel really... bland and off compared to what I expected, like I clicked reading mode even though if I wanted reading mode I'd have clicked that.
Im torn because while I want mobile versions of sites to be fast over poor connections, I also don't want to read what looks like a cached version version of the sute. Maybe it's the AMP sites I've visited but it's always way too jarring
The fact that the person receiving the link will also get a fast loading well behaved page with a bar at the top is not such a deal breaker for everyone.
Yes, you are right, the speed is great and the concept is actually quite interesting. What annoys me is the fact that they broke the UX on iOS (don't know about other platforms);
- you cannot scroll to the top by typing on the bar at the top on the screen
- there's this AMP title bar at the top, that's super annoying. I read, they might eventually add the option to hide it
- feels like they tried to implement smooth scrolling what conflicts with native iOS smooth scrolling resulting in not-so-smooth scrolling
Finally, and that is more important I'd say, we have the whole point about the openness of the Internet. People are concerned about what Google (and Facebook) does because there is the potential to create a walled garden of exclusive content not everyone can access - which would actually contradict the idea of AMP, wouldn't it?
It's true that loading fast and giving you the info you wanted directly from the search results page is a good thing. It is also important to realize there's a trade off happening where you're further locked into Google and their ecosystem. It's a pretty dramatic change to the way search has worked up until now. It more mimics the way internal webviews work in Apps like Twitter and Facebook apps.
> It is also important to realize there's a trade off happening where you're further locked into Google and their ecosystem
How am I locked in? Google isn't the authoritative host of AMP content, nor are they the only party running an AMP cache, nor does the existence of an AMP copy of a page prevent me from accessing the regular web copy.
But, you don't actually get to their page. Once you click on an AMP link on Google's SERP, I've found it impossible to actually "open full site" as you might expect to be able to do. It's also annoying to try and share a search result link only to have it be an AMP redirect.
It's sacrificing the open web in exchange for a is-this-fast indicator. If the search engine just made note of the site's speed during its crawling, and made that information available to the user, then sites everywhere would find their own ways of speeding up their whole site instead of just some proprietary search result.
It got annoying enough for me to switch my search to bing.com everywhere, including Google's own browser. My two main complaints: 1. Once I am on AMP page, most of the time I want to click around the site and I cannot do that - feels like a cage. 2. URL obfuscates the site name and article title (not completely, but definitely adds visual noise)
I don't think I've ever seen an AMP page on a google search result, so either I'm searching for very different things than you are, or there's some browser configuration that doesn't show tons of AMP sites on Google.
I usually browse with JS off (though I think not on Google) and the standard suite of privacy apps - uBlock Origin, Privacy Badger, etc, and I usually use the version of Google with Instant disabled. Maybe that helps.
I was thinking earlier, why don't mozilla or the FSF take a shot at building their own search engine? Imagine how many projects the monetization could fund?
(Though, actually, it's only a response in spirit; Bakaus's article was posted about a week earlier than Miessler's.)
I think the problem with the AMP cache model is that, because you need to link directly to the cached URL, you commit to exactly one cache provider. If Bing were to also implement their own validated AMP cache for Bing search results, you can't have one link point to both; you're either AMPed in Google results or in Bing results, and, by being marginally bigger, Google wins all of the pie. That's no good.
How might we change the AMP standard, or the trust model around AMP caches, to get the same performance wins while still enabling competition?
Similar to Medium, AMP encourages fast page loads and no interstitials, pop-ups or other cancer that seems to infest the average site these days.
Yes, it may be possible to fix it over time. But I see AMP and Medium as clean, lightweight platforms that developers/marketers want to emulate and users will start to demand.
From a user experience, you definitely can't beat the speed of AMP delivered content. So it's a high bar to beat. But if it forces content providers to up their game, I see it as a good thing.
I guess the scary point, that hasn't explicitly been mentioned, is what happens when a good portion (maybe not a majority) of content is AMP-enabled. Is it something we transition away from, or is it here to stay? Will non-AMP, but fast pages be second-class citizens in the new AMP-era?
That's really strange. 760KB for me, but it was a good 3 - 4 seconds before everything had rendered. The article content was there much more quickly, but the recommendations and responses sections below took longer to appear.
Crazy because when you look at Medium it does appear to be very clean so this experience has certainly been somewhat disillusioning.
Out of interest, is there anyone who wants to defend the current Google AMP (not the concept of lighter webpages, but how google has gone about it?) I haven't found anyone yet personally.
1. I can click a link to an article from a search result
2. I can read the article without having to wait 5 mins for every little javascript and popup to finish
3. Success
Optimizing a rich content-heavy website is hard, and time consuming. While we all can moan about all the tracking and ads that appear on these sites, they are a fact of life, and simply relying on the engineering chops of every website to up their game is not a winning strategy. It's infinitely simpler at the end of the day to drop in a few extra scripts and meta tags than to yak-shave-optimize the entire site.
We haven't quite reached the point where performance is seen as core functionality. What I will say is that if they've built the site sensibly it should be a case of optimising templates and views rather than yak-shaving-optimising every single page, which is a much more approachable endeavour.
I'm probably going to get flak for this but tracking aside, and I can understand the arguments for that, from my experience a lot of poor performance is down to cargo cult development on the client side.
On the flip-side, if you want an example of a content heavy media site that gets it right: http://www.bbc.com/news.
Certainly, and a lot of it depends on the kind of engineering culture that the particular organization has. Shops like BBC and (especially) Bloomberg have really solid engineering org, which means they have a high degree of give-a-shit, and they have the flexibility to try more cutting-edge solutions that may require in-house maintenance. But as we all know, developing a good engineering culture is difficult and expensive and not everyone can do it.
Sure. AMP is a good thing. Google is simply the first company to implement the AMP cache-- Cloudflare has recently spun up their own and outbound links from Cloudflare-enabled sites can use an AMP cache that doesn't rely on Google, so they get the speed benefits as well.
The implementation of AMP is one of those technologies that's "the more it gets deployed, the better it is." Reading the spec, it's clear that Google's vision is for AMP to be the opposite of FB instant articles; where the entire web can have a decentralized cache (yes this sounds weird but makes sense). I suspect Cloudflare will help quite a bit with this.
I could see mobile networks implementing their own AMP caches, so their inbound traffic winds up terminating mostly at the cache layer. This speed boost will win the mobile networks customers.
> I could see mobile networks implementing their own AMP caches, so their inbound traffic winds up terminating mostly at the cache layer. This speed boost will win the mobile networks customers.
How would that work? Google can replace links to AMP pages with links to their own AMP cache in their search results, since they're the ones generating those resutls. Cloudflare can serve the AMP version of their customers' pages since they are the ones actually terminating the TLS connection.
Mobile operators don't have either type of access. At best they could try to do this for non-encrypted content with some kind of a transparent proxy. But the share of non-encrypted content is plummeting quickly, and might as well not exist soon. No operator is going to invest any money in HTTP-only services at this point.
Just anycast cdn.ampproject.org to a cluster sitting on your network with Google's supervision and cert? This is added value for the provider, just like sticking a bunch of Akamai boxes on your network is added value.
Christian Heilmann (formerly of Mozilla, now Microsoft) recently interviewed[0] AMP developer Paul Bakaus. It was a fantastic interview, as Heilmann grilled Bakaus on some of the issues raised in this thread.
Just noticed a few days ago one of the major Australian newspapers started using AMP.
I do understand the negativities around Google's AMP, but the speed was.. blazing fast.
I can't help to think that for a user who may not be familiar with all the underlying issues, it is a pretty good user experience in terms of the speed alone.
I don't think AMP is nearly as bad as people are making it out to be. The complaints I've seen on HN either only affect developers or are entirely hypothetical.
As someone that dislikes viewing desktop sites on mobile devices I have no problems with AMP. It would seem the majority of people that have issues with it have to do with Google caching the content. If you don't like Google caching AMP content then host your own caching. It's free open source software.
This is software vs. services confusion. It's sort of like saying that if you don't like Reddit's moderation policies, host your own Reddit, it's free software.
Also, most people who complain about AMP claim that no caching is needed, just adherence to the AMP format. But there's no way to go from a Google search results page, or a link provided to you by someone who uses Google for search, to an uncached page.
The full URL is still part of the shared link, so not much of a value has been lost, but the gain (speed boost) still outperforms this "inconvenience".
I don't really feel the hatred against AMP, it works as intended and for me as an end user that's all that matters.
The core argument of this article is flawed. AMP does not break normal links--although the Google search engine sort of does.
As an example of using AMP with normal links, see Cloudflare's implementation[0]. It is possible for many CDN-like services to implement AMP caches. Web sites link to each other normally, and mobile visitors can be served the AMP version.
Remember that AMP is an open standard and accepting pull requests[1].
> Who (other than Google) can possibly see this as a good thing?
Users want faster pages. From all these AMP critics, I have never heard an alternate solution, or even an idea, of how we can streamline delivery of article content.
AMP is imperfect. But it is a step in the right direction _for users_. Critics need to step up with a better idea, or maybe some code, and quit with the (in this case, unfounded) rhetoric.
IIRC Google already does this. But it doesn't solve the same problem as AMP does.
With your solution, site A can load at 2s and site B at 3s, and site A will win. With AMP, sites A and B can both load in 200ms by easily integrating with an open standard.
Also: all this talk of "lock-in" and "centralization". With the approach you proposed, the publisher with the most money to spend on dev resources wins the highest search ranking. Isn't that counter to decentralization? Isn't an open, simple standard like AMP a better solution (though not a perfect one)?
What I'd like to hear from an AMP critic is: how can we achieve what AMP achieves--lightning-fast speeds that users love--without the "evil" AMP approach?
really? cause I don't see any discrete indicator that this page loads blazing fast. just rankings.
meanwhile, people itt are claiming that they deliberately seek out the little thunderbolt as proof of quality. why can't the little thunderbolt be awarded to HackerNews too, even outside the AMP ecosystem?
Cloudflare is doing this AMP crap too. If a cloudflare user enables AMP on his site then links from their domain to yours will trigger a visit of Mozilla/5.0 (compatible; Cloudflare-AMP/1.0; +https://amp.cloudflare.com/bot) AppleWebKit/534.34" which then mirrors the content from your domain and re-hosts it on Cloudflare servers.
Then whenever someone goes to the Cloudflare user's website and clicks a link to your website they'll instead be fed a version of the page from Cloudflare and you'll never see that traffic.
And since you (or me, in this case) don't have a Cloudflare account you can't get any response from Cloudflare support to get them to stop re-hosting and serving your content from their servers.
I remember when Google had a really awesome thing that provided great content experiences: It was called Google Reader. I wish they would take some of the energy they are using trying to force AMP down everyone's throats and just re-launch Reader.
And the beautiful thing is, RSS feeds load quickly with no scripts, embedded ads, or tracking, and isn't tied to any proprietary cloud service provider.
More and more I am convinced Google convinces everyone to move away from things just so they can "reinvent" them down the line in a more proprietary fashion.
I mean, sure, you can put like... text ads in an RSS feed, and I'm sure you can throw a tracking link as a link to click on in there. But unless you click into the page from the RSS feed, you aren't going to be picking up any stray cookies or have any scripts running on your computer. Browsing an RSS reader is very fast, and has very little bloat.
Including Google Reader. You could put ads in the feed. If you really want to track people an image load is enough, too, although it's harder to plug third parties in.
The reaction to AMP is a perfect example of when the things users/publishers care about differ greatly from developers. Users don't care about being on the publisher's site vs. Google's but do really care that that their low-to-medium end phone from 2014 can load the article in <5 seconds on a slow 3G connection. Publishers care that all of their tracking and ads are working properly.
AMP specifications allow for other cache servers, of which CloudFlare[0] has recently implemented one. You could implement your own if you like.
AMP also specifies that the canonical page URL should be used when sharing, though the cached URL is currently what's shown in the browser. Their last developer update[1] said they're working to address this, however for all relevant purposes Google's own systems already currently consider AMP traffic and results to be attributed to the original source.
> Google amends its cached AMP search results with Schema.org and OpenGraph metadata, so posting the link to any platform that honors these should result in the canonical URL being shared.
A) First we had simple web pages
B) Then people want to do fancy stuff on it. It became slower
C) Back to A
Instead of going back to "A", it seems like there new are ideas are coming out (like AMP) but in the end, I really wish we would just go back to "A". HTML is HTML.
Just adblock and you will get a fast browsing experience. The biggest problem is not web development, but the advertising framework that is installed nowadays.
There is a lot of hostility lately toward AMP it seems like. I personally really enjoy it and have found myself now choosing AMP articles over non-article because I know the mobile experience won't suck.
One thing I noticed in the author's post: The author mentions that "The content loads off of Google’s own server, not from the website itself." I don't think that is correct unless you use choose to use the AMP-cache. For example, if you
AMP is a terrible idea. HTML is already very fast, if it's just kept lean and clean.
Creating a new fork of HTML only means less resources for publishers to spend on their existing sites, creating an ever-increasing divergence in experience. Google already had a great way to enforce better performance by taking it into account for search rankings - which it already uses as we've seen just a few days ago to discourage popup modals.
Another issue is that Google's adtech software is the most popular across the web and one of the primary reasons ads are slow in the first place. They've made improvements to speed up ads but they again hold an incredible amount of leverage to force better practices like smaller assets, less JS, async loading, https, no flash, etc and yet still havent don't anything about it.
It seems like AMP was some small side project that's easy to praise and get attention without actually fixing any of the root causes for the web cruft issue, ultimately hurting everyone in the long run.
This is probably the 5th article on amp in the last few days but its already a reality so it would perhaps have helped if this intense focus was put much earlier.
A large number of mainstream sites are already on amp. The rest will inevitably be forced to follow. It's done.
It's a clear abuse of power by Google which would ideally be illegal given its near monopoly search position. Trading convenience for a lock-in is an extremely poor tradeoff in the long run and its a miracle no legal action is in the offing. This is the negative outcome of capitalism, concentration of power which inevitably gets abused.
When i got a Nexus One way back when, it had a news app that preloaded the news with 4-8 paragraphs of plain text and a single photograph. It was great, I could catch up on the news while I was standing in a checkout line or similar short time-wasting situation. AMP gets somewhat back towards that, but it's still slow and unresponsive by comparison.
Google doesn't get news. The people who work on google News clearly don't consume it, barring the unlikely possibility that they're masochists who enjoy making everyday tools work more and more poorly.
I have been suffering with AMP. try to share a link to an article and you current url is an AMP url. if the site didn't make a hard link in the post title, you are gonna have a bad time.
Just like we have made silos on the mobile market, the internet will slowly get it's own silos. For people to value decentralization, they need to be shown direct and observable value. Just taking a moral/ethical stand is not enough. This is the case with anything and not just technology. The cars and the phones we use probably enslave chinese and kill polar bears.. but for all what the general population cares those things don't exist/happen. This comes down to human nature.
It is one of the most annoying things to use, and might actually get me to switch my default search engine. I often search for stuff where the results come up on Reddit. I want to see the comments, but AMP helpfully hides all replies, and only shows like the top 5-10 comments. This is useless. So now instead of getting to the page I want right away, I have to scroll down to the button that says "see more comments". WTF?
Google started stealing content a long time ago on their search page... sometime displaying almost whole pages of content as the first "search result" so that the user doesn't even need to visit the source.
We need tools to help developers build fast websites. If all websites were as fast as AMP and Instant Articles, these platforms would become obsolete. It is in our hands as developers to take back control and make the web as decentralised as possible.
It doesn't seem like the author says why they think it's bad that Google stores articles on its own servers, just that everyone should know already. Not very convincing.
1. Single point of failure/control
2. It's a retraction from the web's inherent uhhh 'webby' nature where you can link to any content.
3. Google wants to become a 'toll booth' on the internet where it inserts itself between users and content.
As an aside, I think people do sense a bit of hypocrisy from a lot of "benevolent" companies like Google. They're all open and standards-y when its about commoditizing a sector in which they don't have any direct financial interest. But they're fiercely closed and proprietary when it serves their interests.
Well, that is not true. The author clearly stated that the problem with AMP is that it creates an artificial silo where all content is being distributed (i.e., in the hands of) Google. But I agree that more arguments (especially also listing the advantages of AMP) would have given the post more credibility.
While the article is correct that there's a big conflict of interest emerging in terms of privacy, it will be exactly like the reaction we've had to all other news of violations on the internet. We've got people with remote controlled submarines siphoning data from the pipes. Yet no outright revolt. People just aren't able to fathom the compromises without the technical framework that most HN'ers have to be able to catch these things in the app.
I'm sure 16 years ago we argued that Google eating up search market would be bad for consumers. People gladly voted Google while ditching Yahoo, Altavista, and other search engines for Google. It will be the same case for AMP or PWAMPs (Progressive Web App + AMP), they are here to stay.
So yes, while you can put a sticker with "AMP? Not in my backyard" on your laptop, but the vast majority of consumers simply don't care.
We are all self serving bunch. Unless more is done other than writing articles and sharing, the status quo will be whatever the unchallenged decides it will be, with the money and resources to see to it. The rest of us can only vote with our money.
The internet is not a democracy after all unless we have some type of mesh networking using our mobile phones, is coupled to governments and their willingness to keep the underweater fibre cables. Creating our own satellite mesh network is obviously out of the question as well.
Strangely I don't see any amp pages if I search within the Google app in Android but see them if search from Chrome. Does anyone know why is this difference? How can I restore amp pages while searching from Google app?
> The content loads off of Google’s own server, not from the website itself.
It seems the author isn't familiar with how CDNs work, how they've been around for many years and how they serve most of the data on the internet.
When you browse YT, the data most likely isn't being served by Google directly, but by a Google-provided rack on your local ISP.
When you browse a newspaper website, it is most likely coming out of an Akamai or some other CDN's server in your local ISP. Akamai by itself serves about 30Tbps of local traffic around the world.
And before these massive CDNs emerged, small ISPs would use caching solutions for static content (most of the web back then).
So we've all been loading content from 3rd party servers for more than a decade, not from the website itself. The internet as it is today is only sustainable because of CDNs.
IMHO, the quoted statement doesn't necessarily preclude CDNs. I think you're reading too much into the phrasing, which like you suggested, is a laypersons view of the internet. To me, it is instantly obvious what the author meant. The question is who controls the platform. For e.g. Are you in control if Google chooses to datamine your readers, or if in the future Google is free to show "suggested" content which is not your own, etc, etc.
> "Are you in control if Google chooses to datamine your readers, or if in the future Google is free to show "suggested" content which is not your own, etc, etc."
Just don't use Google's CDN then, use someone else's, like Cloudflare or Bing.
I feel that many web developers don't realise that simple HTML and CSS is often all you need to make clear, fast loading pages. No complicated tricks or techniques required. You can make the page reasonably pleasant in appearance too.
Think of the sites you often visit: news stories, blogs, magazine-style sites, discussion sites. These are mostly text, not web apps.
I hope I'm not hijacking this thread, but I'd like to ask if readers find the web page links below fast to load on their mobile phones? They don't use AMP.
I created the pages below as a test because I was (and still am) frustrated by the slow page-loading speeds when using my phone with a 3G connection.
The page links below represent a common article/blog/report style of page. There's about 2500+ words on the page.
The page content is CC licensed but the pictures from the original synopsis are not included despite the references in the text (since this was just a test)
So is it fast?
Version A: http://interfacesketch.com/test/energy-book-synopsis-a.html
Here is an identical version to the above but one that loads custom fonts (approx 40kb extra). Is this slower?
Version B: http://interfacesketch.com/test/energy-book-synopsis-b.html