18 ms·

A new approach to web performance

225 points by kostarelo 11y ago

manigandham 11y ago
What's sad is that this is just optimized HTML + CDN packaged up by Google and heralded as some big innovation. If publishers spent a few hours they could make extremely lightweight pages too (even with media and ads). Here's an AMP page: https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/reassurances-end-in-flint-after-months-of-concern.amp.html?amp_js_v=0 https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/r...
- stdbrouw 11y ago
  Well, most publishers actually use fairly optimized HTML/CSS and most publishers use a CDN. But there's only so much you can do if you don't want to get rid of those 5 ad networks, 7 analytics services, 2 sidebars and just generally a whole bunch of crap that has nothing to do with the article. The innovation of Facebook instant articles and AMP isn't technical, it's that they have been able to convince publishers that getting rid of all the bells and whistles will actually benefit them – and that if they don't do it, it will harm them because huge traffic drivers like Twitter won't put up with it anymore.
  - manigandham 11y ago
    I disagree - most publishers I've seen (including large and mid-level) have some of the most bloated HTML with megabytes(!) of javascript and CSS just for rendering + all the other stuff you mentioned. They are definitely not optimized. I dont think there is any innovation at all with either Facebook or Google, it's all about keeping the user on their service longer and by hosting the content themselves, they increase speed and claim more user time. It's a pure monopoly play with Apple, Google, Facebook having far more leverage than publishers (who have really none these days). Pubs need traffic to survive which is why they are willing to work with this, but the revenue potential is still up in the air so long-term sustainability is not anywhere near proven. I'm not convinced that this will work as a viable model, beyond the technical implementation.
    - zenocon 11y ago
      > I disagree - most publishers I've seen (including large and mid-level) have some of the most bloated HTML with megabytes(!) of javascript and CSS just for rendering + all the other stuff you mentioned. They are definitely not optimized. http://www.nytimes.com/interactive/2015/10/01/business/cost-of-mobile-ads.html http://www.nytimes.com/interactive/2015/10/01/business/cost-...
  - mattlutze 11y ago
    The search engines just need to penalize sites or result pages that have all these piles of bloat in them if they want to be a forcing function in the mobile web getting quicker. Push crappy experiences lower in the results and you can be sure news and aggregator sites will clean up their act. That Google et. al. are publishing a parallel framework to HTML indicates their goal is not just making mobile web faster, but in controlling that experience, to whatever end they may have in mind.
    - mtberatwork 11y ago
      > The search engines just need to penalize sites or result pages that have all these piles of bloat in them if they want to be a forcing function in the mobile web getting quicker. Isn't Google already claiming to demote sites that are slow to load, have content below the fold, etc?
- danieldk 11y ago
  What's sad is that this is just optimized HTML + CDN packaged up by Google and heralded as some big innovation. I think AMP is useful as a standard: setting a set of requirements to be considered an AMP page. Having such a brand plus possible beneficial treatment in search engines, will encourage publishers to adopt it. Sometimes a strong incentive is needed to change things.
  - PepeGomez 11y ago
    I think the sad part is that it isn't common practice and a standard has to be made.
- kostarelo 11y ago
  Did just this page disabled my Ad Blocker????
radicalbyte 11y ago
Maybe it's a sign of me getting old, but I have never understood the thought process behind building systems which server static content - newspapers, blogs - which require active processing for every request for every user. These are systems where the read/write ratios are often 1000:1. Ten years ago this was symptomized by systems which pulled the same content out of a database for every single request. We treated the symptoms by introducing caching servers and horizontal scaling. In modern times the symptom is displayed with heavy use of client-side rendering. Because, you know, this client-side rendering is "free" for the publisher. I don't understand how any "Engineer" can see 1000:1 R:W ratios and suggest doing all of the work on the R side of the ratio.
- deleted 11y ago
  [deleted]
- firasd 11y ago
  About static vs. dynamic rendering on the server side, the Movable Type CMS used to do exactly as you suggest and it was difficult to make changes on large sites. Imagine if you want to change a link on a sidebar and have to re-build every HTML page served by your CMS to do that. Caching dynamic pages is a bit of a “hybrid” system where you can just publish your new sidebar, then clear cache on the first request for each particular changed page. About the client side, the situation is a bit different because the JS is actually third-party software designed to be dropped in and updated easily, so it’s not just an implementation detail. Very few publishers are going to build or host their own server-side analytics or commenting systems…
  - radicalbyte 11y ago
    You can do that async - have the edit experience use the db then a publish action which re-generated the site. As for monitoring/comment systems: using external sites is actually really good for performance. Third party tools do a great job of blocking them and that makes a lot of sites very fast.
  - userbinator 11y ago
    Imagine if you want to change a link on a sidebar and have to re-build every HTML page served by your CMS to do that. On the other hand, doing the processing on the client side means that work would be done every single time by every single client, and the result of that work isn't even preserved. As decades of programmers have had absolutely no problem compiling software with many, many more dependent files than pages on a typical HTML site, I suspect the problem is in the implementation and not the concept. build or host their own server-side analytics or commenting systems I've not written any analytics before so I won't comment on that, but it's funny you mention commenting systems since a simple one (textboard-like) is literally less than a day's work.
bshimmin 11y ago
"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." Quite a bold decision there! Ultimately this will fail, of course, because the vast majority of sites that attempt to make money will need third-party scripts in some form. A much better move would be to try and produce a standard which third-party library authors could adhere to so that their scripts behaved nicely.
- danieldk 11y ago
  Quite a bold decision there! Ultimately this will fail, of course, because the vast majority of sites that attempt to make money will need third-party scripts in some form. I don't think it will necessarily fail, if AMP has a good ad story. I think some publishers realize that ad blocking is taking off in an accelerated pace since iOS 9. If they have to choose between a universe between no ad revenue (because ad blocking) and more behaved and subtle advertising, they will choose the latter. Given that AMP is pushed by Google, it's pretty obvious that they did think about ads: http://www.wsj.com/articles/what-googles-amp-project-means-for-online-advertising-1444247579 http://www.wsj.com/articles/what-googles-amp-project-means-f...
  - pjc50 11y ago
    "Google is not yet sure exactly how advertising will work within AMP" says that article.
    - JustSomeNobody 11y ago
      They can say that, but this is clearly targeted at the ad blocking conversation that is occurring.
