If you browse the web on mobile today, you expect rich graphics, smooth scrolling, fast animations and transitions, all loading quickly.
And the good news is that on a platform and browser level, Some sites making a lot of great progress towards faster, smoother websites. The bad news, however, is that even with these improvements, a lot of websites still won’t magically turn into speedy experiences.
Think about it for a second, if you’re at a bus station and click on a link in your Twitter feed.
You wait for five and then ten seconds.
You keep thinking, it must be amazing content if it takes so long to prepare.
And right then you get pulled back into reality. A full screen asking me to buy something.
Ads that distract from the content and make the page so slow you can’t even scroll and as if that wasn’t enough, a bunch of competing analytics
scripts in the background that loads and kill your phone’s battery.
All of this wouldn’t be such a big deal for the publishers of those sites if you were just willing to continue to suffer.
But you don’t.
You’re furious about the current state. So furious that you either don’t bother, and click off, and studies suggest a 40% of users drop off after just three seconds or decide to install an ad blocker.
Clicking off is a lose-lose situation.
You are frustrated because you didn’t get to read the article your friends posted and publishers are frustrated because they didn’t get a chance to show you other great stuff and relevant ads to help pay to create that free content.
And adblockers might work for you as a reader but harm the business model of many publishers that depend on ads to help pay for the content offered.
But here’s the thing.
Publishers don’t purposely try to slow down pages. They add all of these extras to try to increase the monetization of their site and attract more and more readers to help keep the site in business and then they end up in this tough spot where they feel they need to decide between improving the user experience or focusing on monetization and user acquisition.
These overloaded, user-unfriendly websites aren’t a new problem and some have tried to come up with solutions. The first are walled gardens that lock you to a specific content distribution platform.
Now you have to implement a custom solution for every single platform and your content cannot be discovered through search engines or linked to other websites.
Or you could create a native app and lose even more advantages the web offers, like effortless entry without install, or easy distribution of content.
Google felt this was a problem in need of a simple and elegant solution, a new way to implement and ensure beautiful, streamlined, wicked fast content web pages without all the extra clutter, and it’s built on the openness of the web and doesn’t try to replace it.
That allows everyone to participate and collaborate.
That publishers, platforms, and developers all stand behind and benefit from.
That’s AMP, stands for Accelerated Mobile Pages.
The AMP project dramatically improves the performance of mobile sites on the web, often to the point where their load appears to be instant. It’s an open-source initiative that relies on existing web technologies and is built in collaboration with many different partners.
Many technologies today come with super complicated build processes. But not so with AMP. An AMP page is just a normal HTML website with a couple of restrictions and extras.
No build process.
No extra step.
That’s done to ensure staying in the fast lane in two critical situations.
- First, it allows AMP JS to control the entire load chain and prioritize certain elements and requests over others. In practice, this means that most third-party content and elements below the fold, are loaded after the main content arrives. So your users can start reading as soon as possible.
- Second, AMP’s custom properties strictly require the width, height, or other aspect ratio defining attributes to be set. This way, AMP JS knows exactly how your page will look like before any assets are loaded, and can layout the page in advance. This prevents the famous flash of on-site content, the ugliness of a half-loaded website that then starts to jump around while loading more stuff, as well as the need to re-render and do additional layout calculations, a browser task that can be very slow.
Every single limitation or addition to AMP documents is carefully designed to AMP up the speed of the page to 11, and implement RAIL, a user experience-focused performance model that the Chrome team came up with and because AMP JS comes with a built-in validator that locks to the console, it ensures developers stay in a fast lane, as nothing is more frustrating than a speed regression you’re discovering months later.
On an AMP page, the content is always king.
And the user experience is queen.
But if you now say, wait a sec, sounds great for users, but how does this help publishers?
Users love fast content.
And AMP allows platforms like Google, Twitter, Pinterest, or LinkedIn to know for a fact that this content is fast, which they can then promise to users in return. If I know it only takes me five seconds to read that article,
I’d do it much more often with many more articles.
Users are happy.
The platforms are happy because users are happy.
And the publishers are happy because they get to show me more content.
And just like that, everybody wins.
Get started writing your first AMP page today directly to ampproject.org to learn more.