larlet-fr-david-cache/cache/92bdb2bb826299c4eb5a002dcdd1e42e/index.md

title: Facebook and the media: united, they attack the web
url: https://www.baldurbjarnason.com/notes/media-websites-vs-facebook/
hash_url: 92bdb2bb826299c4eb5a002dcdd1e42e

<p>A few media websites have made a deal with Facebook to present their articles within Facebook’s iOS app instead of on their own websites. Apparently, it’s all the web’s fault.</p>

<p>Although, it should be mentioned that Instant Articles are published only on Facebook’s iOS app and degrade gracefully into links to the media site’s original website elsewhere, so it isn’t nearly the wholesale assimilation of everything everywhere that people present it to be.</p>

<p>Commentators online report this news alternately as armageddon or the second coming.</p>

<hr />

<h3 id="fear-and-loathing">Fear and loathing</h3>

<p>The first and most common reaction from the punditry is fear.</p>

<blockquote>
  <p>That’s not a privilege that Facebook, Google or anyone else should have. But with content creators surging en mass to wherever the viewers are, and the viewers looking for the best (and fastest-loading) content, it may be that it’s already too late to stop the process.</p>

  <p><em><a href="http://readwrite.com/2015/05/13/walled-gardens-of-the-web?utm_content=buffera726c&amp;utm_medium=social&amp;utm_source=twitter.com&amp;utm_campaign=buffer">The Walled Gardens Of The Web Are Growing</a> by David Nield (663 words).</em></p>
</blockquote>

<p>Egads. How worrying.</p>

<hr />

<h3 id="the-core-problem-advertising">The core problem: advertising</h3>

<blockquote>
  <p>Facebook is progressing on all these fronts: the company’s ad units are best-in-class, the targeting is frighteningly specific, and with its overhaul of Atlas the company is working to draw a line from Facebook ads to offline purchases. The vast majority of publishers, though, are in the opposite boat.</p>

  <p><em><a href="https://stratechery.com/2015/verizon-aol-facebook-instant-articles-and-the-future-of-digital-advertising/">Verizon-AOL, Facebook Instant Articles, and the Future of Digital Advertising</a> by Ben Thompson (2005 words).</em></p>
</blockquote>

<p>In short, Facebook is just better at mobile advertising and it’s getting better at it faster.</p>

<blockquote>
  <p>First, mobile display ads stink. Unlike a PC browser, which has a lot of space to display ads alongside content, content on mobile necessarily takes up the whole screen (and if it doesn’t, the user experience degrades significantly, making quality a casualty once again). This results in mobile ad rates that are a fraction of desktop ad rates (and remember, desktop ad rates are already a fraction of print ad rates)</p>

  <p>Second, on mobile, clicks are expensive from a user experience perspective. Not only do PCs typically have faster broadband connections to download assets and more powerful processors to render pages, they also have multiple windows and tabs. On a phone, on the other hand, clicking on a link means you can do nothing but wait for it to open, and open quite slowly at that. The cost of clicking a link, already quite high because of the deluge of crap content and particularly-annoying-on-mobile ads, is even higher because of the fundamental nature of the device.</p>

  <p><em><a href="https://stratechery.com/2015/facebook-reckoning/">The Facebook Reckoning</a> by Ben Thompson (2109 words).</em></p>
</blockquote>

<p>Ben isn’t the only one to say so.</p>

<blockquote>
  <p>For years publishers have struggled to successfully generate revenues from mobile ads, and there’s no reason to believe they’ll be any better at it if they sell their own ads for Instant Articles. It’s possible Facebook could generate a whole lot more revenue by selling the ads – and 70% of that larger number may wind up the better outcome for publishers.</p>

  <p><em><a href="http://blogs.wsj.com/cmo/2015/05/14/with-facebooks-instant-articles-publishers-may-find-70-cents-is-better-than-a-dollar/">With Facebook’s Instant Articles, Publishers May Find 70 Cents Is Better Than a Dollar</a> by Jack Marshall (916 words).</em></p>
</blockquote>

<p>Make no mistake <em>this</em> is the real problem that media websites are facing. The advertising product that is the foundation of their business model is failing on mobile phones.</p>

<p>But they aren’t blaming it on their ad targeting. They are blaming their strategic failure on the web.</p>

<hr />

<h3 id="they-say-the-web-is-dying">They say the web is dying</h3>

<p>It’s clear from the start that the web isn’t being held in a high regard by either party here.</p>

<p>As Nick Barreto found out:</p>