peterjmag 11y ago
Two scrolling behaviors that I found odd on this page and on the NY Times example[1] on iOS: - You can't scroll to the top by tapping the status bar. - The scrolling momentum is different. There's less friction, as if you were scrolling through a list view (e.g. Mail). Anyone know how/why? I thought it might be some -webkit-overflow-scrolling trickery[2] with a full-size container div or something, but I don't see anything too weird like that. [1] https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/reassurances-end-in-flint-after-months-of-concern.amp.html?amp_js_v=0 https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/r... [2] https://css-tricks.com/snippets/css/momentum-scrolling-on-ios-overflow-elements/ https://css-tricks.com/snippets/css/momentum-scrolling-on-io... EDIT: Turns out there is some -webkit-overflow-scrolling trickery going on[3]. But again, why? [3] https://github.com/ampproject/amphtml/blob/77d9f31263866e56a83a7ee7194f1ec46bed65f9/src/viewport.js#L533-L559 https://github.com/ampproject/amphtml/blob/77d9f31263866e56a...
- joosters 11y ago
  The scrolling feels unchanged for me, but the top shortcut doesn't work. In general though, why sites feel the need to change / reimplement scrolling is beyond me. Every reimplementation is worse than the native behaviour.
- Rifu 11y ago
  If you take a look at the source[0], you'll notice they roll their own viewport renderer, presumably as a way for them to do their "tracking pixels". I imagine this might be what causes the difference in behavior? If anyone more knowledgeable could jump in, that would be cool. [0] https://github.com/ampproject/amphtml/blob/master/src/viewport.js https://github.com/ampproject/amphtml/blob/master/src/viewpo...
- ino 11y ago
  -webkit-overflow-scrolling makes scrolling feel like native, important for web apps and web views. It's like when you make an overflow: scroll div, and you make your main content inside this it. It also ads the permanent url bar at the top and the navigational arrows at the bottom. This is useful for some web apps, because if those weren't permanent, you couldn't have buttons fixed on the bottom. This is because when you would click them, the back/forward arrows bar would appear pushing your button up so you have to click it again. I used to use it but I've stopped because it's a whole level of complexity on your complex app. I wish iOS safari scrolling would feel like native. Many people are using this property for this reason only, sacrificing screen space (the always-on browser interface). It used to be worse with the small screen of the iPhone 4.
betageek 11y ago
I'm tremendously not keen on this, but am willing to be persuaded otherwise. I don't want to have to build my sites using Google's AMP framework and their custom elements just to get good SEO. I don't want to cache my content in Google's network so they can 1) track everything my users are doing without any indication on the front end and b) start serving ads from the cache and make every ad blocker stop working overnight. This looks like Trojans bearing gifts in my (maybe paranoid) mind.
- noir_lord 11y ago
  No, this is exactly my concern with this as well, particulary the ad-blocker thing (most sites already use google analytics).
joosters 11y ago
I hate it when pages suddenly change their scroll position, it makes reading the site painful. So any project that aims to fix this gets my approval! One more pet peeve of mine: websites with giant non-scrolling banners at the top of the page. Thanks for wasting my screen space just so you can show your stupid website logo. As well as the pixel wastage, half the sites can't even make their banner stay still, it wobbles slightly as you scroll and it tries to reposition itself. Or, it breaks page scrolling - page up/page down will skip content hidden under the banner. And while I'm moaning about the web of today: Also annoying are the sites that hide/shrink the banner as you scroll down the page, but make it pop back up as soon as you scroll upwards. If you accidentally move slightly too far down a page, you shift back up a row or two to catch a missing line of text, only to find a banner popping up and obscuring the bit that you specifically tried to view. Argh!
- idonthaveaname 11y ago
  All of those problems are design issues (in the sense of overall application/site design). They can "easily" be solved by not designing the site to work that way. Sites only work that way because site developers (the whole team) choose to do it and then implement a solution to achieve it. The specs for the various languages and the guidelines on their "best use" already define NOT doing any of those things either by dint of it not being built-in behavior or by already actively recommending against it. There's no need to follow a 2nd, proprietary specification to do what is already the standard.
