Slashdot Mirror

"Ever wondered why pages seem to load slower and slower? Or why it is that browsing seems to take just as long to load a page, even though your broadband connection doubled in speed a couple of months ago?" gb7djk, a long-time Slashdot reader, blames "the bullshit web" -- as described in this essay by Calgary-based front-end developer Nick Heer (who does his testing on a 50 Mbps connection). A story at the Hill took over nine seconds to load; at Politico, seventeen seconds; at CNN, over thirty seconds. This is the bullshit web... When I use the word "bullshit" in this article, it isn't in a profane sense. It is much closer to Harry Frankfurt's definition in On Bullshit: "It is just this lack of connection to a concern with truth -- this indifference to how things really are -- that I regard as of the essence of bullshit...." The average internet connection in the United States is about six times as fast as it was just ten years ago, but instead of making it faster to browse the same types of websites, we're simply occupying that extra bandwidth with more stuff. Some of this stuff is amazing.... But a lot of the stuff we're seeing is a pile-up of garbage on seemingly every major website that does nothing to make visitors happier -- if anything, much of this stuff is deeply irritating and morally indefensible.

Take that CNN article, for example. Here's what it contained when I loaded it:

- Eleven web fonts, totalling 414 KB
- Four stylesheets, totalling 315 KB
- Twenty frames
- Twenty-nine XML HTTP requests, totalling about 500 KB
- Approximately one hundred scripts, totalling several megabytes -- though it's hard to pin down the number and actual size because some of the scripts are "beacons" that load after the page is technically finished downloading.

The vast majority of these resources are not directly related to the information on the page, and I'm including advertising... In addition, pretty much any CNN article page includes an autoplaying video... Also, have you noticed just how many websites desperately want you to sign up for their newsletter?
The essay also deals harshly with AMP, "a collection of standard HTML elements and AMP-specific elements on a special ostensibly-lightweight page that needs an 80 kilobyte JavaScript file to load correctly....required by the AMP spec to be hotlinked from cdn.amp-project.org, which is a Google-owned domain. That makes an AMP website dependent on Google to display its basic markup, which is super weird for a platform as open as the web."

It argues AMP is only speedier "because AMP restricts the kinds of elements that can be used on a page and severely limits the scripts that can be used," calling it a pseudo-solution. "Better choices should be made by web developers to not ship this bullshit in the first place.... An honest web is one in which the overwhelming majority of the code and assets downloaded to a user's computer are used in a page's visual presentation, with nearly all the remainder used to define the semantic structure and associated metadata on the page."

Google is rolling out tappable, visual stories that incorporate text, images, and videos in the style made popular by Snapchat. "It started widely testing the multimedia format, called AMP stories, today (Feb. 13) in an effort to help publishers engage more with readers on mobile," reports Quartz. Google announced the feature in a developer blog post. From the report: Users can now find Google stories in search results -- in a box called "visual stories" -- when they search on mobile at g.co/ampstories for the names of publishers that have begun using the format, such as CNN, Conde Nast, Hearst, Mashable, Meredith, Mic, Vox Media, and the Washington Post brands. Google worked with those publishers to develop the format. Desktop users can also get a taste of stories through Google's Accelerate Mobile Pages site. When a user selects a story, like Cosmopolitan magazine's piece on apple cider vinegar, it displays in a full-screen, slideshow format, similar to those on Snapchat and Instagram.

The multimedia format is part of Google's Accelerated Mobile Pages (AMP) project, a competitor to Facebook's Instant Articles that helps load pages faster on mobile devices. Like AMP, the AMP story format is open-sourced, so anyone can use it. However, Google is reportedly only displaying stories from a select group of publishers, including those it partnered with on the development, on its own site at the moment. The company said it plans to bring AMP stories to more Google products in the future, and expand the ways they appear in Google search.