<blockquote>
  <p>Having a look at <a href="http://instantarticles.fb.com/">http://instantarticles.fb.com/</a>, and half the resources are PDFs.</p>

  <p>What is this, 1998? (<a href="https://twitter.com/nickbarreto/status/598809488066482176">@nickbarreto</a>)</p>
</blockquote>

<p>Apparently, the web is broken and slow despite the fact that the apps are using the same infrastructure and standards as the web. Guess how those Instant Articles are formatted? <code>HTML</code>. Guess how those articles get to the app? <code>HTTP</code>.</p>

<p>Those two techie terms should sound familiar to you.</p>

<blockquote>
  <p>Facebook is quite right when it says that most news sites load too slowly and look terrible, rendering the ads on those pages largely useless. Facebook, however, understands mobile like no one else: everything loads faster, looks nicer and is more appealing to advertisers, in part because Facebook can do the kind of targeting that newspapers aren’t equipped to do.</p>

  <p><em><a href="http://fortune.com/2015/05/13/facebook-new-york-times-instant/">Is Facebook a partner or a competitor for media companies? Yes.</a> by Mathew Ingram (1143 words).</em></p>
</blockquote>

<p>No. Facebook is more appealing to advertisers because of its targeting. If looking nice was the key here, <em>Snow Fall</em> would have delivered truckloads of money on the New York Times’ doorstep.</p>

<hr />

<p>Even the web’s old guard is worried. The web can’t compete. The web can’t compete. The web can’t compete. End times.</p>

<blockquote>
  <p>I’m intrigued by the emphasis on speed. Not only is native mobile code winning for app development, but with things like Instant Articles, native is making the browser-based web look like a relic even just for publishing articles. If I’m right about that, it might pose a problem even for my overwhelmingly-text work at Daring Fireball. Daring Fireball pages load fast, but the pages I link to often don’t. I worry that the inherent slowness of the web and ill-considered trend toward over-produced web design is going to start hurting traffic to DF.</p>

  <p><em><a href="http://daringfireball.net/2015/05/facebook_instant_articles">Facebook Introduces Instant Articles</a> by John Gruber (524 words).</em></p>
</blockquote>

<p>Actually, hang on. Gruber makes an excellent point mixed in with the web-blaming. I’m highlighting it here but I’m going to come back to it later (emphasis mine):</p>

<blockquote>
  <p>I worry that the inherent slowness of the web and <em>ill-considered trend toward over-produced web design</em> is going to start hurting traffic to DF.</p>
</blockquote>

<p>If you work for a large media company, pay attention to the italicised text. It’s where you’re failing.</p>

<p>It gets worse:</p>

<blockquote>
  <p>Not only is the web not fast enough for apps, it’s not fast enough for text either.</p>

  <p>And you know what, they’re right.</p>

  <p>Such a stance will be considered blasphemy in some circles. But it doesn’t change the very real and very obvious truth: on mobile, the web browser just isn’t cutting it.</p>

  <p>Yes, native apps have spoiled us. But such spoilage is natural. In the end, all that matters is user experience. Native apps provide a better user experience on mobile than a web browser. That was true five years ago, that’s true today. And I suspect it will still be true five years from now.</p>

  <p><em><a href="https://500ish.com/facebook-instant-karma-4a4bd4f3eca?gi=5cf41ca63561">Facebook Instant Karma</a> by M.G. Siegler (678 words).</em></p>
</blockquote>

<p>There’s just one problem with this. It’s completely untrue. Here’s an absolute fact that all of these reporters, columnists, and media pundits need to get into their heads:</p>

<p>The web doesn’t suck. Your websites suck.</p>

<p><em>All of your websites suck.</em></p>

<p>You destroy basic usability by hijacking the scrollbar. You take native functionality (scrolling, selection, links, loading) that is fast and efficient and you rewrite it with ‘cutting edge’ javascript toolkits and frameworks so that it is slow and buggy and broken. You balloon your websites with megabytes of cruft. You ignore best practices. You take something that works and is complementary to your business and turn it into a liability.</p>

<p>The lousy performance of your websites becomes a defensive moat around Facebook.</p>

<p>Of course, Facebook might still win even if you all had awesome websites, but you can’t even begin to compete with it until you fix the foundation of your business.</p>

<hr />

<h3 id="how-things-should-be">How things should be</h3>

<p>If your web developers are telling you that a website delivering hypertext and images can’t be just as fast as a native app (albeit behaving in different ways) then you should fire them.</p>

<p>Peter-Paul Koch, <a href="http://www.quirksmode.org/mobile/">web browser tester extraordinaire</a>, picks up on the phrase that I highlighted in the John Gruber quote and runs with it.</p>