- yoodenvranx 11y ago
  > I hate it when pages suddenly change their scroll position This problem gets worse and worse :( I also hate the trend to forcefully remap my old trusty middle mouse click from "open link in new tab" to "open link in current tab" via javascript.
mtgx 11y ago
Does this mean Google will get to centralize tracking through its servers even more?
- ducuboy 11y ago
  Yes. https://news.ycombinator.com/item?id=10358945 https://news.ycombinator.com/item?id=10358945
tempodox 11y ago
I suspect that the issue of web performance is less a technical problem than an organisational one. We have the technology to build performant pages right now, as well as best practises — they're just not used pervasively enough. As long as the business processes that produce the slow pages don't change, no shift in technology alone can save us.
- cramforce 11y ago
  Exactly. AMP is very much about addressing that issue.
jeena 11y ago
I don't seem to understand what this is for. If you want a fast loading page, don't add slow stuff to it. What new is AMP bringing to the table? It seems to be some kind of a framework? Is it code or is it a preprocessor or what is it?
ducuboy 11y ago
What annoys me is how Google is selling this project. At least Facebook is honest about their Instant Articles. This isn't an "open standard" guys, and it's not about performance! It's about the single piece of js that's allowed on AMP pages and the amp-tags such as <amp-ad> and <amp-pixel> that only Google controls. Performance is just the story they are selling in exchange of absolute control of the Web. After all, any publisher can easily clean up their websites as they ought to do to make it AMP compliant, but use valid HTML tags instead of the invalid amp-tags. Google could have easily promoted performance by applying penalties to heavy pages via Page Rank. But it's not about performance. It's all about the money.
- cramforce 11y ago
  First of all this is not a Google-only project. There are many partners. See e.g. https://blog.twitter.com/2015/introducing-accelerated-mobile-pages-0 https://blog.twitter.com/2015/introducing-accelerated-mobile... <amp-pixel> supports all kinds of tracking. You just give it a URL. Ironically it does not work with Google Analytics but we'll fix that eventually. Most others should work. <amp-ad> currently supports these ad networks https://github.com/ampproject/amphtml/blob/master/builtins/amp-ad.md https://github.com/ampproject/amphtml/blob/master/builtins/a... We are super happy to add more. We want to support all networks. You suggest elsewhere there is revenue sharing involved, but that is not true. amp-ad just loads an ad. This is controlled by the publishers and and their agreement with the advertiser. Google only plays a role if it happens to be the ad network (or the advertiser) involved.
  - felipeerias 11y ago
    Taking into account that Google "happens to be" the largest ad company around, it is hard to not see this as a defensive move to protect themselves at a time when the disproportionately negative impact of ad-tech has put their business at the mercy of adblockers and native apps.
    - solofounder1 11y ago
      In general, I think that there is an important conversation to be had about how this newly proposed cacheing tier would effect the overall cat and mouse game between tracking networks and ad blockers on mobile phones. Since the web community is being asked to choose to adopt a new technology, I don't think there's anything wrong with trying to reason about what would be technically possible to achieve in terms of tracking tech with this architecture. Here one rough estimate: If ads are all served locally (from a single domain) then it becomes technically feasible to utilize a short-lived rotating mutation URI generation scheme. Under such a tracking system each ad unit URI would be instantiated "just in time" to redirect a certain amount of load after which it would expire away. This JIT transient URI generator could be aware of the domain's application routing table so that it can dynamically spin out each new tracking/ad unit URI in a camouflaged form. In other words each URI could appear to be only a mutated variation of organic cached content. In computer security parlance this would establish a "covert channel" on top of HTTP via a timing attack vector (extremely short-lived URLs). https://en.wikipedia.org/wiki/Covert_channel https://en.wikipedia.org/wiki/Covert_channel https://en.wikipedia.org/wiki/Timing_attack https://en.wikipedia.org/wiki/Timing_attack I would imagine that ads propagated through such a system would be pretty much impossible for an ad-blocker to identify within a low-enough latency window. In other words by the time the ad unit's URI is discovered by a blocking server and it's clients are notified the URI has already vanished as if it never existed. What's I find slightly humorous about this approach to tracking is that the scheme would closely resemble several of the "blackhat SEO" techniques which are frowned upon by Matt Cutts' "Quality Guidelines" for example "link schemes", "automatically generated content", "cloaking", and "sneaky redirects". Surely it's unfathomable to think that Google would one day resort to such forms of trickery in order to confuse other search engines :) https://support.google.com/webmasters/topic/6001971 https://support.google.com/webmasters/topic/6001971 By the way this is only something I came up with earlier today and definitely not something that I've even heard discussed although I'm not in the advertising business myself. In other words it's entirely possible that I could have missed something here.
jackgavigan 11y ago
> Resources must declare their sizing up-front This is such a great idea. Jerky web pages that jump around while you're trying to click on something are maddeningly annoying.
mattmanser 11y ago
This really comes across as some sort of elaborate joke. Their solution to a slow web is to circumvent the standards and use a javascript library? My only contribution to the conversation is utter bewilderment someone thought this would be a good idea. The improvements are because they've removed everything. Also, side note but I thought there was already a proposal in HTML for reusable elements?
- ducuboy 11y ago
  No joke, it's all about the money. https://news.ycombinator.com/item?id=10358945 https://news.ycombinator.com/item?id=10358945
pavlov 11y ago
AMP reminds me of "i-mode", a Japanese mobile HTML variant originally launched in 1999 that was hugely popular in the country for many years: https://en.wikipedia.org/wiki/I-mode https://en.wikipedia.org/wiki/I-mode Then, as now, regular HTML pages were considered too slow and complicated for mobile phones. I-mode was conceived by the large network operator NTT Docomo. The big difference is that NTT Docomo were the exclusive gatekeepers for publishing content. Google also gives you the option of publishing AMP content on their CDN, but it's not mandatory.
mhw 11y ago
This is obviously Google's response to Facebook's Instant Articles and Apple's News. Behind all the technology is the main business goal of delivering a content platform that has the sponsoring company's ad network baked in to it.
- ducuboy 11y ago
  Exactly.
- possibleNoob 11y ago
  How does facebook instant articles technology work?
- cramforce 11y ago
  We support currently many / future most (if they chose to participate) ad networks and there is no rev share.
gildas 11y ago
I am wondering why v0.js is compiled with Babel if Google really wants the JavaScript execution to be fast.
bryanrasmussen 11y ago
That the page is itself an AMP HTML document would be really impressive if it wasn't really simple to make a completely valid html page that looks the same as that one that loads extremely fast on every platform.
- TazeTSchnitzel 11y ago
  I guess this makes my lowly blog now advanced technology, because it doesn't use JavaScript.
TazeTSchnitzel 11y ago
This isn't an HTML subset, it's some freakish pseudo-HTML JS library weirdness. Why not define an actual subset of HTML? You know, like XHTML Strict Mode? Why must everything be a JavaScript library?!
- spankalee 11y ago
  It _is_ an HTML (and CSS) subset. JavaScript is used to implement custom elements, like amp-image. That's just how custom elements work.
  - TazeTSchnitzel 11y ago
    It's not a subset, it's not a superset. It lacks some HTML things and adds new ones.
    - spankalee 11y ago
      Custom elements are a part of HTML, they can be part of a subset. Disqualifying custom elements from an HTML subset would be like claiming function declarations can't be in subsets of JavaScript.
      - TazeTSchnitzel 11y ago
        That's not really the same... HTML elements are more like keywords than functions.
        spankalee 11y ago
        Not really. To continue the analogy, in HTML doesn't really have keywords, but has syntax in the form of brackets, quotes, =, etc. Tags are like function calls, and the built in tags are like the standard library. Until custom elements you couldn't declare "functions".
