8 ms·

The bloat of AMP

124 points by technion 9y ago

leeoniya 9y ago
also, YouTube's embedded player is 1.17MB js minified (~411KB gzipped) [1] this is why we simply self-host our mp4s w/ <video> tags. Gmail and AdWords UIs are equally terrible/bloated perf-wise. the plain html version of gmail [2] is still by far the best. for a company that built V8, Closure Compiler, Chrome Devtools, PageSpeed Insights, Lighthouse, etc. they really do a shit job on their own properties. Gmail went from the best in performant webapps when it first popularized Ajax to the worst example of one in 2017. it's as if Google can't find good frontend engineering talent, i don't get it :/ AMP is not a solution for slow pages, even if it's billed as such to clueless content producers. AMP is a content lock-in and user tracking strategy with the promise of boosted visibility/rank. nothing more. [1] https://www.youtube.com/yts/jsbin/player-vfleyMpxV/en_US/base.js https://www.youtube.com/yts/jsbin/player-vfleyMpxV/en_US/bas... [2] https://mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui https://mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui
- m-p-3 9y ago
  I wish they did some more optimization on Gmail, and especially Inbox. The desktop UI is painfully slow to load, to the point that I mostly use it on mobile now..
  - fiatjaf 9y ago
    Google Drive does not open anymore on my computer, seriously, while Google Spreadsheets (if I load them with a direct link) run smoothly.
- sotojuan 9y ago
  > it's as if Google can't find good frontend engineering talent, i don't get it :/ They can. Addy Osmani, Paul Irish, the PWA people, etc. They just don't seem to employ them to actually make user-facing products.
  - leeoniya 9y ago
    > They just don't seem to employ them to actually make user-facing products. it's fine if the high-level public-speaking folks aren't doing this, but the problem is that no one seems to be doing it. anyone can open up the DevTools network panel during a Gmail load, then look at the timings, payloads and generated DOM to see that it's almost entirely absolute shit by Google's own standards, even in Chrome on a fast desktop; they still use MochiKit ffs. there are at least several hundred engineers here on HN that can rewrite the Gmail UI to be "blazing fast" without gutting features and would still work great even on old phones still running Android 4.4.4 (with latest Chrome). obviously Google knows all of this, they just don't care because there's no measurable ROI in a faster free Gmail compared to getting people to host their juicy AMP content on Google's servers. "It's what the users want" is a half-truth optimized for maximum PR value; a bit like "Don't be evil".
    - DamonHD 9y ago
      Almost all the complaints on technical site performance I get from tools such as PageSpeed Insights and WebpageTest are indeed about Google's stuff, not mine, and as far as I can tell entirely unnecessarily. Eg leaving at least some of their own static site-furniture graphics not fully minimised and not cacheable? Likewise the CSS. I keep removing Google stuff from my properties because it outweighs my stuff by typically 10:1, again entirely unnecessarily AFAIK!
    - roywiggins 9y ago
      And Inbox is even worse. It's fine on a modern beefy desktop but brings my slightly anemic ye olde Linux box to a standstill, whereas GMail is still basically fine.
  - nevir 9y ago
    Addy, Dominic, Eric, the Pauls, etc are (mostly) dev outreach for the Chrome team, which is why they're so well known. There are a LOT of talented frontend devs in Google; you just don't see them much externally. That being said, there is also a toxic stance from many Google engineers (and management) that JS is a "lesser" language, and that feeling often translates to the devs that work in it.