<blockquote>
  <p>The web definitely has a speed problem due to over-design and the junkyard of tools people feel they have to include on every single web page. However, I don’t agree that the web has an inherent slowness. The articles for the new Facebook feature will be sent over exactly the same connection as web pages. However, the web versions of the articles have an extra layer of cruft attached to them, and that’s what makes the web slow to load. The speed problem is not inherent to the web; it’s a consequence of what passes for modern web development. Remove the cruft and we can compete again.</p>

  <p><em><a href="http://www.quirksmode.org/blog/archives/2015/05/tools_dont_solv.html">Tools don’t solve the web’s problems, they ARE the problem</a> by Peter-Paul Koch (841 words).</em></p>
</blockquote>

<p>The web is capable of impressive performance and offers a dramatically vaster reach and accessibility than anything an app can offer.</p>

<blockquote>
  <p>This is one reason why mobile web has to be part of every company’s strategy. When someone encounters a link via an email newsletter or shared via a social network, they should be able to view that link no matter where they are and no matter what device they are using.</p>

  <p><em><a href="http://blog.cloudfour.com/links-do-not-open-apps/">Links Don’t Open Apps</a> by Jason Grigsby (368 words).</em></p>
</blockquote>

<p>All it requires is discipline.</p>

<blockquote>
  <p>“Make everything on your page fight for its life, fight for its right to be there.” — <a href="https://twitter.com/brad_frost">@Brad_Frost</a> #aeabos (<a href="https://twitter.com/topdownjimmy/status/598498025892347905">@topdownjimmy</a>)</p>
</blockquote>

<p>This is a long-standing debate. Except it’s only long-standing among web developers. Columnists, managers, pundits, and journalists seem to have no interest in understanding the technical foundation of their livelihoods. Instead they are content with assuming that Facebook can somehow magically render <code>HTML</code> over <code>HTTP</code> faster than anybody else and there is nothing anybody can do to make their crap scroll-jacking websites faster. They buy into the myth that the web is incapable of delivering on its core capabilities: delivering hypertext and images quickly to a diverse and connected readership.</p>

<p>We continue to have this problem because your web developers are treating the web like an app platform when your very business <em>hinges</em> on it being a quick, lightweight media platform with a worldwide reach.</p>

<blockquote>
  <p>Stop me if you’ve heard this one before. You’re reading an article on Smashing Magazine or A List Apart or some other publication. The article is about a specific feature of CSS, or maybe JavaScript, or perhaps it’s exploring some of the newer additions to HTML. The article is good. It explains how to use this particular feature in your work. Then you read the comments. The first comment is inevitably from someone bemoaning the fact that they can’t use this feature because it isn’t supported in every browser. Specifically, it isn’t supported in some older version of Internet Explorer that they have to support. Therefore the entire article is rendered null and void.</p>

  <p>That attitude infuriates and depresses me. It seems to me that it demonstrates a fundamental mismatch between how that person views the job of web development and the way the web actually works.</p>

  <p><em><a href="https://adactio.com/journal/6692">Continuum</a> by Jeremy Keith (1128 words).</em></p>
</blockquote>

<p>Of course, Facebook is better at mobile advertising which, again, is the root problem facing media websites. Focus on that and stop blaming the web.</p>

<p>And web developers? Stop buying into the ‘native is better’ myth. (It’s just different.) Progressive enhancement has never been an optional extra and it’s high time you make sure that your managers and your CEOs know that.</p>

<p>It’s not a question whether everybody has javascript but a question of <a href="http://kryogenix.org/code/browser/everyonehasjs.html">javascript’s fundamental unreliability</a>.</p>

<p>Of course, it isn’t easy. That’s why you aren’t doing it.</p>

<blockquote>
  <p>Here’s the harsh truth: building websites with progressive enhancement is not convenient.</p>

  <p>Building a client-side web thang that requires JavaScript to work is convenient, especially if you’re using a framework like Angular or Ember. In fact, that’s the main selling point of those frameworks: developer convenience.</p>

  <p>The trade-off is that to get that level of developer convenience, you have to sacrifice the universal reach that the web provides, and limit your audience to the browsers that can run a pre-determined level of JavaScript. Many developers are quite willing to make that trade-off.</p>

  <p>Developer convenience is a very powerful and important force. I wish that progressive enhancement could provide the same level of developer convenience offered by Angular and Ember, but right now, it doesn’t. Instead, its benefits are focused on the end user, often at the expense of the developer.</p>

  <p>Personally, I’m willing to take that hit. I’ve always maintained that, given the choice between making something my problem, and making something the user’s problem, I’ll choose to make it my problem every time. But I absolutely understand the mindset of developers who choose otherwise.</p>

  <p><em><a href="https://adactio.com/journal/7706">Be progressive</a> by Jeremy Keith (1981 words).</em></p>