JustSomeNobody 11y ago
I feel this is Google's response to Apple's ad blocking push (maybe push is too much here, what's a better word?). Neither AMP nor ad blocking are what is needed. We need sensible ads that are unobtrusive. We need web pages that do not track the consumer. We need smarter designs that don't use huge images everywhere. We need JS where it is needed and not just because it's cool. We don't need two behemoths fighting over the control of our web.
ramon 11y ago
It's not 100% on Google PageSpeed Insights, it's 75%. They needs now to focus on render blocking, space between the characters and gzip.
insanebits 11y ago
TLDR; I mostly agree with monopoly idea. We had WML for mobile devices before mobile devices were powerful enough to render HTML. Then we got smartphones better than my computer bought 5 years ago. AMP in my oppinion is a step back, yes you can do a lot of things in CSS. But in reality there are cases where it needs to happen dynamically. For example: javascript input validation, you cannot validate data using CSS. Are we then going to reinvent Javascript using some new fancy name?. Also, how about backwards compatibility(IE7-8 I'm looking at you)? Those companys could spend their resources on better things, like implementing ways to load viewport dependent images(it seems it's already done using picture tag). Because multimedia takes huge chunk of the website. And like always there are ways to write performant websites using existing technology and even more ways to write slow websites using all the "bleeding edge" technology. It's up to the developer mostly.
coldtea 11y ago
I have a 45 Mbps line (with low latency). Even so their crappy webfonts took like 1-2 seconds with a FOIT before that, while all the text was available almost immediately.
est 11y ago
WML reborn?
- ducuboy 11y ago
  Oh the good old days.. I was rendering WML/CHTML/XHTML with Wurfl depending on UAs from hacked ASP.NET. Then iPhone appeared and ruined everything ;)
anuraj 11y ago
Nothing new - Ever heard of CHTML, WBXML etc? 90's standards.
gorhill 11y ago
I personally choose to block ubiquitous 3rd parties by default[1], to fight both bloat AND privacy exposure. This AMP project reduces the bloat but at the cost of increased privacy exposure. If I globally block `ampproject.org` when visiting a AMP-enabled web pages, the pages do not render at all. My understanding is that now all "Google and its partners" have foiled the ability of visitors to protect their privacy with this AMP project -- and all these partners are given access to my browsing history. This goes completely counter to "The Internet is for End Users"[2]. I hope people will boycott by blocking wholesale `ampproject.org` as 3rd party -- this needs to fail. [1] Examples: `twitter.com`, `facebook.[com|net]`, `gravatar.com`, `fonts.googleapis.com`, etc. [2] http://mnot.github.io/I-D/for-the-users/ http://mnot.github.io/I-D/for-the-users/
- tombrossman 11y ago
  I'm curious why you say "when visiting a AMP-enabled web pages, the pages do not render at all". I'm not seeing the same result. The first two 'AMP' pages I tested loaded very quickly and were easily readable. I use Firefox with NoScript, which is definitely blocking the JS from ampproject.org. I also use Privacy Badger and uBlock Origin (thanks btw) and I'm not having any trouble at all. Here are the figures for the two pages I've tested with so far: 1- Visiting https://www.ampproject.org/how-it-works/ https://www.ampproject.org/how-it-works/ loads a perfectly readable page weighing 16.05kB in 40ms. It's just one file, the HTML document. 2- Visiting The Verge's demo page http://www.theverge.com/platform/amp/2015/10/7/9467149/google-accelerated-mobile-pages-caching-preview http://www.theverge.com/platform/amp/2015/10/7/9467149/googl... also loads a single perfectly readable HTML document weighing 17.6kB in 184ms. I've used NoScript for quite a while and while I don't expect every page to work perfectly with it, the speed gains are incredible! AMP and NoScript aren't directly comparable but they seem to be accomplishing the same thing for me. Only one of them is also blocking third-party tracking and delivering feather-light pages which nearly always render acceptably. Can you please clarify whether you mean the pages are totally blank, or if they just don't render the same as if you had allowed them to execute JS? (obviously if you globally block ampproject.org you can't access even their index.html page but that's not the info I'm after...)
  - 11y ago
z3t4 11y ago
The problem is that publishers want to know everything about their users, so they add tons of "spyware" that slow down the site. Who does already know EVERYTHING about your users? But can they sell it? startup idea: Make a blazingly fast CMS that tracks everything and show pretty graphs.
ised 11y ago
"Performance is just the story they are selling in exchange of absolute control of the Web." To be fair, they are not the only ones that use this "story" as a ploy to get more control over users (and hence gather more saleable personal information). Phrases like "make the web faster" are disingenuous and should not pass any intelligent user's BS filter. The very reason the web is slow is because of these companies which need to serve ads and other crud to survive. That means more DNS lookups, more TCP connections, more HTTP requests, more Javascript, longer URL's, more unwanted IMG's (e.g., beacons), more tags, etc., etc. The list is so long I cannot even hope to capture it all. That end result is simple: staring at a screen waiting for the computer to respond. Not to mention frequent leakage of personal information. As a user of netcat and text-only browsers that retrieve pages in milliseconds, I am astounded at how long users today are willing to wait for their content (i.e., "page loads"). I also run my own web servers at home to serve content to my family's mobile devices. I am well-aware of what (i.e., who) slows down "the Web". The user does not start from the assumption that she needs to (down)load "resources" (as in Uniform Resource Locator) from a number of advertisers for every page she views. Those are the assumptions that the web company starts with. Those are the constraints they must work within. Not true for users. I do not need Google DNS. I run my own locally, primed with all the domains I routinely visit. No remote DNS cache is going to be faster than my loopback. Nor do I need HTTP/2. I just use HTTP/1.1 pipelining to retrieve 100's of pages of content, usually 100 pages at a time. HTTP/2 is something the web companies may need to accomplish their goals of serving ads and collecting personal information. But it is not something users need. To drive adoption they must convince users that users need these "improvements". So the web companies purport to offer "solutions" to the problem they themselves created: a slow, bloated www.
- Certhas 11y ago
  So I as a user put up with all that loading of resources, because I don't have the time and money (resources) to set up my own version of the web. And because I consume a lot of content I don't otherwise pay for. To pretend that the infrastructure that allows companies to pay for the content I want to consume is incidental to the true purpose of the web (text documents??) is pretty narrow.
AnbeSivam 11y ago
With custom_element and web_component support not being complete in other browsers, will the polyfills provide as much benefit in these other browsers as it does in chrome.
Dirlewanger 11y ago
The only thing that's getting accelerated here is the filter bubble. The Internet and all of its neutral standards are being eviscerated by faceless avarice, and no one gives a shit.

