diff options
author | luxagraf <sng@luxagraf.net> | 2016-05-18 20:57:44 -0400 |
---|---|---|
committer | luxagraf <sng@luxagraf.net> | 2016-05-18 20:57:44 -0400 |
commit | c1175bb131f5b9bf89399735e896a9bb8fb1cb9d (patch) | |
tree | 50ed1888bda3bbe2506ee0b98cbb966abff85f3d | |
parent | 56b82089bc586e566e89e39e96d4c43d04ee8613 (diff) |
changed open source insider to be standardize instant articles piece
-rw-r--r-- | invoices/scott_gilbertson_invoice_79.doc | bin | 13824 -> 14848 bytes | |||
-rw-r--r-- | standardize-instant-articles.txt (renamed from open-source-insider-02.txt) | 13 |
2 files changed, 8 insertions, 5 deletions
diff --git a/invoices/scott_gilbertson_invoice_79.doc b/invoices/scott_gilbertson_invoice_79.doc Binary files differindex f61e1b6..6b355dd 100644 --- a/invoices/scott_gilbertson_invoice_79.doc +++ b/invoices/scott_gilbertson_invoice_79.doc diff --git a/open-source-insider-02.txt b/standardize-instant-articles.txt index bedbe37..aef8abd 100644 --- a/open-source-insider-02.txt +++ b/standardize-instant-articles.txt @@ -8,6 +8,8 @@ Aside from a few platform specific details -- all three want media like image or Somewhere along the way publishers and web developers lost sight of performance as a feature. Google and Facebook know that performance is a feature and they're both great at providing users with fast experiences, until they have to hand their users some page with 35 JavaScript libraries and images designed to look good on the 8K monitors no one actually has. +Instant Articles and AMP pages strip out all the JavaScript, kill the animations, prohibit the ubiquitous "sign up for my newsletter" overlay pop ups and deliver, well, the actual content readers come to read. And it turns out, without all the fluff no one wants, web pages load very quickly. + However, with a couple of exceptions, most notably the use of a content distribution network to cache pages, there's nothing in Google's AMP spec or Facebook's Instant Article feeds that publishers can't do for themselves. Except that they aren't doing it for themselves, so Google and Facebook have taken matters into their own hands, offering the promise of their content hungry audiences in exchange for less encumbered content. So what do publishers get out of reformatting their content to suit Google and Facebook? Nothing directly. What Instant Articles and Google AMP pages provide is verification for themselves. Google knows that an AMP page will be fast because -- assuming it's validly formated -- it can't not be fast. Ditto properly formatted Instant Article content. Performance is the whole goal of both efforts and performance is built into the requirement of the format. @@ -20,15 +22,16 @@ That's the goal behind a proposed web standard known as Content Performance Poli Yes, another standard to save us from a quagmire of competing quasi-standards. But none of the other solutions are actually standards. -The Content Performance Policy proposal is a long way from being an actual standard, but the brainchild of web developers Tim Kadlec and Yoav Weiss wants to <a href="https://timkadlec.com/2016/02/a-standardized-alternative-to-amp/">give developers</a> a "standardized way to provide similar verification [to what AMP offers]. Something that would avoid forcing developers into the use of a specific tool and the taste of 'walled-garden' that comes with it." +To be fair, the Content Performance Policy proposal is a long way from being an actual standard too, but the brainchild of web developers Tim Kadlec and Yoav Weiss wants to <a href="https://timkadlec.com/2016/02/a-standardized-alternative-to-amp/">give developers</a> a "standardized way to provide similar verification [to what AMP offers]. Something that would avoid forcing developers into the use of a specific tool and the taste of 'walled-garden' that comes with it." The <a href="http://wicg.github.io/ContentPerformancePolicy/">proposed spec</a> lists a variety of optimizations sites could use to speed up their content, including delayed image loading, throttling CPU consumption, no auto-play of audio and video content, and no external scripts among other things. -In short, it standardized current best practices for creating high performance websites. - But since publishers and site owners aren't actually following those best practices, the standard helps to define an alternative set of content. Which is to say that a publisher would do with the CPP formatted page exactly what it does now with Google AMP pages, publish them alongside their regular, bloated content. -User-agents would then be able to chose which content to display. This is helpful for user-agents that will pull content into other sites. For example Facebook when it includes articles in its timeline or Google's carousel. But it would also allow, for example, mobile browsers on a limited-bandwidth connection to do the same thing. +In short, it standardized current best practices for creating high performance websites. Google and Facebook would still get all the benefits their homegrown solutions offer -- namely, a guarantee that the page in question will load quickly -- but so would every other content consuming party on the web. + +User-agents would then be able to chose which content to display. This is helpful for user-agents that will pull content into other sites. For example Facebook when it includes articles in its timeline or Google's carousel. But it would also allow, for example, mobile browsers on a limited-bandwidth connection to do the same thing. Rather than the ad blocker that iOS currently employs, users could simply check a box to "prefer faster pages" when sites make a CPP page available. In fact, from a user point of view it's hard to imagine a scenario in which the faster loading, less cluttered content that CPP pages envision would not be preferable. -It might also end up being that carrot that convinces publishers to come back around to building faster websites. If the vast majority of traffic is going to the optimized version of a site while the festooned version sits virtually unused perhaps publishers will finally come around. Without a standardized way to do that publishers remain at the mercy of the walled gardens. +It's not just user agents though. This might also end up being that carrot that convinces publishers to come back around to building faster websites. +If the vast majority of traffic is going to the optimized version of a site while the festooned version sits virtually unused perhaps publishers will finally come around. Without a standardized way to do that publishers remain at the mercy of the walled gardens. |