7 ms·

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

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.
  - leeoniya 9y ago
    > There are a LOT of talented frontend devs in Google...many Google engineers (and management) that JS is a "lesser" language And exactly what language do these fine folks do their frontend development in, Go, C++? Google sure spends a lot of resources on this lesser language for how few engineers want to work with it.
    - nevir 9y ago
      > And exactly what language do these fine folks do their frontend development in, Go, C++? For a very long time, GWT (Java compiled to JS) was the preferred approach. Then development moved to the Closure compiler (JS following very Java-like patterns), and only very recently is ES6 style code taking off. Much of the code you see still carries the legacy of GWT/Closure (and there is so much there that porting would be an insane task). It's a slow process. But, for example, YouTube is switching over to Polymer (https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtubes-new-look-and.html https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtu...). > Google sure spends a lot of resources on this lesser language for how few engineers want to work with it. Google is a massive company, with many different (often conflicting) initiatives. Chrome spends a lot of effort on JavaScript; but Chrome engineers are (for the most part) not the ones that are writing Google's frontend code.
      - leeoniya 9y ago
        > For a very long time, GWT (Java compiled to JS) was the preferred approach. fine, but this is entirely irrelevant. the problem is that no one was optimizing for the deliverable (HTML, JS, CSS). the GWT folks could have easily written an excellent compiler so it didnt spew a bunch of unoptimized and bloated trash. > YouTube is switching over to Polymer which requires a massive slow polyfill in all but latest Chrome and results in a shit experience for all others (if i recall a related thread correctly [1]). [1] https://www.reddit.com/r/javascript/comments/68vehl/youtubes_new_ui_uses_polymer/ https://www.reddit.com/r/javascript/comments/68vehl/youtubes...
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...

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.
- leeoniya 9y ago
  > There are a LOT of talented frontend devs in Google...many Google engineers (and management) that JS is a "lesser" language And exactly what language do these fine folks do their frontend development in, Go, C++? Google sure spends a lot of resources on this lesser language for how few engineers want to work with it.
  - nevir 9y ago
    > And exactly what language do these fine folks do their frontend development in, Go, C++? For a very long time, GWT (Java compiled to JS) was the preferred approach. Then development moved to the Closure compiler (JS following very Java-like patterns), and only very recently is ES6 style code taking off. Much of the code you see still carries the legacy of GWT/Closure (and there is so much there that porting would be an insane task). It's a slow process. But, for example, YouTube is switching over to Polymer (https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtubes-new-look-and.html https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtu...). > Google sure spends a lot of resources on this lesser language for how few engineers want to work with it. Google is a massive company, with many different (often conflicting) initiatives. Chrome spends a lot of effort on JavaScript; but Chrome engineers are (for the most part) not the ones that are writing Google's frontend code.
    - leeoniya 9y ago
      > For a very long time, GWT (Java compiled to JS) was the preferred approach. fine, but this is entirely irrelevant. the problem is that no one was optimizing for the deliverable (HTML, JS, CSS). the GWT folks could have easily written an excellent compiler so it didnt spew a bunch of unoptimized and bloated trash. > YouTube is switching over to Polymer which requires a massive slow polyfill in all but latest Chrome and results in a shit experience for all others (if i recall a related thread correctly [1]). [1] https://www.reddit.com/r/javascript/comments/68vehl/youtubes_new_ui_uses_polymer/ https://www.reddit.com/r/javascript/comments/68vehl/youtubes...

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...