225 points by kostarelo 11y ago

What's sad is that this is just optimized HTML + CDN packaged up by Google and heralded as some big innovation. If publishers spent a few hours they could make extremely lightweight pages too (even with media and ads). Here's an AMP page: https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/reassurances-end-in-flint-after-months-of-concern.amp.html?amp_js_v=0 https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/r...

stdbrouw 11y ago
Well, most publishers actually use fairly optimized HTML/CSS and most publishers use a CDN. But there's only so much you can do if you don't want to get rid of those 5 ad networks, 7 analytics services, 2 sidebars and just generally a whole bunch of crap that has nothing to do with the article. The innovation of Facebook instant articles and AMP isn't technical, it's that they have been able to convince publishers that getting rid of all the bells and whistles will actually benefit them – and that if they don't do it, it will harm them because huge traffic drivers like Twitter won't put up with it anymore.
- manigandham 11y ago
  I disagree - most publishers I've seen (including large and mid-level) have some of the most bloated HTML with megabytes(!) of javascript and CSS just for rendering + all the other stuff you mentioned. They are definitely not optimized. I dont think there is any innovation at all with either Facebook or Google, it's all about keeping the user on their service longer and by hosting the content themselves, they increase speed and claim more user time. It's a pure monopoly play with Apple, Google, Facebook having far more leverage than publishers (who have really none these days). Pubs need traffic to survive which is why they are willing to work with this, but the revenue potential is still up in the air so long-term sustainability is not anywhere near proven. I'm not convinced that this will work as a viable model, beyond the technical implementation.
  - zenocon 11y ago
    > I disagree - most publishers I've seen (including large and mid-level) have some of the most bloated HTML with megabytes(!) of javascript and CSS just for rendering + all the other stuff you mentioned. They are definitely not optimized. http://www.nytimes.com/interactive/2015/10/01/business/cost-of-mobile-ads.html http://www.nytimes.com/interactive/2015/10/01/business/cost-...
- mattlutze 11y ago
  The search engines just need to penalize sites or result pages that have all these piles of bloat in them if they want to be a forcing function in the mobile web getting quicker. Push crappy experiences lower in the results and you can be sure news and aggregator sites will clean up their act. That Google et. al. are publishing a parallel framework to HTML indicates their goal is not just making mobile web faster, but in controlling that experience, to whatever end they may have in mind.
  - mtberatwork 11y ago
    > The search engines just need to penalize sites or result pages that have all these piles of bloat in them if they want to be a forcing function in the mobile web getting quicker. Isn't Google already claiming to demote sites that are slow to load, have content below the fold, etc?
danieldk 11y ago
What's sad is that this is just optimized HTML + CDN packaged up by Google and heralded as some big innovation. I think AMP is useful as a standard: setting a set of requirements to be considered an AMP page. Having such a brand plus possible beneficial treatment in search engines, will encourage publishers to adopt it. Sometimes a strong incentive is needed to change things.
- PepeGomez 11y ago
  I think the sad part is that it isn't common practice and a standard has to be made.
kostarelo 11y ago
Did just this page disabled my Ad Blocker????

radicalbyte 11y ago

Maybe it's a sign of me getting old, but I have never understood the thought process behind building systems which server static content - newspapers, blogs - which require active processing for every request for every user. These are systems where the read/write ratios are often 1000:1. Ten years ago this was symptomized by systems which pulled the same content out of a database for every single request. We treated the symptoms by introducing caching servers and horizontal scaling. In modern times the symptom is displayed with heavy use of client-side rendering. Because, you know, this client-side rendering is "free" for the publisher. I don't understand how any "Engineer" can see 1000:1 R:W ratios and suggest doing all of the work on the R side of the ratio.

deleted 11y ago
[deleted]
firasd 11y ago
About static vs. dynamic rendering on the server side, the Movable Type CMS used to do exactly as you suggest and it was difficult to make changes on large sites. Imagine if you want to change a link on a sidebar and have to re-build every HTML page served by your CMS to do that. Caching dynamic pages is a bit of a “hybrid” system where you can just publish your new sidebar, then clear cache on the first request for each particular changed page. About the client side, the situation is a bit different because the JS is actually third-party software designed to be dropped in and updated easily, so it’s not just an implementation detail. Very few publishers are going to build or host their own server-side analytics or commenting systems…
- radicalbyte 11y ago
  You can do that async - have the edit experience use the db then a publish action which re-generated the site. As for monitoring/comment systems: using external sites is actually really good for performance. Third party tools do a great job of blocking them and that makes a lot of sites very fast.
- userbinator 11y ago
  Imagine if you want to change a link on a sidebar and have to re-build every HTML page served by your CMS to do that. On the other hand, doing the processing on the client side means that work would be done every single time by every single client, and the result of that work isn't even preserved. As decades of programmers have had absolutely no problem compiling software with many, many more dependent files than pages on a typical HTML site, I suspect the problem is in the implementation and not the concept. build or host their own server-side analytics or commenting systems I've not written any analytics before so I won't comment on that, but it's funny you mention commenting systems since a simple one (textboard-like) is literally less than a day's work.

bshimmin 11y ago

"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." Quite a bold decision there! Ultimately this will fail, of course, because the vast majority of sites that attempt to make money will need third-party scripts in some form. A much better move would be to try and produce a standard which third-party library authors could adhere to so that their scripts behaved nicely.

danieldk 11y ago
Quite a bold decision there! Ultimately this will fail, of course, because the vast majority of sites that attempt to make money will need third-party scripts in some form. I don't think it will necessarily fail, if AMP has a good ad story. I think some publishers realize that ad blocking is taking off in an accelerated pace since iOS 9. If they have to choose between a universe between no ad revenue (because ad blocking) and more behaved and subtle advertising, they will choose the latter. Given that AMP is pushed by Google, it's pretty obvious that they did think about ads: http://www.wsj.com/articles/what-googles-amp-project-means-for-online-advertising-1444247579 http://www.wsj.com/articles/what-googles-amp-project-means-f...
- pjc50 11y ago
  "Google is not yet sure exactly how advertising will work within AMP" says that article.
  - JustSomeNobody 11y ago
    They can say that, but this is clearly targeted at the ad blocking conversation that is occurring.