- endorphone 9y ago
  AMP is a content lock-in strategy with the promise of boosted rank Open, not locked in, anyone can parse and cache it and it has to be publicly available (versus Apple News and Facebook Instant Articles that are pushed to those services), ridiculously straightforward and obvious. Oh, and there is no boosted rank. So aside from the entirety of your statement, you're entirely correct. People can have rational discussions about whether AMP is worthwhile or not (for instance, Google hosting the canonical script seems dubious) -- or whether some other subset of HTML would be ideal given the endless bloat that allows publishers to abuse fly-by users. However the rhetoric on here regarding AMP is so over the top of flag waving nonsense that it simply doesn't fit on a site where presumably we're a little more enlightened.
  - manigandham 9y ago
    Nobody else wants to parse or host it because HTML works just fine. We don't need a new version from Google that so far only helps with search result visibility while losing flexibility and increasing the amount of effort publishers need to effectively maintain 2 copies of their site. This is a regression back to the days of WAP mobile sites. It also does lock-in the users into Google's experience rather than actually visiting the site, which is a big issue, including problems like further centralizing traffic and data to a single company. Google could easily penalize search results based on speed with a strict cutoff and the entire web would become faster within weeks. Also the largest ad server on the web is Google's own doubleclick which is one of the slowest. There are many better ways to improve performance and UX without AMP.
    - endorphone 9y ago
      Nobody else wants to parse it because HTML is a perfectly well functioning and accepted system Apple and Facebook, two of the largest content (re)publishers, have their own competing formats, and Bing currently spiders and parses AMP content as well. But thinking more holistically, many others simply pushed their content into apps, abandoning the web wholesale. Because while we can talk about how "well functioning" the web is, a virtually universal observation is that native apps that just wrap a web browser are sloggy garbage, and a big reason is that the HTML stack has grown so enormously flexible it becomes its own enemy. We don't need a new version from Google that so far only helps with google rankings I'm a charitable sort of person, so when someone like Google comes out with something I assess why they did it without presuming the worst. In this case we see silos appearing from Apple and Facebook, not to mention the appification of content, so Google looks for a way to keep the web compelling. And it is. When I see an AMP page there are a number of user-centric benefits that make it a draw as a link, not just speed but also best behaviors. I mean, many of the complaints on here about AMP seem just surreal. For instance if you open the carousel (an option for trending topics like Trump) and swipe, it brings you to the next story in the carousel. This outrages some that you aren't locked in the gutter of a given site, which is just bizarre and anti-user.
- deleted 9y ago
  [deleted]
- matt_wulfeck 9y ago
  > also, YouTube's embedded player is 1.17MB js minified (~411KB gzipped) [1] this is why we simply self-host our mp4s w/ <video> tags. I find that as a user this is an often not ideal. For starters I probably have the JS cached. And the videos almost always going to play faster and more smoothly from google CDN versus some homebrew solution.
  - currysausage 9y ago
    > For starters I probably have the JS cached. Caching is not an excuse for giant JS files, they still need to be executed by my browser. > And the videos almost always going to play faster and more smoothly from google CDN versus some homebrew solution. That is indeed usually true.
  - leeoniya 9y ago
    > For starters I probably have the JS cached. this is one of those fallacies that people keep repeating and actually believe as truth. if you look at the headers of the youtube player file i linked, you'll see that anyone who had it cached prior to Wed, 28 Jun 2017 18:12:45 GMT is out of luck as well as myself when i request in > 48 hours. i dunno how often it changes, but it's safe to say "very frequently". date:Wed, 28 Jun 2017 18:23:58 GMT expires:Thu, 06 Jul 2017 18:23:58 GMT last-modified:Wed, 28 Jun 2017 18:12:45 GMT also relevant: https://twitter.com/HenriHelvetica/status/877924754195324928 https://twitter.com/HenriHelvetica/status/877924754195324928
    - TeMPOraL 9y ago
      A good point. RE that tweet, I assume the values there are in milliseconds. I hate it when people don't label their axes.
    - matt_wulfeck 9y ago
      Isn't it cached from any website I visit that uses it though? Almost for sure by the time I land on this particular page I've picked up the JS like some virus.
  - skrause 9y ago
