If you haven’t heard, Facebook’s often-criticized Instant Articles service recently received an update to support publishing to Accelerated Mobile Pages (AMP for brevity) and Apple News (still not supported as of the publishing of this article) all at once. At first glance this seems like big news—Facebook is one of the big three mobile content delivery platforms—this will obviously push some traffic to its competitors’ services. So when a colleague sent Facebook’s announcement my way, it prompted me to consider why Facebook would do this. After some research, I’ve come up with some thoughts on the topic.
A Brief History of the Mobile Web
For the unacquainted, let’s start with some background on the mobile content space and how we got where we are. Back in the day (think ‘90s-early 2000s), websites had one size. Fixed-widths ruled all and since the smallest devices were laptops, web developers didn’t have to worry about device width. But then the iPhone was introduced, and it became evident that the times they are a changin’. [Steve Jobs Deal With it Gif] It’s difficult to overemphasize just how much mobile devices flipped the web upside-down despite huge hurdles. Users relied on devices that ran on EDGE network speeds, downloading Flash-heavy content on 3.5” screens, which the user then pinch-zoomed to navigate a page that may or may not work enough to perform tasks. Yet mobile traffic continued to explode, and within ten years it would overtake desktop web traffic worldwide. Throughout that ten-year period, advancements in both hardware and web technologies have brought a snappy, more natural experience to the mobile web. Sites that once took ten seconds or more to load, now did so in less than a second—even with increased video, image, and dynamic content. Perhaps unsurprisingly, with every advancement in speed, users were less willing to wait for the same page load times they once had considered blazingly-fast.
M.Website.Com vs Technology (HD DVD vs. Blu-ray)
It’s easy to become defensive of a technology with little more reason than “it’s what we’ve always used.” History has taught us that refusing to give new technologies a chance because they’re unfamiliar just won’t do. The advancement of technology continues at a steady march, and it does so without regard to our comfort—it’s up to us to keep pace.
If you’re old enough to remember, you’ll recall watching movies on VHS tape and never really thinking that we needed a change in video formats. My family had a not-so-small library of VHS tapes and I loved looking through them on Saturday mornings, as if I hadn’t already seen each of them at least five times. When DVDs became popular in 1996, I couldn’t fathom why people would shell out hundreds of dollars for a new DVD player and rebuild their movie library shelf by shelf—especially when VHS did the *exact same thing* as DVD. Sure, every now and then you’d have to adjust the tracking on the VCR to get those lines off the screen, but auto-tracking solved that. Blockbuster also reminded us constantly to rewind our movies (were you kind?), but that wasn’t an issue after my dad came home with a fast tape rewinder shaped like a race car which cut our rewind time down to mere seconds. Like me, you may remember your first experience watching a DVD and experiencing the difference in person. In my case, I was at a friend’s house, and the movie was The Matrix. I had watched it several times on VHS during my five-day Blockbuster rental. When my friend put in the DVD and we waited for the disc to load, I made a few comments about the technology being a fad that would pass. Then the menu loaded, Keanu Reeves started doing wall flips across the screen, and I immediately realized my folly. The difference was night and day—my local thrift store soon received a large donation of VHS tapes.
The Responsive Revolution
Back to the web. If you were to guess, you’d probably credit responsive design as the most notable evolution in the mobile web—and I’d agree with you. Giving credit to the generic term “responsive” is overly simplistic, when the reality is that it took the combined advancements in HTML, CSS, Javascript, and browser technology (to name just a handful) to make the responsive web possible. Responsive or “mobile first” design helped solve a problem from which mobile sites had suffered—unification of content and user experience on a mobile and desktop device. A contemporary of early responsive design, the mobile-specific site (m.* subdomain), utilized a separate theme and sometimes even an entirely separate codebase to limit what was being served to mobile devices. While it was sometimes necessary for developers that couldn’t offer a certain feature for mobile devices (such as Flash), it was a regular frustration to find a page from a Google search, tap on it, and then be redirected to the mobile site’s homepage because the page didn’t exist on the mobile site. I regularly found myself setting the browser user agent to desktop to try to avoid getting mobile sites. As is the case with technology in general, when an issue is encountered, a corresponding solution is introduced; in this case, the solution was responsive design. Within a couple of years, sites were being built from the ground up with the mobile user in mind, effectively making mobile-specific sites a thing of the past.
Enter the Competition
So now, after only being widely adopted for a couple years, the responsive web is facing its first big test: content delivery that is both mobile- and platform-specific. Within a short time, Google, Apple, and Facebook have introduced competing options for users to consume content on mobile devices. Aside from Apple News (which is a dedicated News app), users won’t be able to opt out from these new technologies. When available, Facebook Instant Articles are served automatically within the Facebook App. Google’s AMP content, which is an open source technology, is prominently displayed in search results and is also a default for mobile users regardless of browser (there is currently a link to allow users to leave the AMP page and use the canonical page instead, but I wouldn’t be surprised if AMP hides this by default in the near future). As these platforms are able to drive adoption, it’s likely that they will become less optional. The incentive for consumers is simple and often accurate: accessing content via one of these technologies can be faster. The incentive for publishers, which hasn’t been so cut and dry, is a higher rate of engagement, higher advertising revenue, and ease of implementation compared to a complete mobile performance overhaul.
As mentioned, Google already provides a separate slider for AMP pages in search results. Facebook has also just announced that site load speed will be included in its news feed ranking. What better way for Facebook to drive adoption and show publishers that their investment is worthwhile than to ensure that Instant Articles are among the top ranked? If I’m coming across as being a bit paranoid, it’s because I am (whether warranted or not). It’s not that page speed is a factor in search rankings, that was inevitable. It’s that the company providing the rank and results (Facebook) is ensuring that content which utilizes its platform (Instant Articles) benefits the most from this ranking change. Facebook can drive higher user adoption, which will encourage publishers to adopt Instant Articles, providing more ad revenue to Facebook, and (more importantly) keep users within Facebook’s ecosystem.
The Test for Responsive Sites
This brings me back to the Instant Articles announcement. Facebook is introducing a feature into its proprietary content delivery tool which allows developers and publishers to publish to its competition, and I don’t think Facebook is concerned about it. I doubt it’s because Facebook is confident that Instant Articles can provide a better experience or more features than responsive sites, AMP, or Apple News, because it doesn’t. As an example, AMP offers site menu navigation, ecommerce integration, and form support (in fact, AMP is becoming a full mobile site replacement—an article for another day). In contrast, Facebook doesn’t really want a user to stay on a publisher’s site indefinitely. It would rather users read an article within Instant Articles, visit the publisher’s Facebook Page, and share and interact with it directly on the user’s activity feed. Facebook is the master of making sure that a user doesn’t focus on any particular thing for too long—its news feed is designed to hold attention by dropping in content, not necessarily because it’s relevant, but because it’s overwhelmingly engaging. So it’s my opinion that Facebook doesn’t plan to compete based on features, but like many of its other tools, by preventing competition. Much like a windowless, clockless, maze-laden casino, Facebook welcomes users and does as much as possible to keep them from leaving. So yes, I believe that Facebook will happily increase its list of publishers by allowing them to create AMP and Apple News articles, as long as Facebook’s 2 billion and growing users never actually see them for the massive amounts of time that they spend on Facebook each day.
When these technologies were introduced, my original thought was that instead of adopting platforms that strip out code, we should just write good code (I still think that, by the way). If a feature is worth building, then it’s worth building well and making it available to all traffic (mobile being the majority anyway), rather than stripping it out for mobile. The same goes for platform-specific content—if a platform offers something that a browser cannot, a native app for example, then I think it makes sense to build it. But I’m not yet persuaded that distributing content to platforms like Facebook makes sense unless there’s a clear business requirement that also accounts for losing traffic to another site.
The test for responsive sites goes beyond being as fast, feature-filled, and convenient as AMP, Instant Articles, and Apple News. In part, it involves whether traffic gets to the site in the first place. Services like Facebook will continue to test the limits of keeping users within their platform. And to the extent that those efforts are successful, publishers will integrate with their technologies to get a chunk of that user engagement. Finally, as users and publishers get on board, those platforms will be able to make it more difficult to view canonical content, effectively closing the loop (think of how difficult it is to share content from within Facebook outside of Facebook). I’m aware that this is a gloomy view of the web and I recognize that I’m in danger of not embracing change. Regardless of what it may look like on the other side, I’m confident that the open web, which has endured the app revolution and undergone several iterations already, will endure this new test, evolving to meet the needs of users and publishers alike.
Additional Resources
Beyond the .Com: Drupal’s New Role in Large Enterprise | Drupalcon Presentation
Ramping up the AMP Module in Drupal 8 | Mediacurrent Blog
AMP’lify your Website: Google AMP 101 | Mediacurrent Blog