Last week, Ethan Marcotte, an independent web designer, shared how Google describes AMP (Accelerated Mobile Pages). People at Google says AMP "isn't a 'proprietary format'; it's an open standard that anyone can contribute to." But that definition, Marcotte argues, isn't necessarily an honest one. He writes: On the face of it, this statement's true. AMP's markup isn't proprietary as such: rather, all those odd-looking amp- tags are custom elements, part of the HTML standard. And the specification's published, edited, and distributed on GitHub, under one of the more permissive licenses available. So, yes. The HTML standard does allow for the creation of custom elements, it's true, and AMP's license is quite liberal. But spend a bit of time with the rules that outline AMP's governance. Significant features and changes require the approval of AMP's Technical Lead and one Core Committer -- and if you peruse the list of AMP's Core Committers, that list seems exclusively staffed and led by Google employees. Now, there's nothing wrong with this. After all, AMP is a Google-backed project, and they're free to establish any governance model they deem appropriate. But when I hear AMP described as an open, community-led project, it strikes me as incredibly problematic, and more than a little troubling. AMP is, I think, best described as nominally open-source. It's a corporate-led product initiative built with, and distributed on, open web technologies. Jeremy Keith, a web developer, further adds: If AMP were actually the product of working web developers, this justification would make sense. As it is, we've got one team at Google citing the preference of another team at Google but representing it as the will of the people. This is just one example of AMP's sneaky marketing where some finely-shaved semantics allows them to appear far more reasonable than they actually are. At AMP Conf, the Google Search team were at pains to repeat over and over that AMP pages wouldn't get any preferential treatment in search results ... but they appear in a carousel above the search results. Now, if you were to ask any right-thinking person whether they think having their page appear right at the top of a list of search results would be considered preferential treatment, I think they would say hell, yes! This is the only reason why The Guardian, for instance, even have AMP versions of their content -- it's not for the performance benefits (their non-AMP pages are faster); it's for that prime real estate in the carousel. The same semantic nit-picking can be found in their defence of caching. See, they've even got me calling it caching! It's hosting. If I click on a search result, and I am taken to page that has a URL beginning with https://www.google.com/amp/s/... then that page is being hosted on the domain google.com. That is literally what hosting means. Now, you might argue that the original version was hosted on a different domain, but the version that the user gets sent to is the Google copy. You can call it caching if you like, but you can't tell me that Google aren't hosting AMP pages. That's a particularly low blow, because it's such a bait'n'switch.

Last week, Ethan Marcotte, an independent web designer, shared how Google describes AMP (Accelerated Mobile Pages). People at Google says AMP "isn't a 'proprietary format'; it's an open standard that anyone can contribute to." But that definition, Marcotte argues, isn't necessarily an honest one. He writes: On the face of it, this statement's true. AMP's markup isn't proprietary as such: rather, all those odd-looking amp- tags are custom elements, part of the HTML standard. And the specification's published, edited, and distributed on GitHub, under one of the more permissive licenses available. So, yes. The HTML standard does allow for the creation of custom elements, it's true, and AMP's license is quite liberal. But spend a bit of time with the rules that outline AMP's governance. Significant features and changes require the approval of AMP's Technical Lead and one Core Committer -- and if you peruse the list of AMP's Core Committers, that list seems exclusively staffed and led by Google employees. Now, there's nothing wrong with this. After all, AMP is a Google-backed project, and they're free to establish any governance model they deem appropriate. But when I hear AMP described as an open, community-led project, it strikes me as incredibly problematic, and more than a little troubling. AMP is, I think, best described as nominally open-source. It's a corporate-led product initiative built with, and distributed on, open web technologies. Jeremy Keith, a web developer, further adds: If AMP were actually the product of working web developers, this justification would make sense. As it is, we've got one team at Google citing the preference of another team at Google but representing it as the will of the people. This is just one example of AMP's sneaky marketing where some finely-shaved semantics allows them to appear far more reasonable than they actually are. At AMP Conf, the Google Search team were at pains to repeat over and over that AMP pages wouldn't get any preferential treatment in search results ... but they appear in a carousel above the search results. Now, if you were to ask any right-thinking person whether they think having their page appear right at the top of a list of search results would be considered preferential treatment, I think they would say hell, yes! This is the only reason why The Guardian, for instance, even have AMP versions of their content -- it's not for the performance benefits (their non-AMP pages are faster); it's for that prime real estate in the carousel. The same semantic nit-picking can be found in their defence of caching. See, they've even got me calling it caching! It's hosting. If I click on a search result, and I am taken to page that has a URL beginning with https://www.google.com/amp/s/... then that page is being hosted on the domain google.com. That is literally what hosting means. Now, you might argue that the original version was hosted on a different domain, but the version that the user gets sent to is the Google copy. You can call it caching if you like, but you can't tell me that Google aren't hosting AMP pages. That's a particularly low blow, because it's such a bait'n'switch.

