Google AMP News - 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.
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:
“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. It’s a fairly complex process!” he added. “But we’re no different than anyone else in the industry. We’ve been having discussions around page weight and page optimization, in depth, for about six months.
Maybe a side effect of publishers exploring and using AMP is that publishers and new site owners will create simple web pages by default. Maybe these site owners will finally realize that they have been destroying the web for the past several years with single article pages that are 5 to 10 megabytes in size. Maybe these site owners will have empathy for the readers.
Some tweets by https://twitter.com/aschweig
"hey so you know how all these large publishers are struggling to implement AMP? some have entire teams dedicated to it."
"Seeing a lot of people just throwing up their hands about website performance generally, conceding it as a battle already lost."
Seeing things like Google AMP as the last best solution to the performance and privacy disaster that news orgs created for themselves... …stikes me as a little too defeatist and also puts too many eggs in two few baskets. Which... …is how publishers got themselves into this mess in the first place. (by being too reliant on ad dollars and effectively selling readers out
http://searchengineland.com/live-google-launches-amp-results-in-mobile-search-results-243147
https://medium.com/readme-mic/mic-s-open-source-amp-integration-2ceca1cb3213#.srnits9h8
https://github.com/ampproject/amphtml
http://searchengineland.com/get-started-accelerated-mobile-pages-amp-240688
To view the demo for Accelerated Mobile Pages in Search, open this link on your mobile device. http://g.co/amp
http://fortune.com/2016/02/24/google-amp-search/
http://github.com/Automattic/amp-wp
http://www.theguardian.com/membership/2016/feb/24/todays-release-of-accelerated-mobile-pages-amp
http://www.editorandpublisher.com/news/news-publishers-are-going-all-in-on-googles-amp/
https://backchannel.com/google-is-going-to-speed-up-the-web-is-this-good-a92a6043598b#.btthbzw7l
“Sluggish” is too tame a word for what we endure now, due to an accumulation of terrible news-industry design and business choices in recent years.
Hey, another person who knows where the blame lies. Gilmore launched the Bayosphere community site early to mid last decade, but he scrapped it too soon, giving it only a year or so to grow. I don't always agree with Gilmore's views on media, but on this topic, I agree. Gilmore wrote:
Before getting into details about what’s happening here, let’s be clear on something. AMP wouldn’t be necessary — assuming it is in the first place — if the news industry hadn’t so thoroughly poisoned its own nest.
Boom. Bingo. Exclamation point!
More brilliance from Gilmore, although this is what I have been thinking for a long time too:
Looking for money in a business that grows more financially troubled by the month, media companies have infested articles with garbage code, much of it on behalf of advertising/surveillance companies, to the extent that readers have quite reasonably rebelled.We don’t like slow-responding sites, period.
On our mobile devices, which are taking over as the way we “consume” information, we despise having to download megabytes of crapware just to read something, because the carriers charge us for the privilege.
That’s one reason why we use ad blockers. (The other, at least for me, is that we despise being spied on so relentlessly.)
The news business could have solved this problem without racing into the arms of giant, centralized tech companies. But it didn’t, and here we are.
Yet that verge.com article from last summer blamed all of the above on mobile web browsers.
Google’s surveillance-dependent business model should give us all pause, but it does have a stake in maintaining an open web, or at least a web open enough for its own, search-advertising business to continue to thrive. To the extent that the competition can capture the advertising that flows into its version of the Internet, the demise of an open web is a clear and present danger to Google.Google, as noted, is no shrinking violet. And a big incentive for news organizations to participate in AMP is to satisfy their AMP “general partner” (my expression, not Google’s) on another front — better placement on Google’s search results. Google’s bread and butter is the ads it can sell based on search, and the company has made clear its intention to rank loading speed high in how it calculates search results. Google insists it won’t favor sites using AMP just because they’re serving up AMP pages, but that may become a distinction with little difference.
Sites will have to create separate versions of stories, including at least one for AMP mobile pages and another for regular (desktop/laptop) rendering. Kinsey Wilson, the New York Times’ executive vice president for product and technology, calls AMP “probably the most publisher-friendly solution we’ve seen to date” from the big tech companies, but making it all work takes real effort and staff time.
The Times has ample staff to make it all work; smaller publishers face a bigger hurdle. Even if it’s (relatively) simple to build AMP pages alongside the regular ones going forward, they’ll suffer to some degree if they don’t do this for the archives. (And, as open-standards advocate Kevin Marks notes, by relying on Google JavaScript code, not traditional HTML, for page rendering, AMP pages could ultimately make parts of the web even more fragile and difficult to archive.)
Another crucial partner is WordPress: an enormous portion of the Web, over 20 percent by some estimates, comes from its sites. As with other participants in this initiative, Automattic, the company behind WordPress, worries that the open Web is in trouble. So it’s building AMP into its WordPress.com commercial site, and making a plug-in available to people (like me) who run the free-to-use software on their own servers. My personal WordPress site is about as stripped down as it could be in any case, so AMP won’t make it all that much faster. But the cumulative effect of WordPress plus AMP is bound to be significant.
I still have a million questions about this, and some are the ones I began with: What if Google changes its strategy, by making it more proprietary and centralized?
What if news sites had just done the right thing in the first place? Or, since they didn’t, what if they just resolved to build faster pages — using standard HTML markup and loading components in a non-annoying way — now?
Wouldn’t that have gone a long way toward solving the problem? Do they, and we, really need all this?
For now, at any rate, the answer seems to be yes.
Excellent take from Gilmore.
https://googleblog.blogspot.com/2016/02/amping-up-in-mobile-search.html
Incorrect or at least an incomplete view of a reader-friendly web:
https://twitter.com/s_m_i/status/702530607662931969
This is what your devs could do too, if you prioritised performance.
Empathy for readers means not burdening the readers with massive article pages that are bloated with unnecessarily huge and maybe irrelevant images, along with a ton of javascript, trackers, etc.
Simplifying leads to faster performance and a better reading experience. Speed is only one aspect of this.
Yeah, the Toledo Blade probably should experiment with Facebook Instant Articles when the feature is open to everyone in April, and the Blade should produce AMP pages now. The Blade site could definitely use a speed-up. But does the Blade have the resources to exploit these ideas?
https://www.smashingmagazine.com/2016/02/everything-about-google-accelerated-mobile-pages/
http://www.kevinmarks.com/ampreaction.html
The broad goal of this spec is to simplify pages, and they do this by banning all javascript except their own (thereby confirming Marco's precept that blocking all 3rd party javascript is the answer).That fits in with Tantek's js;dr point of view to some extent, except they leave loophole for their own js code, which while fast and well written compared to most ad content, still breaks some things.
They also require a lot of arbitrary weird markup (like emoji in the html element, which violates content encoding, a weird style incantation that makes the page opaque, and require the proprietary schema.org markup.
Now, my site is not very complex; indeed it loads very fast on mobile already, but it does use a few javascript enhancements: fragmention to let you link to a phrase; webmention injection for comments as seen below, and the twitter embed enhancement javascript. Without these, the page still renders and makes sense, and it is parseable as microformats. This is known as progressive enhancement; AMP looks more like graceless degradation - the amp page without js is entirely blank because of the required style tag that sets opacity to 0.
http://www.kevinmarks.com/ampreaction-nojs.html
http://www.kevinmarks.com/ampreaction-amp.html
http://www.kevinmarks.com/ampreaction-amp-nojs.html
http://tantek.com/2015/069/t1/js-dr-javascript-required-dead
Normal version:
Amp version (which should probably have been the normal or default version to at the start.
http://www.mondaynote.com/2015/10/12/googles-potential-game-changing-boost-to-mobile-pages/
The AMP versions contain only a home link at the top of the navigation area. And the nav area is not fixed. Both are concepts that I prefer.
My September 2015 ToledoTalk.com comment
I don't need an app. I prefer one website that responds comfortably on all devices and loads fast with no mountains of JavaScript bilge, no huge irrelevant images, no ads, and no trackers and other gobbledygook that bog down page load speed.It would be nice if the article page contained a large-ish font size and a lot of negative space. I don't understand why some responsively-designed websites use a tiny, uncomfortable font size on mobile.
I see no need for a bunch of navigation links in the header and footer areas of an article page. No fixed areas. No hamburger or similar menu icons, like I use here [at TT]. The only link needed is a link to the home page. The reader can find all the site's link cruft on the home page.
On an article page, I want at least 99% of the page to focus on the article: Title, secondary title, author, contact info, publish date, and content.
But my comment was not restricted only to mobile versions of websites. My thoughts applied to a website, regardless of where it was viewed.
From my GitHub page about article designs https://github.com/jrsawvel/Article-Designs :
No CSS and no JavaScript is actually an improvement for some overly-engineered sites. In my opinion, the problem is that too many website publishers/designers/developers focus on extravagance instead of elegance.
Testing on my iPhone:
The AMP pages won't load from the desktop. Need to use the phone.
When viewing pages, the header/nav area is fixed. It's a smooth scroll, which I dislike implementing because it keeps the back and forward arrow area fixed at the bottom of the Safari browser. Chrome's mobile browser smooth-scrolls web pages by default. To get smooth scroll to work in Safari, CSS needs to be added, and I don't like it. The fixed HTML area at the top and then Safari's fixed area at the bottom reduces the reading area.
It's interesting. Not bad. Definitely fast loading. Amazingly fast. But it means publishers can continue to create bloated websites in case someone actually visits their site, instead of reading their content within Facebook, Apple, and Google.
What bad thing: the font size is too small. It's not painfully small, but it would be more comfortable if the font size was a little larger.
Feb 25, 2016
http://techcrunch.com/2016/02/24/wordpress-sites-now-support-googles-amp-to-make-mobile-pages-load-much-faster
https://news.ycombinator.com/item?id=11167428
As I've noted elsewhere: to use AMP, you must load JavaScript from the AMP CDN, which is operated by Google. So you are handing over the security of your site and your user's privacy to them.
After view some AMP articles on my iPhone, it's a bit awkward to me, since a link to the story on the publisher's website does not exist. If I wanted to bookmark the story, I ended getting only a Google AMP URL.
I don't like the fixed blue nav area. The pages load super fast. The font sizes, however, could be a little larger. Publishers can include some CSS actions that get used within AMP, such as a publisher fixing their own nav area at the top and share buttons at bottom. With all of the fixed areas, the viewing area is reduced significantly.
But it's an improvement over most of the publisher's websites. Basically, an article is displayed within a Google viewer. It seems odd to me, but that's what publishers enabled.
https://news.ycombinator.com/item?id=11167478
https://timkadlec.com/2016/02/a-standardized-alternative-to-amp/
last fall:
http://andydavies.me/blog/2015/10/13/accelerated-mobile-pages-ive-more-questions-than-answers/
From JR's : articles
3248 words - 22271 chars
- 18 min read
created on
updated on
- #
source
- versions