peterjmag 11y ago

Two scrolling behaviors that I found odd on this page and on the NY Times example[1] on iOS: - You can't scroll to the top by tapping the status bar. - The scrolling momentum is different. There's less friction, as if you were scrolling through a list view (e.g. Mail). Anyone know how/why? I thought it might be some -webkit-overflow-scrolling trickery[2] with a full-size container div or something, but I don't see anything too weird like that. [1] https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/reassurances-end-in-flint-after-months-of-concern.amp.html?amp_js_v=0 https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/r... [2] https://css-tricks.com/snippets/css/momentum-scrolling-on-ios-overflow-elements/ https://css-tricks.com/snippets/css/momentum-scrolling-on-io... EDIT: Turns out there is some -webkit-overflow-scrolling trickery going on[3]. But again, why? [3] https://github.com/ampproject/amphtml/blob/77d9f31263866e56a83a7ee7194f1ec46bed65f9/src/viewport.js#L533-L559 https://github.com/ampproject/amphtml/blob/77d9f31263866e56a...

joosters 11y ago
The scrolling feels unchanged for me, but the top shortcut doesn't work. In general though, why sites feel the need to change / reimplement scrolling is beyond me. Every reimplementation is worse than the native behaviour.
Rifu 11y ago
If you take a look at the source[0], you'll notice they roll their own viewport renderer, presumably as a way for them to do their "tracking pixels". I imagine this might be what causes the difference in behavior? If anyone more knowledgeable could jump in, that would be cool. [0] https://github.com/ampproject/amphtml/blob/master/src/viewport.js https://github.com/ampproject/amphtml/blob/master/src/viewpo...
ino 11y ago
-webkit-overflow-scrolling makes scrolling feel like native, important for web apps and web views. It's like when you make an overflow: scroll div, and you make your main content inside this it. It also ads the permanent url bar at the top and the navigational arrows at the bottom. This is useful for some web apps, because if those weren't permanent, you couldn't have buttons fixed on the bottom. This is because when you would click them, the back/forward arrows bar would appear pushing your button up so you have to click it again. I used to use it but I've stopped because it's a whole level of complexity on your complex app. I wish iOS safari scrolling would feel like native. Many people are using this property for this reason only, sacrificing screen space (the always-on browser interface). It used to be worse with the small screen of the iPhone 4.

betageek 11y ago

I'm tremendously not keen on this, but am willing to be persuaded otherwise. I don't want to have to build my sites using Google's AMP framework and their custom elements just to get good SEO. I don't want to cache my content in Google's network so they can 1) track everything my users are doing without any indication on the front end and b) start serving ads from the cache and make every ad blocker stop working overnight. This looks like Trojans bearing gifts in my (maybe paranoid) mind.

noir_lord 11y ago
No, this is exactly my concern with this as well, particulary the ad-blocker thing (most sites already use google analytics).

joosters 11y ago

I hate it when pages suddenly change their scroll position, it makes reading the site painful. So any project that aims to fix this gets my approval! One more pet peeve of mine: websites with giant non-scrolling banners at the top of the page. Thanks for wasting my screen space just so you can show your stupid website logo. As well as the pixel wastage, half the sites can't even make their banner stay still, it wobbles slightly as you scroll and it tries to reposition itself. Or, it breaks page scrolling - page up/page down will skip content hidden under the banner. And while I'm moaning about the web of today: Also annoying are the sites that hide/shrink the banner as you scroll down the page, but make it pop back up as soon as you scroll upwards. If you accidentally move slightly too far down a page, you shift back up a row or two to catch a missing line of text, only to find a banner popping up and obscuring the bit that you specifically tried to view. Argh!

