Hacker News Reader

Comment by mankyd | Hacker News Reader

I used to work on Pagespeed. People were always so puzzled that adding Google Analytics or Maps to their page would lower their score. "This is your own company's tools! They shouldn't count! Make them fast!"

We always responded that adding any extra "weight" to a page made it slower. We didn't give our own tools any special treatment. It was up to the site owners to decided what costs were worth their corresponding benefit.

Put another way: the fastest page is an empty one, but that's not terribly useful. Optimize for not just for speed but for utility.

(Disclosure: I still work for Google, but haven't worked on Pagespeed - or anything remotely related - in many years).

View on HN

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

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

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

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.

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.

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.

If the trick to sensible page sizes is letting the site owners decide which features to enable, couldn't we go a step further and let users decide which features they need from each site?

Turn off ads? Disable third-party scripts site-wide? Don't send over any audio? How about webfonts? Tracking? Webgl? Webgl2?

Would it not make more sense to ask the user (or their agent) what features they want to use, before trying to figure out which dependencies are needed to make them work?

Could we optimize not just for speed and utility but also user feedback?

That would require site owners to build sites that actually work across a large range of feature sets. Given most sites barely work in their default version, godspeed on that quest. (I mean, restaurants now have QR codes to download PDF menus. Clearly, site owner incentives aren't at all aligned with customer needs)

Why don't we also have a check box asking

[] Do you want a Million Dollars? [] Free Massage? . . or when they are booking an airline ticket [] Gigabit Internet [] Sleeper Couch

The amount of entitlement HNers have is mind-boggling.

Here's economics 101.

Users pay with attention/money for a list of goods/services from the provider. If you don't like it, switch your provider. Unlike some physical monopolies, you aren't bound to any provider.

If you think there is a market for your utopian content provider, how about you start your own company (with your fellow entitled HNers and provide all these features)?

Interesting plot twist! Economists do study these trends and you seem aware that the fact of having a right to something is trending among hackers, however I'm struggling to understand how any of what you just said relates to pruning code.

Was there any internal drama among teams?

Reply on news.ycombinator.com