Google amp feb 24, 2016

http://mediagazer.com/160224/p4#a160224p4

http://mediagazer.com/160223/p28#a160223p28

Publishers are dumb. Publishers create terrible websites. Publishers need Facebook and Google to save them.

A lot of moronic rhetoric will exist about this topic.

http://www.wsj.com/articles/google-starts-including-amp-content-in-mobile-search-results-1456326159

“The feedback from publishers so far has been very enthusiastic. Everyone is excited to make the Web faster,” said Dave Besbris, Google’s vice president of engineering.

The Web or the web is not slow. Browsers on desktops, laptops, tablets, and phones are not the problem.

Bloated, poorly designed websites are the problem. And publishers create them. These stunningly huge article pages bog down old computers and cause slow downloads.

The solution is to create simpler websites. My test site that's using my new formatting app to create static html pages loads fast and works fine on desktop and phone. http://article.soupmode.com/static

My other sites, such as http://maketoledo.com and http://crochet.soupmode.com/, also load fast because the Nginx web server pulls the homepages and the article pages from Memcached. And if the article page was not cached, then my code is accessed, which pulls the content from the MySQL or CouchDB database, and then the content is cached before or after it's sent to the user. A refresh retrieves the newly cached page. But when I create or update an article, that page is cached. Other stream views, such as page 2 and on and search results, are not cached.

Make the web faster? No. Make your websites leaner. Make your websites reader-friendly instead of reader-hostile.

Popular blogging platform and content management system WordPress is also supporting the initiative, potentially adding AMP versions of content to millions of websites using WordPress software.

Is that because Wordpress sites pull content from a database every time an article page is accessed? Memcached and Redis are simple to implement and use. Does every article page need to contain dynamic elements? The answer is probably 'Yes', especially for all the tracking, advertising, and analytics crap that users must download.

“We want to make it really easy for publishers of all shapes and sizes to publish AMP-formatted pages, from the New York Post all the way down to people running their own personal blogs,” said Paul Maiorana, vice president of platform services at WordPress.com parent company Automattic.

Why not create simple, fast-loading, reader-friendly pages by default?

Under the hood, AMP works by simplifying and streamlining the HTML code that powers Web pages to prioritize speed. Google also “caches” pages, or saves copies of them on its own systems, in order to deliver them quicker when users access them. It’s an open-source initiative, meaning anyone is free to use it.

Again, content producers on their own can create simple HTML pages, and they can cache their own content for faster access, thus creating a reader-friendly experience.

This is bizarre. Great for Google, but it's bizarre that web site owners created this mess.

“This really is the Web ecosystem. That means the publishers get a choice of a wide variety of tech solutions including analytics solutions and ad providers,” Mr. Besbris said.

That's not the web. That's monetization or business.

Google’s AMP initiative is just one of many content delivery options now available to online publishers. Facebook, for example, recently launched its own Instant Articles product, which enables publishers to host content directly with the social network instead of driving users back to their own websites. Part of the sales pitch for Instant Articles was that news stories would load faster on mobile devices.

The difference with AMP pages, however, is that publishers host the content themselves, with Google saving or “caching” AMP pages temporarily to speed up their loading times.

Because of this distinction, some publishers say they are less leery of Google’s approach.

“I think of it as very different arrangement to Facebook Instant Articles. We feel much more in control of the content because of the fact this is hosted on our servers and our business model travels with it,” said Kate Harris, a mobile product director at the New York Times.

http://www.niemanlab.org/2016/02/diving-all-in-or-dipping-a-toe-how-publishers-are-approaching-googles-accelerated-mobile-pages-initiative/

Wow. The amount of idiotic thinking is staggering.

“Mobile web performance is bad — I challenge you find someone who disagrees with that,” Mic’s chief strategy officer Cory Haik told me.

I would vehemently disagree. The mobile web performance is not bad. Your obnoxiously bloated and clunky website is bad. You create a reader-hostile experience and then blame something else.

“When our pages load too slowly on mobile, as a publisher, we’re losing an audience, and that is painful. So we’ve been excited to build on AMP.”

That's hilarious.

Unlike its platform-specific counterpart Facebook Instant Articles, Google’s AMP initiative applies to the open web.

Speed ...

Diving all in or dipping a toe? How publishers are approaching Google’s Accelerated Mobile Pages initiative
“Everything we know about building a webpage, we have to relearn. But we’re relearning it from the premise of converting a current product over, not creating a product from scratch.”
By Shan Wang @shansquared Feb. 24, 2016, 10:48 a.m.

google-amp-project
RELATED ARTICLE
Get AMP’d: Here’s what publishers need to know about Google’s new plan to speed up your website
October 7, 2015
“Mobile web performance is bad — I challenge you find someone who disagrees with that,” Mic’s chief strategy officer Cory Haik told me. “When our pages load too slowly on mobile, as a publisher, we’re losing an audience, and that is painful. So we’ve been excited to build on AMP.”

Google’s AMP initiative — Accelerated Mobile Pages — officially launches today with the goal of getting the mobile web to that wonderful place where all “publishers can create mobile optimized content once and have it load instantly everywhere.” Unlike its platform-specific counterpart Facebook Instant Articles, Google’s AMP initiative applies to the open web and will rely on participating publishers and technologists to contribute (non-proprietary) code of their own to get AMP pages to a place where they reflect the fullness of the “regular” web. (Read more about some of the technical details around AMP HTML from the time of its announcement last fall here; Search Engine Land has a good quick summary today here.)

What kind of speed improvements does AMP deliver? Here’s one example: This desktop version of a New York Times story gets to domContentLoaded — a key point in a webpage’s load where the HTML is fully downloaded and certain important parsing has been completed — to 0.985 seconds and loads fully in 3.82 seconds. (That’s in a test in Chrome on a fast iMac.)

The mobile version of that page gets to domContentLoaded in 0.857 seconds and is fully loaded at 2.99 seconds.

The AMP version of that same webpage — note the .amp.html in the url — reaches domContentLoaded in 0.240 seconds and loads fully in 0.646 seconds.

Development ...

So how are newsrooms adjusting to what is, on one hand, a chance to speed up their mobile presence but, on the other, a mandate to develop and maintain another version of all their stories? I reached out to a number of them and found a variety of responses — some all in, some testing the waters, and some unwilling (or unable) to commit the necessary developer resources.

A number of newsrooms I reached out to declined to speak for attribution, but cited “limited resources” and “different priorities” as reasons for not pursuing AMP for now.

“The most challenging task in our case has been the implementation of the paywall issues, because our system is totally based in JavaScript, which is not supported by AMP,” Folha de S.Paulo assistant managing editor Roberto Dias told me.

The ToledoBlade.com could benefit from using AMP.

More jocularity: