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
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.
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.
They can put ads, they can even put analytics and links back to their main site. The brand lift they get from all the views also has value.
Unless Google won't let you load lightweight ads outside of AMP, which is its own issue.
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.
AMP pages run ads....
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
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.
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).
Why wouldn't this work?
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.
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.
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!
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.
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.
On SERPs, both the "flash" icon and the AMP carousel are AMP-exclusive which suggests that Google is abusing its market power.
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.
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.
And by construction, AMP pages are easy to analyze without having to execute anything.
(disclaimer: I work at Google, and used to work on Search)
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.)
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.
Everyone is free to follow, but they don't accept contributions. That is monopolising.
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.
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.
I just don't get what the big deal is.
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.
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.
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
- 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?
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.
Penalize my search listing all you like, but none of my stuff will be hosted elsewhere.
I thought publishers learned their lessons here - use someone else's printing press, and ultimately, they control what's printed.
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.
(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?
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?
There are more examples and a broader examination available from idlewords:
Crazy because when you look at Medium it does appear to be very clean so this experience has certainly been somewhat disillusioning.
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.
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.
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.
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.
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.
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.
As an example of using AMP with normal links, see Cloudflare's implementation. 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.
> 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.
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?
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?
But that's different from the argument being made in the article, which is that AMP as a performance booster is "bad" because it "breaks links".
This is what a lot of people are worried about.
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.
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.
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 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.
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
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.
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 was reading one on google news and I wanted to share it with you guys but I couldn't figure out how to get a URL for the story.
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.
I am somewhat a Google fan, happily paying for music, tv shows, movies, and use the Google cloud platform. I also get some value from Facebook.
That said, I think that Google and Facebook are going to eventually badly damage the web, or at least the web that I love.
What about the value of seconds amd bandwidth saved for millions of people who get pages a bit faster due to a project like AMP?
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.
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.
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.
Just don't use Google's CDN then, use someone else's, like Cloudflare or Bing.