Top web developers and thought leaders got together and published a site called AMPletter.org. The page is a simple letter that outlines some positions and concerns about the Google AMP project.
I see 'open letters' like this from time to time. Some I agree with, but don't bother endorsing. Others it may not be a lack of agreement, but a lack of real importance compelling my endorsement.
But AMP is different.
Since it was introduced 2.5 years ago I have seen issues. At the same time I appreciate what Google's public intentions are.
It's good to know I am not alone and some of my peers banded together to state the issue clearly and politely.
What is AMP?
A couple of years ago the Google search team set out to improve the web. Like me, they see all of the poor development practices being propagated. These bad practices make the web slow and deliver bad consumer experiences.
How often do you start reading an article, only to have it jump down the page. Then just as you readjust to find where you were, it jumps back?
I hate that too.
This is a product of poor development and UX. Low quality third party content, aka ads, cause most of these poor experiences.
Google has a vested interest in the success of the web. The 19 second mobile load time is just one indicator. Since mobile is the dominant consumer device today, speed makes a huge difference.
So Google created AMP as a way to fix common issues they see propagated around the web.
The goal is to make the web great again, but with Google controlling everything.
In essence they lost confidence in businesses hiring competent web developers and applying the guidance they and other companies evangelize.
Instead of relying on their evangelism campaigns, they said screw it, we'll just do it for you. As a reward for letting Google do render and host your content for you, AMP ages get high profile search result placement
The problem is two fold.
You only get the preferential placement if it is an AMP page.
AMPpages are hosted and managed by Google.
In fact they are served from a Google domain. Today that is either a sub folder of Google.com or a sub domain of ampproject.org.
Either way it is not your domain, which hurts your branding effort.
Publishers can still maintain their existing, very slow and poor user experience, websites but they should also have a parallel AMP version.
Doing so causes Google to consume the AMP ages and host them on Google Web servers. Consumers are greeted with special search placement for these AMP ages. But instead of going to the publishers URL, they are sent to a Google URL.
The main idea is to make the web faster and offer better user experience. Google knows how to do this, but instead of advising companies how to deliver these experiences they are simply grabbing their content and doing so themselves.
In essence you are creating content for Google, not your brand.
That is not 100% fair. The Chrome team does a great job evangilizing web development best practices. Unfortunately their reach is rather limited in my opinion.
Not for lack of making content available, but because 99% of developers simply don't care.
And Google does pass along some of the 'link juice' to your canonical URL and allows some minor branding to carry along.
AMP in SEO
Search engine marketers are on the fence about AMP. They don't like the way it works, but can help but take the premier search placement it offers.But is it really good search placement when the traffic never hits your site, and you don't have a way to monetize the content?
As I study the SEO world and their opinion about AMP, I think they would rather see it go. Instead of AMP, the ability to achieve better rankings should apply to better experiences.
And honestly, that's exactly what Google wants for better search rankings, good user experience. Because Google consumes so much web content they have it can analyze and determine what consumers really want.
At this point we know there are roughly 200 different criteria Google uses to rank pages and search results.
Google also uses machine learning as a big part of the ranking algorithm these days. This means that there are probably thousands upon thousands of other ranking factors.
But it all boils down to, do customers really want to read what you have published?
You can do all the technical things right, but if your content sucks they will bounce back and go to the next result.
You can write the best content in the world but if you fail on the majority of the technical aspects the same thing happens, the customer bounces back and chooses another option.
And here's the main thing...
We know pages must load within three seconds or you've lost half of the people who clicked your link. Not only are you wasting money, but your building a bad brand reputation.
When this happens Google, and your brand, both suffer. That's because they put their recommendation on you and you failed to deliver. By not offering the best result, they are tarnishing their brand because of your bad experience.
This is why Google created AMP. A way to effectively save the web because they don't feel like publishers are willing to do so.
So what's the real problem?
Well it's a combination to be honest. First, publishers, and by that I mean newspapers and news sites for the most part, rely heavily on third-party advertising services. While I have no problem with them trying to monetize their content through ad services, the services provid very poor quality code.
As I analyze hundreds upon hundreds of web page waterfalls news sites continually fail miserably.
No one likes this.
Can the web run fast?
Of course it can.
That's exactly what the creators of ampletter.org want to prove.
These are my friends and influencers. And we/they know how to make websites load instantly.
We been doing it for years. And we try to help you do the same.
So how do we know how to build websites fast?
- we listen to what browser teams and search teams tell us
- we analyze real data just like the search engines
- we get our elbows dirty writing code and testing it
We know third-party scripts are the worst thing on the Internet today. So we try to avoid them.
We also know why these scripts are bad and we offer solutions and fixes, but are often ignored.
We also know the cost of Fast Food Frameworks and focus on using cleaner code.
What is the main point of AMPLetter.org?
If you read it, they don't have a problem with Google promoting AMP. And I don't either.
You see that's not the problem. In fact it's sort of a good thing.
However, Google should not require you to host your pages on a Google web server. You should be free to implement AMP on your own server and serve from your own domain.
What about those of us who can make good, fast loading user experiences?
This is the main point of the whole letter.
Those of us who know how to make pages load instantly should receive the same preference as AMP pages.
Does AMP Do Anything You Can't Do?
What's one of the first things they offer up in their tutorial? How to use the amp image tag.
My assumption is this tag is used by their server to consume your image and turn it into a responsive image array. Part of the process also optimizes the image file sizes..
That is exactly what I do with my sites.
If you take the time to look at any of the images on this site they are all responsive. For the last year or two I have used responsive images and run them through an image optimization service.
There are other performance improvements that the AMP project offers. They are all in line with all the best practices I've been preaching for the last 10 or so years.
In fact, there are in line with all of my friends recommendations as well.
Identifying Performance KPIs As a Search Signal
One of the last points the AMP letter makes is identify a standard set of performance measurements we can use to determine if a page loads fast.
I think Google already has some standardized tests we can use. We can even make them part of our automated testing process because they are accessible via node modules.
The speed test is a tool offered by the Google search team and has some good tests and feedback. I don't 100% agree with the criteria, but it is a good test.
Lighthouse is an evolution of performance audits in the Chrome developer tools. Today it has 4 main areas to tests, Progressive Web Apps, Accessibility, Performance and best practices. I think Lighthouse is a more thorough test.
Having a real performance metric or set of metrics would be the best solution, in my opinion, because then everyone could focus on meeting those goals and know where they currently stand.
The Problem with Walled Content Gardens
This is another area of contention I have with AMP. In fact I have this problem with Facebook and Apple as well.
The overwhelming effort by these companies to have us create the content they own and "wall off" from the outside world.
AMP pages are hosted on a Google server and served them from a Google domain. This means that Google in essence owns the content.
Hhave you considered Facebook?
Facebook is the app people use on their mobile devices. There is no question about it. Facebook owns roughly 80% of mobile device screen time.
But is Facebook really "app-like"?
Facebook is really just a proprietary browser, using a proprietary markup syntax called JSX.
Industry analyst have gone so far to point this out. The difference is Facebook has its own content and structure. They curate your news feed content in a very controlled manner.
For instance, did you know that the content in your newsfeed is only about 4-6% of the actual content of your friends and pages you follow?
Facebook wants to force business owners to promote their content via Facebook ads.
Imagine what you would actually see if you had an un-filtered newsfeed. It would be pretty darn noisy be honest.
Maybe you can start seen how each of these industry giants are trying to create their own curated and closed off worlds of content. Where the obvious goal is to have you never leave their properties.
Google has not done this with AMP, yet, but I could see how this might be the direction they head.
It does concern me a little at this point. I would be more concerned if it seemed more aggressive.
For what it's worth, the Google mobile first index does not support AMP pages. Which I find very ironic ,since that's where most the performance issues lie, mobile devices.This may change this year as Google is switching to a mobile first index and deprecating the legacy desktop index.
These are my issues and concerns about AMP.
Now ask yourself is this good for the web?
Knowing that folks like myself, my friends, crafted the letter and others who signed it like me, know how to make sites that load instantly, do you think our properties and projects should not receive the same benefit as AMP?
And what about a standardize measuring index?
What you think about AMP?
Do you think AMP pages should receive preferential treatment in the search engine results?
Or do you think that maybe Google should increase the weight they give to any fast loading pages in their search engine algorithm?
What do you think Google should do with AMP?
What do you think of the AMP Letter?
If you feel like me and many others, I invite you to make a pull request and get, and add your name to the list.