idonthaveaname 11y ago
All of those problems are design issues (in the sense of overall application/site design). They can "easily" be solved by not designing the site to work that way. Sites only work that way because site developers (the whole team) choose to do it and then implement a solution to achieve it. The specs for the various languages and the guidelines on their "best use" already define NOT doing any of those things either by dint of it not being built-in behavior or by already actively recommending against it. There's no need to follow a 2nd, proprietary specification to do what is already the standard.
yoodenvranx 11y ago
> I hate it when pages suddenly change their scroll position This problem gets worse and worse :( I also hate the trend to forcefully remap my old trusty middle mouse click from "open link in new tab" to "open link in current tab" via javascript.

mtgx 11y ago

Does this mean Google will get to centralize tracking through its servers even more?

ducuboy 11y ago
Yes. https://news.ycombinator.com/item?id=10358945 https://news.ycombinator.com/item?id=10358945

tempodox 11y ago

I suspect that the issue of web performance is less a technical problem than an organisational one. We have the technology to build performant pages right now, as well as best practises — they're just not used pervasively enough. As long as the business processes that produce the slow pages don't change, no shift in technology alone can save us.

cramforce 11y ago
Exactly. AMP is very much about addressing that issue.

jeena 11y ago

I don't seem to understand what this is for. If you want a fast loading page, don't add slow stuff to it. What new is AMP bringing to the table? It seems to be some kind of a framework? Is it code or is it a preprocessor or what is it?

ducuboy 11y ago

What annoys me is how Google is selling this project. At least Facebook is honest about their Instant Articles. This isn't an "open standard" guys, and it's not about performance! It's about the single piece of js that's allowed on AMP pages and the amp-tags such as <amp-ad> and <amp-pixel> that only Google controls. Performance is just the story they are selling in exchange of absolute control of the Web. After all, any publisher can easily clean up their websites as they ought to do to make it AMP compliant, but use valid HTML tags instead of the invalid amp-tags. Google could have easily promoted performance by applying penalties to heavy pages via Page Rank. But it's not about performance. It's all about the money.

cramforce 11y ago
First of all this is not a Google-only project. There are many partners. See e.g. https://blog.twitter.com/2015/introducing-accelerated-mobile-pages-0 https://blog.twitter.com/2015/introducing-accelerated-mobile... <amp-pixel> supports all kinds of tracking. You just give it a URL. Ironically it does not work with Google Analytics but we'll fix that eventually. Most others should work. <amp-ad> currently supports these ad networks https://github.com/ampproject/amphtml/blob/master/builtins/amp-ad.md https://github.com/ampproject/amphtml/blob/master/builtins/a... We are super happy to add more. We want to support all networks. You suggest elsewhere there is revenue sharing involved, but that is not true. amp-ad just loads an ad. This is controlled by the publishers and and their agreement with the advertiser. Google only plays a role if it happens to be the ad network (or the advertiser) involved.
- felipeerias 11y ago
  Taking into account that Google "happens to be" the largest ad company around, it is hard to not see this as a defensive move to protect themselves at a time when the disproportionately negative impact of ad-tech has put their business at the mercy of adblockers and native apps.
  - solofounder1 11y ago
    In general, I think that there is an important conversation to be had about how this newly proposed cacheing tier would effect the overall cat and mouse game between tracking networks and ad blockers on mobile phones. Since the web community is being asked to choose to adopt a new technology, I don't think there's anything wrong with trying to reason about what would be technically possible to achieve in terms of tracking tech with this architecture. Here one rough estimate: If ads are all served locally (from a single domain) then it becomes technically feasible to utilize a short-lived rotating mutation URI generation scheme. Under such a tracking system each ad unit URI would be instantiated "just in time" to redirect a certain amount of load after which it would expire away. This JIT transient URI generator could be aware of the domain's application routing table so that it can dynamically spin out each new tracking/ad unit URI in a camouflaged form. In other words each URI could appear to be only a mutated variation of organic cached content. In computer security parlance this would establish a "covert channel" on top of HTTP via a timing attack vector (extremely short-lived URLs). https://en.wikipedia.org/wiki/Covert_channel https://en.wikipedia.org/wiki/Covert_channel https://en.wikipedia.org/wiki/Timing_attack https://en.wikipedia.org/wiki/Timing_attack I would imagine that ads propagated through such a system would be pretty much impossible for an ad-blocker to identify within a low-enough latency window. In other words by the time the ad unit's URI is discovered by a blocking server and it's clients are notified the URI has already vanished as if it never existed. What's I find slightly humorous about this approach to tracking is that the scheme would closely resemble several of the "blackhat SEO" techniques which are frowned upon by Matt Cutts' "Quality Guidelines" for example "link schemes", "automatically generated content", "cloaking", and "sneaky redirects". Surely it's unfathomable to think that Google would one day resort to such forms of trickery in order to confuse other search engines :) https://support.google.com/webmasters/topic/6001971 https://support.google.com/webmasters/topic/6001971 By the way this is only something I came up with earlier today and definitely not something that I've even heard discussed although I'm not in the advertising business myself. In other words it's entirely possible that I could have missed something here.

jackgavigan 11y ago

> Resources must declare their sizing up-front This is such a great idea. Jerky web pages that jump around while you're trying to click on something are maddeningly annoying.

mattmanser 11y ago

This really comes across as some sort of elaborate joke. Their solution to a slow web is to circumvent the standards and use a javascript library? My only contribution to the conversation is utter bewilderment someone thought this would be a good idea. The improvements are because they've removed everything. Also, side note but I thought there was already a proposal in HTML for reusable elements?

ducuboy 11y ago
No joke, it's all about the money. https://news.ycombinator.com/item?id=10358945 https://news.ycombinator.com/item?id=10358945

pavlov 11y ago

AMP reminds me of "i-mode", a Japanese mobile HTML variant originally launched in 1999 that was hugely popular in the country for many years: https://en.wikipedia.org/wiki/I-mode https://en.wikipedia.org/wiki/I-mode Then, as now, regular HTML pages were considered too slow and complicated for mobile phones. I-mode was conceived by the large network operator NTT Docomo. The big difference is that NTT Docomo were the exclusive gatekeepers for publishing content. Google also gives you the option of publishing AMP content on their CDN, but it's not mandatory.

mhw 11y ago

This is obviously Google's response to Facebook's Instant Articles and Apple's News. Behind all the technology is the main business goal of delivering a content platform that has the sponsoring company's ad network baked in to it.

ducuboy 11y ago
Exactly.
possibleNoob 11y ago
How does facebook instant articles technology work?
cramforce 11y ago
We support currently many / future most (if they chose to participate) ad networks and there is no rev share.

gildas 11y ago

I am wondering why v0.js is compiled with Babel if Google really wants the JavaScript execution to be fast.

bryanrasmussen 11y ago

That the page is itself an AMP HTML document would be really impressive if it wasn't really simple to make a completely valid html page that looks the same as that one that loads extremely fast on every platform.

TazeTSchnitzel 11y ago
I guess this makes my lowly blog now advanced technology, because it doesn't use JavaScript.

TazeTSchnitzel 11y ago

This isn't an HTML subset, it's some freakish pseudo-HTML JS library weirdness. Why not define an actual subset of HTML? You know, like XHTML Strict Mode? Why must everything be a JavaScript library?!

spankalee 11y ago
It _is_ an HTML (and CSS) subset. JavaScript is used to implement custom elements, like amp-image. That's just how custom elements work.
- TazeTSchnitzel 11y ago
  It's not a subset, it's not a superset. It lacks some HTML things and adds new ones.
  - spankalee 11y ago
    Custom elements are a part of HTML, they can be part of a subset. Disqualifying custom elements from an HTML subset would be like claiming function declarations can't be in subsets of JavaScript.
    - TazeTSchnitzel 11y ago
      That's not really the same... HTML elements are more like keywords than functions.
      - spankalee 11y ago
        Not really. To continue the analogy, in HTML doesn't really have keywords, but has syntax in the form of brackets, quotes, =, etc. Tags are like function calls, and the built in tags are like the standard library. Until custom elements you couldn't declare "functions".

JustSomeNobody 11y ago