</blockquote>

<p>Your problem is that if you put your developers ahead of your customers, you’ll end up with just the developers. Facebook will have all of your customers because the sites your developers made suck.</p>

<p><a href="http://www.filamentgroup.com/lab/weight-wait.html">They can do much better. And we can do much better.</a></p>

<p>We <em>should</em> do better.</p>

<blockquote>
  <p>There’s this thought in my head that, like a broken record, keeps repeating to me and everyone around: “Stop breaking the web.” And if I think about it more, I realize it’s related to this fundamental idea that I have, which makes me want to push the web forward and make it a better place. Because isn’t that what we, the designers and developers of this medium, should strive for and be proud of?</p>

  <p><em><a href="http://viljamis.com/blog/2015/the-many-faces-of-the-web/">The Many Faces of The Web</a> by Viljami Salminen (811 words).</em></p>
</blockquote>

<p>Stop <em>blaming</em> the web. Stop <em>breaking</em> the web.</p>

<hr />

<h3 id="some-more-responses-to-the-news-updated-15-may-1330-bst">Some more responses to the news (Updated 15 May, 13:30 BST)</h3>

<p>Nate makes the same observation I did at the start of this post.</p>

<blockquote>
  <p>So this is the program which has been pontificated over, railed against, and dissected in (speculatory) detail over the last year?</p>

  <p>Color me underwhelmed.</p>

  <p><em><a href="http://the-digital-reader.com/2015/05/14/facebook-launches-instant-articles-im-still-waiting-for-the-other-shoe-to-drop/?utm_source=feedburner&amp;utm_medium=feed&amp;utm_campaign=Feed%3A+TheDigitalReader+%28Ink%2C+Bits%2C+%26+Pixels%29">Facebook Launches Instant Articles, &amp; I’m Still Waiting for the Other Shoe to Drop</a> by Nate Hoffelder (477 words).</em></p>
</blockquote>

<p>Om Malik demonstrates why people read GigaOm in the first place by bringing actual data to the table. He doesn’t seem to be aware of the web’s capabilities in terms of progressive enhancement or perceived performance, though. That’s okay. Most people these days don’t.</p>

<blockquote>
  <p>Whatever you might think about Facebook Instant Articles, they have refocused our attention on the importance of architecting apps and experiences with network performance and speed — something Google made us aware of 11 years.</p>

  <p><em><a href="http://om.co/2015/05/14/on-the-mobile-web-slow-speeds-kill/">On mobile, slow speeds kill</a> by Om Malik (850 words).</em></p>
</blockquote>

<p>Pete Davies asks the question the punditry should have asked. WTF are these media websites doing that takes so long?</p>

<blockquote>
  <p>WTF is taking 8 seconds?</p>

  <p>At the core of Facebook’s case is that the average article takes eight seconds to load. We’ve known forever that users don’t like slow loading pages. So why have publishers ignored this? Why did it take Facebook to take action? Is it all the Adware? Poorly optimized images? “Responsive” templates still loading full desktop code? “Personalization”?</p>

  <p><em><a href="https://medium.com/@pete/notes-on-facebook-instant-articles-9daf2a7b8a94">Notes on Facebook Instant Articles</a> by Pete Davies (726 words).</em></p>
</blockquote>

<p>And last but not least, Tim Kadlec writes the post I wish I had written about how this is a cultural problem, not a technical problem with the web itself.</p>

<p>If you are going to read just <em>one</em> of the posts I link to here, make it this one.</p>

<blockquote>
  <p>But this quote is really the best indicator of why the web is so slow at the moment. It’s not because of any sort of technical limitations. No, if a website is slow it’s because performance was not prioritized. It’s because when push came to shove, time and resources were spent on other features of a site and not on making sure that site loads quickly.</p>

  <p>This goes back to what many have been stating as of late: performance is a cultural problem.</p>

  <p><em><a href="http://timkadlec.com/2015/05/choosing-performance/">Choosing Performance</a> by Tim Kadlec (933 words).</em></p>
</blockquote>

<h3 id="what-if-everybody-else-did-this-as-well-second-update-16-may-1400-bst">What if everybody else did this as well? (Second update, 16 May, 14:00 BST)</h3>

<p>Danny Sullivan starts wondering what would happen if Google decided to do the same thing, host everything themselves. (Good question.)</p>

