It wasn’t long ago we were witnessing a cosmic shift in web development to accommodate the influx of computational powerhouse smartphones chugging through at-the-time bloatful websites. Those sites back in the mid-2000s were getting chunky with all the 2.0 insanity, and while the iPhone (in its release year of 2007) could render these sites on its 3.5” screen, it still wasn’t a great way to experience web pages. While most websites did have mobile versions of their core, desktop-friendly sites, they were woefully under-designed and lacked modern features to harbor modern conveniences (like ecommerce and rich media).
In the transitional years from the early smartphone era to now, sites tried finding a middle ground in design between too mobile-friendly (stripped down and hardly functioning) and too desktop-reliant (don’t just design sites for a large screen and tons of Internet bandwidth). This middle ground ended up becoming “responsive design”, an approach to web development that attempted to streamline page weight (for mobile) but have the flexibility of displaying the same amount of content, and typically loading the same number of scripts, across device screen sizes. For most circumstances, this was the right path to take. It wasn’t a mobile vs desktop world we were heading towards; it was a mobility world we had already entered, where the only thing that really differentiated access to websites and apps was the size of the screen and the interface accessibly (finger touch vs mouse click).
Unfortunately for everybody, this was (perhaps unintentionally) interpreted by developers that they no longer had to worry about page loading, script-rendering, and other complexities in web design contributing to page speed because an iPhone was just as powerful as your everyday, off-the-shelf laptop. Oh, and don’t mind the increasing complexity of ad networks and the growing inundation of ad placements and tracking scripts to load — any smartphone can handle those, too.
Except that this shift has left the web wounded. Everything seems to take longer to load, websites break easily, taps on mobile don’t register sometimes, and register other times, and so on and so on. I’ve written about site speed and performance before. It’s a growing problem. So much of a problem that the tech titans have taken note. Facebook attempted to remedy this and save the publishing industry by pushing hard on its Instant Articles initiative, a closed-garden approach to offering publishers a speedy alternative to their own laggard websites’ article templates and Facebook-sized reach. Apple built-in an iOS app called ‘News’, offering its take on the age-old RSS feed readers, but layering on pretty templates that were fast. And Google, the all-mighty search behemoth and purveyor of results that include the news, has aggressively pushed publishers, retailers, and websites of all kinds towards its Accelerated Mobile Pages (AMP) initiative, which is essentially an open source project encouraging the creation of streamlined HTML pages to reduce clutter and external JavaScript but while also running Google-only JavaScript and reassuring full reader analytics.
So How are Things Going?
Two years later, Instant Articles don’t seem to be working out as planned, as The Verge contemptuously bemoans:
But it's unclear if any huge advantage ever materialized. Facebook decided from the start that publishing a story using the Instant Articles format would not automatically improve its ranking in the News Feed. In practice, Instant Articles typically do reach more people, because people are more likely to read and share them. But as the format spread, competition increased, and any advantage to using Instant Articles was blunted within months. Given that Instant Articles were designed to carry less advertising than mobile web articles, broad reach was essential to ensure publishers would profit from the format. The reach just never arrived.
Apple’s ‘News’ app was initially off to a rocky start) in usage, but not much has been reported since. While arguments have risen about Apple’s role of gatekeeper in the news ecosystem, it seems that most publishers have welcomed it as an easy secondary publishing platform that permits a “bring your own advertising” model and subscription service options that are hard to ignore.
But what about Google. Google’s AMP project is more controversial than both Facebook and Apple’s forays, as it threatens web development integrity on the open web. A rant from The Register describes the plight as thus:
Announced in 2015, duly open sourced and integrated into Google’s mobile search, Google has pitched AMP as a way to speed the mobile web. It employs something the ads slinger calls AMP HTML that the firm describes as a “new open framework built entirely out of existing web technologies.”
What it is, is a way for Google to obfuscate your website, usurp your content and remove any lingering notions of personal credibility from the web.
If that appeals to you, here's what you need to do. First, get rid of all your HTML and render your content in a subset of HTML that Google has approved along with a few tags it invented. Because what do those pesky standards boards know? Trust Google, it knows what it's doing. And if you don't, consider yourself not part of the future of search results.
Sure, you might say: making the web faster is a noble vision. And yes, we unanimously agree, a faster web is better. But as the Register points out, “as with anything that eschews standards for its own modified version thereof, it's about lock-in. Tons of pages in Google AMP markup mean tons of pages that are optimized specifically for Google and indexed primarily by Google and shown primarily to Google users.” AMP is primarily a way for Google to combat lock-in systems from Facebook and Apple. The tech giants want everybody’s attention. But if you have an app feeding off standards (like Apple News), there isn’t a threat to disrupting the entire Internet’s web standards and rallying them around a controlled framework. We all want the Internet to be decentralized, right? Then you have to look at adopting AMP as an opposite way to do that. AMP is a choice for [Google search] inclusion, and there are monetary and attention-capturing benefits to doing so for brands and publishers. But forking your web development to accommodate a tech company’s recommended framework, a framework that is favored by that tech company’s mysterious organic algorithm for surfacing news results, is something else entirely. We’ve already seen what reckless strains of SEO has done to the web. Let’s not repeat those mistakes with reckless adoption of Google’s AMP HTML framework.
AMP also is a branding nightmare. Tapping a link from Google search results (again, the only way to access these versions of canonical pages) loads the page from Google's cached AMP index nearly instantaneously. Sharing that page simply shares the Google cached URL of the article, and trying to read more from that author/publisher is a frustration in interaction design -- the permalink button to go to the brand's actual domain is an unintuitive icon, and branding itself is obfuscated by the AMP framework's content-first philosophy. So what's in it for brands aside from handing over the keys to Google, and continuing to strain their own websites' development with the same shitty inundation of scripts, ad networks, unfriendly mobile paradigms, and page speed performance?
This debate has only just begun. But several of the Internet’s finest warriors are working on alternative solutions. The first of this anti-AMP movement is brought to you by a thoughtful fuck you project by Pinboard’s founder, Maciej Ceglowski. He basically re-created Google’s original AMP demonstration page without any of the forced Google scripts, and it represents the same performance. Maybe if we encouraged web developers to focus on leaner, cleaner designs (melding the pre-iPhone days with a more careful post-iPhone responsive design mantra) we could get to a better place for everyone. I’ll leave you with Ceglowski’s snarky comment at the bottom of his faux-AMP demo site:
Dozens of publishers and technology companies have come together to create this unfortunate initiative. However, it is 2015, and websites should be small and fast enough to render on mobile devices rapidly using minimal resources. The only reason they are not is because we are addicted to tracking, surveillance, gratuitous animation, and bloated, inefficient frameworks. Requiring a readable version of these sites is a great idea. Let's take it one step further and make it the only version.
Update: May 25, 2017
A mildly-related update here from TechCrunch on Facebook's plans for support for Google AMP and Apple News. Essentially they're trying to make it easier (and their own solution interoperable between competing formats) for publishers to more easily manage these specially-formatted content distribution channels. This comes in the form of an Instant Articles SDK (software development kit), enabling developers to "take the markup that’s used to build Facebook’s Instant Articles and use it to create the code that’s needed to build for AMP and Apple News." Note that Facebook would prefer you start with content distribution and formatting within its ecosystem, and use the Instant Articles SDK to output to competitor ones.
TechCrunch points out:
[T]he extension’s launch also comes at a time when a number of high-profile publishers have begun to abandon Facebook’s format, due to its lack of monetization options.
In April, for example, it was reported that Forbes, Hearst, The New York Times and others have backed out of Instant Articles. Other major media organizations including Bloomberg, The WSJ, ESPN, CBS News, NPR, Financial Times, and VICE News have also been holdouts, running little to no content in Facebook’s format. Others who have used the format have been winding down their support; and last month, The Guardian pulled out of both Facebook’s Instant Articles and Apple News.