Hacker News Reader

Comment by leeoniya | Hacker News Reader

> We didn't give our own tools any special treatment.

but you also didn't "Make them fast!" in response to the criticism. i know because i've profiled and purged plenty of google's JS from sites in the past. in most cases, this analytics/tag-manager JS far outweighed the site's own JS, to the tune of 5:1.

always found it odd how a company that makes V8, Blink, Chrome's DevTools, LightHouse, Closure Compiler, then evangelizes and blogs about performance but in the end doesnt take its own medicine.

View on HN

Each team has their own incentive:

The analytics team - get the best data possible The page speed team - get an objective analysis of the speed of a page

Even if it's in Google's interest to give their own stuff preference that would probably require some director or VP to coordinate that collusion and it's hard to say whether it would be worth the liability of having done that.

I don't think it's so much wanting Google scripts to have special treatment, but pushing the script teams to prioritize performance too, just like the Chrome and page speed teams.

I think you missed OPs point. If you want the functionality that those tools provide, then you pay for it with a longer page load.

It's easy to say "make it fast!". Yeah go ahead, make angular fast! Do it now! Its easier said than done...

Make it fast and make it small are not the same thing. The JS ecosystem has a huge culture of thousands of dependencies. “I don’t want to maintain the string trim function so I will import a library just for that” is routine. This is combined with hyperspecialized libraries with odd/unique names which makes discoverability tricky.

An empty VueJS app starts at several MBs of dependencies. That’s before you write any actual code. This is an example of bloat because “I don’t want the responsibility”.

The solution to this is to have more batteries included libraries or frameworks.

It's the same speed/utility tradeoff that mankyd is describing. There was a whole team staffed primarily to improve speed here, but you run into issues where functionality that is very important to publishers (or that makes money for them and so is indirectly important) just needs a lot of client-side javascript.

(I used to work in this area when I was at Google)

when i looked through the JS, it was not written in a way that took size or performance seriously. perhaps it was transpiled from Dart or something. additionally, i think tag manager includes an entire [likely complex] visual DOM tagging UI that gets downloaded even when not used, etc. (correct me if i'm wrong!)

embedding the youtube player downloads 576KB of compressed JS (2MB decompressed) [1], instead of 0 bytes for a cdn-hosted mp4 video; i'm quite certain there is not 2MB of value delivered to embedded youtube watchers.

i think there were/are a lot of low hanging fruit to give technical users / devs the ability to opt out of the whole kitchen sink.

[1] https://developers.google.com/youtube/youtube_player_demo

It scores better know, but previously if you even ran Google's own pages about Lighthouse through Lighthouse itself it would score terribly. I don't know if that ever helped my feelings towards the tool or made it worse.

Yeah, because page speed under 3 seconds doesn't make a difference to pagerank.

On the other hand, it's a miracle that there's still any Google product that's taking its medicine at all, considering the sheer size of the company and the forces at play to squeeze capitalism out of it.

Reply on news.ycombinator.com