An anonymous reader quotes a report from TechCrunch: One of the problems publishers face today in making their content more readable on mobile devices is that there are multiple, competing formats available for this purpose. Facebook has Instant Articles, Google is spearheading the AMP (Accelerated Mobile Pages) project, and the Apple News Format optimizes content for iOS devices. Facebook is today taking a crack at a solution to this problem by rolling out support for both AMP and soon Apple News as a part of its open source Instant Articles software development kit. The updated SDK will now include an extension that lets publishers build content that's publishable in all three formats, beginning with support for Google's AMP in addition to Facebook's own Instant Articles. In the weeks ahead it will also include support for publishing to Apple News, though the company didn't provide an exact launch date for when that feature would be added.

An anonymous reader quotes a report from Fortune: The Google iOS app for devices like the iPhone and iPad now supports the search giant's Accelerated Mobile Pages project, created to increase the loading times of news articles on the Internet. Now when users search for news from their Apple devices using the Google app, they should see streamlined news articles from media companies like The Washington Post that chose to participate in Google's web project. The AMP project is a Google-led initiative to standardize the software code behind each news article on the mobile web. AMP was designed to remove years of accumulated software code that has built up on online publishers' websites. As of Friday, iOS users should see a lightning bolt graphic and the letters "AMP" next to news articles from participating publishers in the "Top Stories" section of their search results in the Google app.

Reader Koreantoast writes: The New York Times posted an interesting thought piece (paywalled, this link could help) on the changing nature of manufacturing globally and the impact it has on modern politics and economic development. Although manufacturing productivity has jumped tremendously over the last several decades, the overall global pool of manufacturing jobs is shrinking as automation and new industrial technologies has increased the production and supply of manufactured goods with fewer people at a rate faster than global demand can absorb. The analogy is the agricultural revolution of the last several centuries where greater amounts of food are being produced by fewer and fewer farmers, displacing many of them. How will industrialized nations manage the growing number of displaced, blue collar labor? Bigger impact globally is that the shrinking pool of manufacturing jobs globally is closing the traditional route of export-oriented manufacturing economy that many nations, particularly in East Asia, were able to use to lift their nations out of poverty. What happens to those nations that missed the boat?"The likelihood that we will get a manufacturing recovery is close to nil," Professor Stiglitz said. "We are more likely to have a smaller share of a shrinking pie."

An anonymous reader writes: Google has officially taken the wraps off its AMP project — Accelerated Mobile Pages — which aims to speed up the delivery of web content to mobile devices. They say, "We began to experiment with an idea: could we develop a restricted subset of the things we'd use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance?" That subset is now encapsulated in AMP, their proof-of-concept. They've posted the code to GitHub and they're asking for help from the open source community to flesh it out. Their conclusions are familiar to the Slashdot crowd: "One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn't saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts." They're seeing speed boosts anywhere from 15-85%, but they're also looking at pre-rendering options to make some content capable of loading instantaneously. Their FAQ has a few more details.

An anonymous reader writes: Google has officially taken the wraps off its AMP project — Accelerated Mobile Pages — which aims to speed up the delivery of web content to mobile devices. They say, "We began to experiment with an idea: could we develop a restricted subset of the things we'd use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance?" That subset is now encapsulated in AMP, their proof-of-concept. They've posted the code to GitHub and they're asking for help from the open source community to flesh it out. Their conclusions are familiar to the Slashdot crowd: "One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn't saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts." They're seeing speed boosts anywhere from 15-85%, but they're also looking at pre-rendering options to make some content capable of loading instantaneously. Their FAQ has a few more details.

An anonymous reader writes: Google has officially taken the wraps off its AMP project — Accelerated Mobile Pages — which aims to speed up the delivery of web content to mobile devices. They say, "We began to experiment with an idea: could we develop a restricted subset of the things we'd use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance?" That subset is now encapsulated in AMP, their proof-of-concept. They've posted the code to GitHub and they're asking for help from the open source community to flesh it out. Their conclusions are familiar to the Slashdot crowd: "One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn't saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts." They're seeing speed boosts anywhere from 15-85%, but they're also looking at pre-rendering options to make some content capable of loading instantaneously. Their FAQ has a few more details.