I feel this is Google's response to Apple's ad blocking push (maybe push is too much here, what's a better word?). Neither AMP nor ad blocking are what is needed. We need sensible ads that are unobtrusive. We need web pages that do not track the consumer. We need smarter designs that don't use huge images everywhere. We need JS where it is needed and not just because it's cool. We don't need two behemoths fighting over the control of our web.

ramon 11y ago

It's not 100% on Google PageSpeed Insights, it's 75%. They needs now to focus on render blocking, space between the characters and gzip.

insanebits 11y ago

TLDR; I mostly agree with monopoly idea. We had WML for mobile devices before mobile devices were powerful enough to render HTML. Then we got smartphones better than my computer bought 5 years ago. AMP in my oppinion is a step back, yes you can do a lot of things in CSS. But in reality there are cases where it needs to happen dynamically. For example: javascript input validation, you cannot validate data using CSS. Are we then going to reinvent Javascript using some new fancy name?. Also, how about backwards compatibility(IE7-8 I'm looking at you)? Those companys could spend their resources on better things, like implementing ways to load viewport dependent images(it seems it's already done using picture tag). Because multimedia takes huge chunk of the website. And like always there are ways to write performant websites using existing technology and even more ways to write slow websites using all the "bleeding edge" technology. It's up to the developer mostly.

coldtea 11y ago

I have a 45 Mbps line (with low latency). Even so their crappy webfonts took like 1-2 seconds with a FOIT before that, while all the text was available almost immediately.

est 11y ago

WML reborn?

ducuboy 11y ago
Oh the good old days.. I was rendering WML/CHTML/XHTML with Wurfl depending on UAs from hacked ASP.NET. Then iPhone appeared and ruined everything ;)

anuraj 11y ago

Nothing new - Ever heard of CHTML, WBXML etc? 90's standards.

gorhill 11y ago

I personally choose to block ubiquitous 3rd parties by default[1], to fight both bloat AND privacy exposure. This AMP project reduces the bloat but at the cost of increased privacy exposure. If I globally block `ampproject.org` when visiting a AMP-enabled web pages, the pages do not render at all. My understanding is that now all "Google and its partners" have foiled the ability of visitors to protect their privacy with this AMP project -- and all these partners are given access to my browsing history. This goes completely counter to "The Internet is for End Users"[2]. I hope people will boycott by blocking wholesale `ampproject.org` as 3rd party -- this needs to fail. [1] Examples: `twitter.com`, `facebook.[com|net]`, `gravatar.com`, `fonts.googleapis.com`, etc. [2] http://mnot.github.io/I-D/for-the-users/ http://mnot.github.io/I-D/for-the-users/

tombrossman 11y ago
I'm curious why you say "when visiting a AMP-enabled web pages, the pages do not render at all". I'm not seeing the same result. The first two 'AMP' pages I tested loaded very quickly and were easily readable. I use Firefox with NoScript, which is definitely blocking the JS from ampproject.org. I also use Privacy Badger and uBlock Origin (thanks btw) and I'm not having any trouble at all. Here are the figures for the two pages I've tested with so far: 1- Visiting https://www.ampproject.org/how-it-works/ https://www.ampproject.org/how-it-works/ loads a perfectly readable page weighing 16.05kB in 40ms. It's just one file, the HTML document. 2- Visiting The Verge's demo page http://www.theverge.com/platform/amp/2015/10/7/9467149/google-accelerated-mobile-pages-caching-preview http://www.theverge.com/platform/amp/2015/10/7/9467149/googl... also loads a single perfectly readable HTML document weighing 17.6kB in 184ms. I've used NoScript for quite a while and while I don't expect every page to work perfectly with it, the speed gains are incredible! AMP and NoScript aren't directly comparable but they seem to be accomplishing the same thing for me. Only one of them is also blocking third-party tracking and delivering feather-light pages which nearly always render acceptably. Can you please clarify whether you mean the pages are totally blank, or if they just don't render the same as if you had allowed them to execute JS? (obviously if you globally block ampproject.org you can't access even their index.html page but that's not the info I'm after...)
- 11y ago

z3t4 11y ago

The problem is that publishers want to know everything about their users, so they add tons of "spyware" that slow down the site. Who does already know EVERYTHING about your users? But can they sell it? startup idea: Make a blazingly fast CMS that tracks everything and show pretty graphs.

ised 11y ago

"Performance is just the story they are selling in exchange of absolute control of the Web." To be fair, they are not the only ones that use this "story" as a ploy to get more control over users (and hence gather more saleable personal information). Phrases like "make the web faster" are disingenuous and should not pass any intelligent user's BS filter. The very reason the web is slow is because of these companies which need to serve ads and other crud to survive. That means more DNS lookups, more TCP connections, more HTTP requests, more Javascript, longer URL's, more unwanted IMG's (e.g., beacons), more tags, etc., etc. The list is so long I cannot even hope to capture it all. That end result is simple: staring at a screen waiting for the computer to respond. Not to mention frequent leakage of personal information. As a user of netcat and text-only browsers that retrieve pages in milliseconds, I am astounded at how long users today are willing to wait for their content (i.e., "page loads"). I also run my own web servers at home to serve content to my family's mobile devices. I am well-aware of what (i.e., who) slows down "the Web". The user does not start from the assumption that she needs to (down)load "resources" (as in Uniform Resource Locator) from a number of advertisers for every page she views. Those are the assumptions that the web company starts with. Those are the constraints they must work within. Not true for users. I do not need Google DNS. I run my own locally, primed with all the domains I routinely visit. No remote DNS cache is going to be faster than my loopback. Nor do I need HTTP/2. I just use HTTP/1.1 pipelining to retrieve 100's of pages of content, usually 100 pages at a time. HTTP/2 is something the web companies may need to accomplish their goals of serving ads and collecting personal information. But it is not something users need. To drive adoption they must convince users that users need these "improvements". So the web companies purport to offer "solutions" to the problem they themselves created: a slow, bloated www.

Certhas 11y ago
So I as a user put up with all that loading of resources, because I don't have the time and money (resources) to set up my own version of the web. And because I consume a lot of content I don't otherwise pay for. To pretend that the infrastructure that allows companies to pay for the content I want to consume is incidental to the true purpose of the web (text documents??) is pretty narrow.

AnbeSivam 11y ago

With custom_element and web_component support not being complete in other browsers, will the polyfills provide as much benefit in these other browsers as it does in chrome.

Dirlewanger 11y ago

The only thing that's getting accelerated here is the filter bubble. The Internet and all of its neutral standards are being eviscerated by faceless avarice, and no one gives a shit.