- coldtea 9y ago
  >this is why we simply self-host our mp4s w/ <video> tags. So that I get way worse performance on trying to stream your videos than with YouTube's CDN? Seriously, anything besides YouTube (from Vimeo to Comedy Central, CNN, any site that self-hosts) is exceptionally sluggish...
  - leeoniya 9y ago
    our traffic levels (as 85% of all sites) are low enough where the experience is significantly better to self-host without involving third party HTTPS connections or dependencies. if we had an uptick in traffic, we would use a CDN to host the vids as long as the CDN didnt require that we swallow a 1MB js player for the pleasure of doing so.
    - ecnahc515 9y ago
      A CDN isn't only for helping you handle large amounts of traffic. It also makes sure the content is close to the user so they get a better experience.
      - leeoniya 9y ago
        true, but the need for a CDN isnt a foregone conclusion. it entirely depends on your traffic. a CDN also exposes your users' privacy via third-party cookies [1]. [1] https://news.ycombinator.com/item?id=14694451 https://news.ycombinator.com/item?id=14694451
      - TeMPOraL 9y ago
        > It also makes sure the content is close to the user so they get a better experience. The way most websites fuck that experience up with superfluous JS and media content makes this point moot, IMO. Being able to deliver JS 200ms faster doesn't help when you're serving megabytes of it.
    - coldtea 9y ago
      It's not about the load on your servers. It's about the CDN being optimized for my (or any other user's) region...
monokh 9y ago
AMP plugins are (supposedly) designed to be the fastest/lightweight/user-friendly implementation of a specific functionality. Yes, if all you consider by "bloat" is how many kilobytes of javascript you have on the page, AMP is not doing well. This is a crucial mistake in this post. In reality "bloat" is more than that. It also refers to whether there's active javascript slowing the browser down, whether resources are cached etc. The purpose of having these small plugins that enable functionality is that they are all individually cached by your browser for a good amount of time. Any Google user would have them cached as they are all using the same reference that any other AMP page would. This is unlike other "bloat" where resources are fragmented and come from any number of sources that users probably haven't hit before. In addition these JS resources wouldn't have been written for a specific experience - which AMP is
- TeMPOraL 9y ago
  The problem is, though, that the moment such wide variety of rich-media plugins is available, AMP stops working for bloat prevention - people will bloat up their AMP pages with superfluous media and JS. Bloat is not a web protocol problem - it's a problem of people being incentivized to add it.
SimeVidas 9y ago
I’ve tested the AMP and regular versions of a The Guardian article page, and the AMP version is more than 4 times smaller in terms of transferred KBs, coming in at about 300 KB. Yes, JavaScript represents more than half of that size, and there are 16 separate script files, but in comparison to the regular page, it’s a significant improvement. Note: I’ve tested with an ad/tracking blocker.
- pmlnr 9y ago
  That 150KB js needs to be executed in the browser, most of which could be simple HTML and CSS.
  - SimeVidas 9y ago
    I was implying that AMP leads to a reduction of JS in practice. Of course, if you have a very simple blog which loads very little JS to begin with, AMP could make things “worse.” But these types of blogs are an exception—unfortunately.
- jacquesm 9y ago
  The funny thing is that that Guardian article page is probably less then 10Kb in content to begin with. It's all the cruft on the page that makes it large, and AMP is also cruft, just less of it.
  - SimeVidas 9y ago
    The main content does indeed load after disabling JavaScript. The page size is about 60 KB in that case.
Retr0spectrum 9y ago
> I mean, I still can't make Get Cryptolocker[0] show up on Google. Hmm, I wonder if that's something to do with the fact that you're literally distributing malware... Surely there are legal issues here too? [0] getcryptolocker[.]com/get/ Edit: According to the about page, it isn't really cryptolocker, but VirusTotal still isn't happy about it: https://virustotal.com/en/file/0a2816af8a0580b0f58cb4ee1f102dc507d4013a0c1fd42af285d269da6029ee/analysis/ https://virustotal.com/en/file/0a2816af8a0580b0f58cb4ee1f102... I'm sure that in itself will hurt rankings.
- JadeNB 9y ago
  > Edit: According to the about page, it isn't really cryptolocker, but VirusTotal still isn't happy about it …. Since you've obviously followed this up, for the benefit of those of us who don't want to follow the link, could you explain what it is?
  - Retr0spectrum 9y ago
    I have no idea, I haven't tried running it.
- technion 9y ago
  Author here. It's a page I built for phishing susceptibility testing. There's another entire blog posting in the fact that I get about a 70% success rate emailing people from .ru domains asking them to visit that site and run the executable. It is 100% benign.
petarb 9y ago
I haven't used AMP, but my impression with all of Google CDN JavaScript files for AMP is the end user has to download them just once per version (which I agree will lead to a bloated first load experience) but on subsequent requests throughout the AMP network they'll be loaded from cache. Similar to how Google recommends you load jQuery through their CDN since millions of people already have it in cache.
- josteink 9y ago
  And then you have to waste your battery on running 100s of kbs of JS to show static HTML. No thanks.
  - monokh 9y ago
    But you'd rather go to the non AMP version which is 10x as bloated? It seems like the vision in your head is: AMP vs. Perfectly optimised site. In reality it's publishers who have built their main site over several years with massive bloat and are unable for whatever reason to optimise.
    - swiley 9y ago
      What google could do instead, if they really cared, is incentivise simple javascriptless static HTML. They won't do this though, because it makes tracking for ads harder.
      - ucaetano 9y ago
        This seems to be the main recurring argument against AMP. It isn't a comparison between AMP and the current web, it's a comparison between AMP and this utopian case where the entire web is simple javascriptless static HTML. It's like the ascii ribbon against HTML email...
        swiley 9y ago
        The diffence is that google has the power to improve the web and instead they warp it for their own profit while saying they're improving it. No one doing the ASCII ribbon thing could change what the majority of mail users saw when they opened their mail clients.
deleted 9y ago
[deleted]
wcr3 9y ago
less whining, more gifs of talented cats.
the8472 9y ago
The site uses AMP. My block AMP since it's a cross-domain request. After a while some inline script must be running into a timeout because the content suddenly shows up. Completely disabling javascript makes the site display faster.
haterswillhate 9y ago
People do not use these sanboxes please. Do not let google to decide anything about your company. They can and will drop your amp site immediately if your blog not meet they requirements. Please stay away of these tightly controlled sanboxes.
Navarr 9y ago
> this image will helpfully render with three dots in the middle to show you it's full of AMP goodness or something. It will render with three dots to let the browser know it is still loading. once it has finished, the dots disappear.
johnklos 9y ago
Google decided to name something "AMP" to confuse people who've used AMP to refer to Apache, MySQL and PHP for ages? Thanks, Google!
verytrivial 9y ago
If there was an option to disable AMP in Chrome, I'd flip it to off immediately. The longer this option is MIA, the more likely Firebox will become my default browser (again!)
gregable 9y ago
Breaking down a few of the concerns in this article: > Google's v0.js, which is compulsory on every AMP page, is currently 217Kb of Javascript. It is only 67KB gzipped, so it's not as bad as suggested, but this is an area for improvement. However, the file size doesn't directly translate to the implied latency, which is really what we care about. There are several reasons why this is much better than your average <5KB javascript files: - The file loads with an async tag, so does not block rendering. - The file uses a stale-while-revalidate header with 30-days, which means that any user who views any amp page on the web once a month will never wait for this file after the very first page load. That's most users. - If the page is loaded from the AMP cache, which is probably the common case, the file has a 1 year expiration. - The javascript uses a foreign fetch service worker to implement the same 1-year effective expiration on the non-AMP cache page views, for browsers that support it. > Google's default analytics.js is 30Kb. The AMP compliant edition of amp-analytics-0.1.js - is 80KB. All of the same responses as above apply here too. It's actually only 27KB on the wire, uses stale-while-revalidate and foreign-fetch service workers, etc. However, this is also not a completely fair comparison. amp-analytics doesn't implement Google Analytics, it implements every common analytics vendor on the web and has a configuration system for novel vendors. Most pages have half a dozen vendor's scripts running on them each with their own javascript payload and running code. This produces a single analytics event runtime and dispatches events to all of the vendors you want to run. Another advantage here is that it's not a new origin to connect to. Even if it's not cached, the DNS and HTTPS connections will be shared with v0.js and any of the other extensions. Depending on your connection, this will almost certainly reduce latency more than the added bandwidth. > you can still embed bloatey ads True, however what is less obvious is that those ads cannot block the main thread for loading the page, so they can't cause issues with scroll or displaying content. In fact, the ads don't actually load until right before they should be in the viewport. The ads also cannot reflow the layout of the page, making content move around as the page loads. > you could dynamically build a page using a mustache template True, but you cannot do so using custom javascript on the client which often blocks the rendering thread. This is a direct mapping from json to html. > The other is to append #development=1 to a URL. Unfortunately, if you try that here, your browser will crap out with errors about CORS and a CSP violation. The issue here is that the validation must operate on the original source of the document. By the time javascript runs, the browser has modified the DOM to the point where the original string is simply unavailable. So the #development=1 trick works by refetching the document using an XHR which only works in certain CORS environments. I'm not sure how else to do this. If you want to validate docs often, I recommend the chrome extension instead (https://chrome.google.com/webstore/detail/amp-validator/nmoffdblmcmgeicmolmhobpoocbbmknc?hl=en https://chrome.google.com/webstore/detail/amp-validator/nmof...). There are ports for other major browsers. > Paraphrasing: you can still load animations, large images, videos, etc. True, but you also don't have to. All of the code for loading these things has been optimized so that while it still may take a while to load those embedded objects, they won't slow down the rest of the document, which is the main advantage. They also won't cause re-layout events causing content to jump around while the page is loading. As a test, open up the network panel on chrome devtools, simulate a mobile phone with a smaller viewport, and hard refresh the page. You'll notice that the 9MB image included as a demo doesn't even get fetched. It's only when you scroll down halfway on the document that this image starts loading. This is what the amp-img component is accomplishing. The author appears to want fewer html features supported which is understandable, but it's not clear that this opinion is widely shared. > this image will helpfully render with three dots in the middle to show you it's full of AMP goodness or something. It's a loading indicator, the dots disappear when loading is complete. This is admittedly an odd effect with an animated gif, since the loading is still happening after the first frame has completely loaded.
randomguy7788 9y ago
you also have to remember these javascript files are then cached and used for ALL amp pages across the board and only gets invalidated once a week. there is also a stale-while-revalidate mechanism in amp if service workers are available so users never experience the delay of fetching new javascript binaries

124 points by technion 9y ago

also, YouTube's embedded player is 1.17MB js minified (~411KB gzipped) [1] this is why we simply self-host our mp4s w/ <video> tags. Gmail and AdWords UIs are equally terrible/bloated perf-wise. the plain html version of gmail [2] is still by far the best. for a company that built V8, Closure Compiler, Chrome Devtools, PageSpeed Insights, Lighthouse, etc. they really do a shit job on their own properties. Gmail went from the best in performant webapps when it first popularized Ajax to the worst example of one in 2017. it's as if Google can't find good frontend engineering talent, i don't get it :/ AMP is not a solution for slow pages, even if it's billed as such to clueless content producers. AMP is a content lock-in and user tracking strategy with the promise of boosted visibility/rank. nothing more. [1] https://www.youtube.com/yts/jsbin/player-vfleyMpxV/en_US/base.js https://www.youtube.com/yts/jsbin/player-vfleyMpxV/en_US/bas... [2] https://mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui https://mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui

m-p-3 9y ago
I wish they did some more optimization on Gmail, and especially Inbox. The desktop UI is painfully slow to load, to the point that I mostly use it on mobile now..
- fiatjaf 9y ago
  Google Drive does not open anymore on my computer, seriously, while Google Spreadsheets (if I load them with a direct link) run smoothly.
sotojuan 9y ago
> it's as if Google can't find good frontend engineering talent, i don't get it :/ They can. Addy Osmani, Paul Irish, the PWA people, etc. They just don't seem to employ them to actually make user-facing products.
- leeoniya 9y ago
  > They just don't seem to employ them to actually make user-facing products. it's fine if the high-level public-speaking folks aren't doing this, but the problem is that no one seems to be doing it. anyone can open up the DevTools network panel during a Gmail load, then look at the timings, payloads and generated DOM to see that it's almost entirely absolute shit by Google's own standards, even in Chrome on a fast desktop; they still use MochiKit ffs. there are at least several hundred engineers here on HN that can rewrite the Gmail UI to be "blazing fast" without gutting features and would still work great even on old phones still running Android 4.4.4 (with latest Chrome). obviously Google knows all of this, they just don't care because there's no measurable ROI in a faster free Gmail compared to getting people to host their juicy AMP content on Google's servers. "It's what the users want" is a half-truth optimized for maximum PR value; a bit like "Don't be evil".
  - DamonHD 9y ago
    Almost all the complaints on technical site performance I get from tools such as PageSpeed Insights and WebpageTest are indeed about Google's stuff, not mine, and as far as I can tell entirely unnecessarily. Eg leaving at least some of their own static site-furniture graphics not fully minimised and not cacheable? Likewise the CSS. I keep removing Google stuff from my properties because it outweighs my stuff by typically 10:1, again entirely unnecessarily AFAIK!
  - roywiggins 9y ago
    And Inbox is even worse. It's fine on a modern beefy desktop but brings my slightly anemic ye olde Linux box to a standstill, whereas GMail is still basically fine.
- nevir 9y ago
  Addy, Dominic, Eric, the Pauls, etc are (mostly) dev outreach for the Chrome team, which is why they're so well known. There are a LOT of talented frontend devs in Google; you just don't see them much externally. That being said, there is also a toxic stance from many Google engineers (and management) that JS is a "lesser" language, and that feeling often translates to the devs that work in it.
endorphone 9y ago
AMP is a content lock-in strategy with the promise of boosted rank Open, not locked in, anyone can parse and cache it and it has to be publicly available (versus Apple News and Facebook Instant Articles that are pushed to those services), ridiculously straightforward and obvious. Oh, and there is no boosted rank. So aside from the entirety of your statement, you're entirely correct. People can have rational discussions about whether AMP is worthwhile or not (for instance, Google hosting the canonical script seems dubious) -- or whether some other subset of HTML would be ideal given the endless bloat that allows publishers to abuse fly-by users. However the rhetoric on here regarding AMP is so over the top of flag waving nonsense that it simply doesn't fit on a site where presumably we're a little more enlightened.
- manigandham 9y ago
  Nobody else wants to parse or host it because HTML works just fine. We don't need a new version from Google that so far only helps with search result visibility while losing flexibility and increasing the amount of effort publishers need to effectively maintain 2 copies of their site. This is a regression back to the days of WAP mobile sites. It also does lock-in the users into Google's experience rather than actually visiting the site, which is a big issue, including problems like further centralizing traffic and data to a single company. Google could easily penalize search results based on speed with a strict cutoff and the entire web would become faster within weeks. Also the largest ad server on the web is Google's own doubleclick which is one of the slowest. There are many better ways to improve performance and UX without AMP.
  - endorphone 9y ago
    Nobody else wants to parse it because HTML is a perfectly well functioning and accepted system Apple and Facebook, two of the largest content (re)publishers, have their own competing formats, and Bing currently spiders and parses AMP content as well. But thinking more holistically, many others simply pushed their content into apps, abandoning the web wholesale. Because while we can talk about how "well functioning" the web is, a virtually universal observation is that native apps that just wrap a web browser are sloggy garbage, and a big reason is that the HTML stack has grown so enormously flexible it becomes its own enemy. We don't need a new version from Google that so far only helps with google rankings I'm a charitable sort of person, so when someone like Google comes out with something I assess why they did it without presuming the worst. In this case we see silos appearing from Apple and Facebook, not to mention the appification of content, so Google looks for a way to keep the web compelling. And it is. When I see an AMP page there are a number of user-centric benefits that make it a draw as a link, not just speed but also best behaviors. I mean, many of the complaints on here about AMP seem just surreal. For instance if you open the carousel (an option for trending topics like Trump) and swipe, it brings you to the next story in the carousel. This outrages some that you aren't locked in the gutter of a given site, which is just bizarre and anti-user.
deleted 9y ago
[deleted]
matt_wulfeck 9y ago
> also, YouTube's embedded player is 1.17MB js minified (~411KB gzipped) [1] this is why we simply self-host our mp4s w/ <video> tags. I find that as a user this is an often not ideal. For starters I probably have the JS cached. And the videos almost always going to play faster and more smoothly from google CDN versus some homebrew solution.
- currysausage 9y ago
  > For starters I probably have the JS cached. Caching is not an excuse for giant JS files, they still need to be executed by my browser. > And the videos almost always going to play faster and more smoothly from google CDN versus some homebrew solution. That is indeed usually true.
- leeoniya 9y ago
  > For starters I probably have the JS cached. this is one of those fallacies that people keep repeating and actually believe as truth. if you look at the headers of the youtube player file i linked, you'll see that anyone who had it cached prior to Wed, 28 Jun 2017 18:12:45 GMT is out of luck as well as myself when i request in > 48 hours. i dunno how often it changes, but it's safe to say "very frequently". date:Wed, 28 Jun 2017 18:23:58 GMT expires:Thu, 06 Jul 2017 18:23:58 GMT last-modified:Wed, 28 Jun 2017 18:12:45 GMT also relevant: https://twitter.com/HenriHelvetica/status/877924754195324928 https://twitter.com/HenriHelvetica/status/877924754195324928
  - TeMPOraL 9y ago
    A good point. RE that tweet, I assume the values there are in milliseconds. I hate it when people don't label their axes.
  - matt_wulfeck 9y ago
    Isn't it cached from any website I visit that uses it though? Almost for sure by the time I land on this particular page I've picked up the JS like some virus.
- skrause 9y ago
coldtea 9y ago
>this is why we simply self-host our mp4s w/ <video> tags. So that I get way worse performance on trying to stream your videos than with YouTube's CDN? Seriously, anything besides YouTube (from Vimeo to Comedy Central, CNN, any site that self-hosts) is exceptionally sluggish...
- leeoniya 9y ago
  our traffic levels (as 85% of all sites) are low enough where the experience is significantly better to self-host without involving third party HTTPS connections or dependencies. if we had an uptick in traffic, we would use a CDN to host the vids as long as the CDN didnt require that we swallow a 1MB js player for the pleasure of doing so.
  - ecnahc515 9y ago
    A CDN isn't only for helping you handle large amounts of traffic. It also makes sure the content is close to the user so they get a better experience.
    - leeoniya 9y ago
      true, but the need for a CDN isnt a foregone conclusion. it entirely depends on your traffic. a CDN also exposes your users' privacy via third-party cookies [1]. [1] https://news.ycombinator.com/item?id=14694451 https://news.ycombinator.com/item?id=14694451
    - TeMPOraL 9y ago
      > It also makes sure the content is close to the user so they get a better experience. The way most websites fuck that experience up with superfluous JS and media content makes this point moot, IMO. Being able to deliver JS 200ms faster doesn't help when you're serving megabytes of it.
  - coldtea 9y ago
    It's not about the load on your servers. It's about the CDN being optimized for my (or any other user's) region...

monokh 9y ago

AMP plugins are (supposedly) designed to be the fastest/lightweight/user-friendly implementation of a specific functionality. Yes, if all you consider by "bloat" is how many kilobytes of javascript you have on the page, AMP is not doing well. This is a crucial mistake in this post. In reality "bloat" is more than that. It also refers to whether there's active javascript slowing the browser down, whether resources are cached etc. The purpose of having these small plugins that enable functionality is that they are all individually cached by your browser for a good amount of time. Any Google user would have them cached as they are all using the same reference that any other AMP page would. This is unlike other "bloat" where resources are fragmented and come from any number of sources that users probably haven't hit before. In addition these JS resources wouldn't have been written for a specific experience - which AMP is

TeMPOraL 9y ago
The problem is, though, that the moment such wide variety of rich-media plugins is available, AMP stops working for bloat prevention - people will bloat up their AMP pages with superfluous media and JS. Bloat is not a web protocol problem - it's a problem of people being incentivized to add it.

SimeVidas 9y ago

I’ve tested the AMP and regular versions of a The Guardian article page, and the AMP version is more than 4 times smaller in terms of transferred KBs, coming in at about 300 KB. Yes, JavaScript represents more than half of that size, and there are 16 separate script files, but in comparison to the regular page, it’s a significant improvement. Note: I’ve tested with an ad/tracking blocker.

pmlnr 9y ago
That 150KB js needs to be executed in the browser, most of which could be simple HTML and CSS.
- SimeVidas 9y ago
  I was implying that AMP leads to a reduction of JS in practice. Of course, if you have a very simple blog which loads very little JS to begin with, AMP could make things “worse.” But these types of blogs are an exception—unfortunately.
jacquesm 9y ago
The funny thing is that that Guardian article page is probably less then 10Kb in content to begin with. It's all the cruft on the page that makes it large, and AMP is also cruft, just less of it.
- SimeVidas 9y ago
  The main content does indeed load after disabling JavaScript. The page size is about 60 KB in that case.

Retr0spectrum 9y ago

> I mean, I still can't make Get Cryptolocker[0] show up on Google. Hmm, I wonder if that's something to do with the fact that you're literally distributing malware... Surely there are legal issues here too? [0] getcryptolocker[.]com/get/ Edit: According to the about page, it isn't really cryptolocker, but VirusTotal still isn't happy about it: https://virustotal.com/en/file/0a2816af8a0580b0f58cb4ee1f102dc507d4013a0c1fd42af285d269da6029ee/analysis/ https://virustotal.com/en/file/0a2816af8a0580b0f58cb4ee1f102... I'm sure that in itself will hurt rankings.

JadeNB 9y ago
> Edit: According to the about page, it isn't really cryptolocker, but VirusTotal still isn't happy about it …. Since you've obviously followed this up, for the benefit of those of us who don't want to follow the link, could you explain what it is?
- Retr0spectrum 9y ago
  I have no idea, I haven't tried running it.
technion 9y ago
Author here. It's a page I built for phishing susceptibility testing. There's another entire blog posting in the fact that I get about a 70% success rate emailing people from .ru domains asking them to visit that site and run the executable. It is 100% benign.

petarb 9y ago

I haven't used AMP, but my impression with all of Google CDN JavaScript files for AMP is the end user has to download them just once per version (which I agree will lead to a bloated first load experience) but on subsequent requests throughout the AMP network they'll be loaded from cache. Similar to how Google recommends you load jQuery through their CDN since millions of people already have it in cache.

josteink 9y ago
And then you have to waste your battery on running 100s of kbs of JS to show static HTML. No thanks.
- monokh 9y ago
  But you'd rather go to the non AMP version which is 10x as bloated? It seems like the vision in your head is: AMP vs. Perfectly optimised site. In reality it's publishers who have built their main site over several years with massive bloat and are unable for whatever reason to optimise.
  - swiley 9y ago
    What google could do instead, if they really cared, is incentivise simple javascriptless static HTML. They won't do this though, because it makes tracking for ads harder.
    - ucaetano 9y ago
      This seems to be the main recurring argument against AMP. It isn't a comparison between AMP and the current web, it's a comparison between AMP and this utopian case where the entire web is simple javascriptless static HTML. It's like the ascii ribbon against HTML email...
      - swiley 9y ago
        The diffence is that google has the power to improve the web and instead they warp it for their own profit while saying they're improving it. No one doing the ASCII ribbon thing could change what the majority of mail users saw when they opened their mail clients.

deleted 9y ago

[deleted]

wcr3 9y ago

less whining, more gifs of talented cats.

the8472 9y ago

The site uses AMP. My block AMP since it's a cross-domain request. After a while some inline script must be running into a timeout because the content suddenly shows up. Completely disabling javascript makes the site display faster.

haterswillhate 9y ago

People do not use these sanboxes please. Do not let google to decide anything about your company. They can and will drop your amp site immediately if your blog not meet they requirements. Please stay away of these tightly controlled sanboxes.

Navarr 9y ago

> this image will helpfully render with three dots in the middle to show you it's full of AMP goodness or something. It will render with three dots to let the browser know it is still loading. once it has finished, the dots disappear.

johnklos 9y ago

Google decided to name something "AMP" to confuse people who've used AMP to refer to Apache, MySQL and PHP for ages? Thanks, Google!

verytrivial 9y ago

If there was an option to disable AMP in Chrome, I'd flip it to off immediately. The longer this option is MIA, the more likely Firebox will become my default browser (again!)

gregable 9y ago

Breaking down a few of the concerns in this article: > Google's v0.js, which is compulsory on every AMP page, is currently 217Kb of Javascript. It is only 67KB gzipped, so it's not as bad as suggested, but this is an area for improvement. However, the file size doesn't directly translate to the implied latency, which is really what we care about. There are several reasons why this is much better than your average <5KB javascript files: - The file loads with an async tag, so does not block rendering. - The file uses a stale-while-revalidate header with 30-days, which means that any user who views any amp page on the web once a month will never wait for this file after the very first page load. That's most users. - If the page is loaded from the AMP cache, which is probably the common case, the file has a 1 year expiration. - The javascript uses a foreign fetch service worker to implement the same 1-year effective expiration on the non-AMP cache page views, for browsers that support it. > Google's default analytics.js is 30Kb. The AMP compliant edition of amp-analytics-0.1.js - is 80KB. All of the same responses as above apply here too. It's actually only 27KB on the wire, uses stale-while-revalidate and foreign-fetch service workers, etc. However, this is also not a completely fair comparison. amp-analytics doesn't implement Google Analytics, it implements every common analytics vendor on the web and has a configuration system for novel vendors. Most pages have half a dozen vendor's scripts running on them each with their own javascript payload and running code. This produces a single analytics event runtime and dispatches events to all of the vendors you want to run. Another advantage here is that it's not a new origin to connect to. Even if it's not cached, the DNS and HTTPS connections will be shared with v0.js and any of the other extensions. Depending on your connection, this will almost certainly reduce latency more than the added bandwidth. > you can still embed bloatey ads True, however what is less obvious is that those ads cannot block the main thread for loading the page, so they can't cause issues with scroll or displaying content. In fact, the ads don't actually load until right before they should be in the viewport. The ads also cannot reflow the layout of the page, making content move around as the page loads. > you could dynamically build a page using a mustache template True, but you cannot do so using custom javascript on the client which often blocks the rendering thread. This is a direct mapping from json to html. > The other is to append #development=1 to a URL. Unfortunately, if you try that here, your browser will crap out with errors about CORS and a CSP violation. The issue here is that the validation must operate on the original source of the document. By the time javascript runs, the browser has modified the DOM to the point where the original string is simply unavailable. So the #development=1 trick works by refetching the document using an XHR which only works in certain CORS environments. I'm not sure how else to do this. If you want to validate docs often, I recommend the chrome extension instead (https://chrome.google.com/webstore/detail/amp-validator/nmoffdblmcmgeicmolmhobpoocbbmknc?hl=en https://chrome.google.com/webstore/detail/amp-validator/nmof...). There are ports for other major browsers. > Paraphrasing: you can still load animations, large images, videos, etc. True, but you also don't have to. All of the code for loading these things has been optimized so that while it still may take a while to load those embedded objects, they won't slow down the rest of the document, which is the main advantage. They also won't cause re-layout events causing content to jump around while the page is loading. As a test, open up the network panel on chrome devtools, simulate a mobile phone with a smaller viewport, and hard refresh the page. You'll notice that the 9MB image included as a demo doesn't even get fetched. It's only when you scroll down halfway on the document that this image starts loading. This is what the amp-img component is accomplishing. The author appears to want fewer html features supported which is understandable, but it's not clear that this opinion is widely shared. > this image will helpfully render with three dots in the middle to show you it's full of AMP goodness or something. It's a loading indicator, the dots disappear when loading is complete. This is admittedly an odd effect with an animated gif, since the loading is still happening after the first frame has completely loaded.

randomguy7788 9y ago

you also have to remember these javascript files are then cached and used for ALL amp pages across the board and only gets invalidated once a week. there is also a stale-while-revalidate mechanism in amp if service workers are available so users never experience the delay of fetching new javascript binaries