<blockquote>
  <p>Today, Facebook announced Instant Articles, a way for publishers to post stories directly on Facebook. We’ve known this would be coming, and there’s been some debate over whether it’s good or bad. But I haven’t seen that extended to what would happen if Google follows Facebook’s lead. It could, potentially causing the web to be swallowed up by two gatekeeping giants.</p>

  <p><em><a href="http://marketingland.com/facebook-instant-articles-slippery-slope-for-google-128596">Facebook Instant Articles: A Slippery Slope For Google To Do The Same, Hurting The Web?</a> by Danny Sullivan (935 words).</em></p>
</blockquote>

<hr />

<p>Jason Brennan counters the rhetoric that since apps use HTTP they are ‘webby’ by pointing out that it isn’t HTTP that makes the web ‘webby’. The mechanisms of the web are the links and connections from page to page, site to site, and you can easily use HTTP in an app without allowing any links or connections at all. In fact, most of them either don’t or do it very badly.</p>

<p>(His post is short. Well worth reading.)</p>

<blockquote>
  <p>What makes the web the web is the open connections between documents or “apps,” the fact that anybody can participate on a mostly-agreed-upon playing field.</p>

  <p><em><a href="http://nearthespeedoflight.com/article/2015_05_14_the_web_and_http">Speed of Light</a> by Jason Brennan (220 words).</em></p>
</blockquote>

<hr />

<h3 id="the-quartz-contrast-update-on-the-20th-of-may">The Quartz contrast (update on the 20th of May)</h3>

<p>The contrast between Quartz and the more traditional new media seems relevant.</p>

<blockquote>
  <p>When Quartz launched, we were careful not to call it a website. The ambition extended well beyond that; our domain on the web was merely its first iteration. This raised a few eyebrows from people who rightly pointed to our, uhh, website, and it required some contortions of language. Quartz is…a business news outlet…organization…venture…brand…</p>

  <p>Well, that’s all true, but if I had to pick one description, it would be this: Quartz is an API.</p>

  <p><em><a href="http://www.niemanlab.org/2015/05/quartz-is-an-api-the-path-ahead-for-the-business-site-thats-reshaping-digital-news/">“Quartz is an API”: The path ahead for the business site that’s reshaping digital news</a> by Zachary M. Seward (1601 words).</em></p>
</blockquote>

<p>And…</p>

<blockquote>
  <p>The last part of Seward’s statement above is the most important: instead of seeing all of the various formats or platforms that it uses as just a way of driving more clicks to a website, Quartz sees them as worthwhile in and of themselves. While the site’s content may not be monetized directly on that platform, it helps build the company’s brand and its knowledge about other platforms and social tools, which in turn allow it to monetize its content better on the Quartz site, which it does through native advertising.</p>

  <p><em><a href="http://fortune.com/2015/05/15/media-quartz-api/">More media companies need to think of themselves the way Quartz does</a> by Mathew Ingram (900 words).</em></p>
</blockquote>

<p>But the best analysis of the strategy surrounding Facebook Instant Articles comes from Thomas Baekdal.</p>

<blockquote>
  <p>Turning this into a Facebook Instant Article doesn’t really change that. Just because an article loads faster and looks prettier once people have already clicked on it, doesn’t mean more people will see it.</p>

  <p>People still have to decide that they want to click on it. Your lack of reach isn’t caused by what happens after people click on a post. It’s caused by the decision that happened before people clicked.</p>

  <p><em><a href="https://www.baekdal.com/analysis/the-thing-about-facebook-instant-articles/">Strategic analysis The Thing About Facebook Instant Articles</a> by Thomas Baekdal (3804 words).</em></p>
</blockquote>

<p>In the end, none of the technological issues matter. You can’t design away a fundamental conflict between user experience and business model:</p>

<blockquote>
  <p>My least favorite online game these days: finding the “X” that closes the nearly ubiquitous website popup for newsletter signup or video ad. (<a href="https://twitter.com/jkottke/status/600325321217470465">@jkottke</a>)</p>
</blockquote>

<p>Perhaps that needs to change.</p>

<blockquote>
  <p>I do think publishers can still compete for very small niche audiences, where creating a high-trust network of participating recommenders and public content creators is hard, or at least harder. They can do this because the number of real experts in these fields is small, and they can hire enough of them to become the hub of informed discussion.</p>

  <p><em><a href="https://medium.com/@e/easier-said-than-done-when-every-url-is-one-click-away-the-content-package-is-dead-421210007a38">Easier said than done. When every URL is one click away, the content package is dead.</a> by Evan Hansen (431 words).</em></p>
</blockquote>