The speed of content delivery via mobile matters more every day. Competition extends beyond search engine results, to landing pages, and even deeper page engagement and conversions. Some would have you think speed is something that only an external force can fix. Facebook’s Instant Articles. Apple’s News format. Google’s AMP project. But what would you be willing to sacrifice to gain speed by implementing them?
The allure of AMP.
Accelerated Mobile Pages (AMP) is an open-source project by Google, whose stated purpose was to enable fast loading mobile pages. This is important to site owners—especially those who rely heavily on revenue generated from onsite advertising (publishers, news outlets) which can significantly slow mobile experiences. Many have speculated, however, that the unstated purpose of this project could be Google’s attempt to prevent ad revenue being driven away due to the rise of adblockers.
Some have also questioned the effect AMP may have on search engine results pages (SERPs). Will preferential treatment be given to pages that use Google’s format for these speedy mobile pages? Google assures us that, while speed is a factor in SERPs, AMP will be treated like any other content. But, should two similar results compete in all other factors and the AMP is faster, it will, in fact, outrank the other.
What you’ll potentially have to part with.
A simple, Google backed, solution to slow loading mobile content is very enticing. But what will you have to give up to make this happen through AMP implementation?
-
Your autonomy. By adopting this trend, content owners will become dependent on Google’s solution for a problem they already can solve themselves. Support, requirements, and cost for the AMP project may change and you’ll have no choice but to comply. AMP’s longevity resides entirely in its adoption, and while current reports sound optimistic, we all know how quickly the web can change. Especially with the growth in support of self sustained, all-in-one solutions like Progressive Web Applications.
-
Your code. You’ll need to use AMP HTML, AMP JS, and AMP Cache.
-
Your design. You’ll need to keep your CSS size under 50K, in some cases resort to using iFrames, and cut out dynamic content not supported by the proprietary code.
-
Your analytics. You’ll need to add AMP analytics in addition to any other analytic code you may be using on your non-AMP pages. Earlier this year, issues were reported in tracking unique visits, sessions, bounce rate, and other metrics. Until recently, the complete user journey from AMP to non-AMP pages was also a mystery, causing incomplete information for site owners.
Step back: what is causing the underlying problem?
At first glance, AMP seems like the way forward in an environment full of competitors, content, and weighted down sites. But what if instead of creating a new language that assumes certain mobile first standards, we build our sites to perform better on mobile to begin with?
Progressive Web Apps (PWAs) not only solve the issue of poor mobile performance, but they also use language we’re already familiar with, allow for the creation of beautiful user experiences, and maintain the separate, yet interconnectedness the web was built on. PWAs condense our growing site sizes, use less data, provide speeds rivaling—if not equal to—AMP, and are supported across browsers. All this plus push notifications, add to homescreen, and offline mode.
So, the answer to increased performance on mobile may not be a new, separate, and owned format for it, but perhaps one update that solves the problem across all platforms. If you’d like to learn more, we’d love to chat.
